 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Oleg Drokin 2:5020/400 19 Nov 2002 23:41:41 To : Alex Tomas Subject : Re: Вопрос по ядрам от -------------------------------------------------------------------------------- Hello! Alex Tomas <bzzz@tmi.comex.ru> wrote: OD>> же как сейчас ext2. Hапример ext3 из 2.4.19 использовать просто OD>> страшно (после просмотра ченджлога из комплекта 2.4.20-rc2) и OD>> несмотря на это оно у многих работает без проблем. AT> только что посмотрел. что там страшного? строчки конкретные покажете? Hесомненно. Вот то что мне сразу в глаза бросилось, например. ChangeSet@1.676.8.3, 2002-09-30 17:36:40-03:00, sct@redhat.com [PATCH] Fix the order of inodes being marked dirty in a couple of corner cases The only impact of this bug is that the on-disk copies of i_version might got out of sync for a directory, or that an error inserting an inode into a directory might leave its i_nlinks or i_ctime incorrect on disk for a short interval. Neither problem will cause trouble for ext3 during normal operation, but the nlink problem might cause e2fsck to emit unnecessary warnings if we crash while the incorrect version of the inode is in the journal. ChangeSet@1.676.7.3, 2002-09-27 23:49:35-03:00, sct@redhat.com [PATCH] 2.4.20-pre4/ext3: Fix LVM snapshot deadlock Fix LVM snapshot deadlock: it is a bad idea to try to flush all running transactions while we already hold the superblock lock. Drop the sb lock while we flush. This only affects kernels that have the extra LVM VFS locking added in for filesystem quiescing on snapshots. ChangeSet@1.587.2.20, 2002-08-28 18:11:04-03:00, sct@redhat.com [PATCH] 2.4.20-pre4/ext3: Fix truncate restart error Fix for a rare problem seen under stress in data=journal mode: if we have to restart a truncate transaction while traversing the inode's direct blocks, we need to deal with bh==NULL in ext3_clear_blocks. ChangeSet@1.587.2.18, 2002-08-28 18:10:34-03:00, sct@redhat.com [PATCH] 2.4.20-pre4/ext3: Fix out-of-inodes handling Don't consider ENOSPC as a fatal error when allocating an inode. Otherwise running out of inodes marks the fs as having an error, potentially taking the kernel down if we are in panic-on-error fs mode. ChangeSet@1.587.9.17, 2002-08-26 19:27:35-03:00, sct@redhat.com [PATCH] 2.4.20-pre4/ext3: Fix "buffer_jdirty" assert failure. There was a race window in buffer refiling where we could temporarily expose the journal's internal BH_JBDDirect flag as BH_Dirty, which is visible to the rest of the VFS. That doesn't affect the journaling, because we hold journal_head locks while the buffer is in this transient state, but bdflush can see the buffer and write it out unexpectedly, causing ext3 to find the buffer in an unexpected state later. The fix simply keeps the dirty bits clear during the internal buffer processing, restoring the state to the private BH_JBDDirect once refiling is complete. ChangeSet@1.587.9.16, 2002-08-26 19:16:16-03:00, sct@redhat.com [PATCH] 2.4.20-pre4/ext3: Handle dirty buffers encountered Ext3's internal debugging has always assumed that it was illegal for there to be parallel IO on a buffer-head which it is trying to modify. That's reasonable --- if there is an IO collision, we end up with IOs hitting disk out-of-order wrt the journal, so we lose recovery guarantees. However, there are two cases where the test is a little over-zealous. If user space is performing inherently non-transactional writes (eg. tune2fs adding a label to a live filesystem and writing to the buffered device superblock location) then we can hit the ext3 assertion. More seriously, since 2.4.11 the page cache can lock a buffer_head for read even if the bh is already under journal control. The tune2fs bug is very rare: there have been no reports of it in Bugzilla or ext3-users lists, and only one on 2.5 on linux-kernel. But now, a dump(8) on a live filesystem can also give rise to the same condition, and in testing, dump + fs activity reproduces the assertion-failure VERY rapidly. This patch changes the jbd get-write-access code to take the buffer_head lock before testing the uptodate and dirty state of a bh, and relaxes the handling of unexpectedly-dirty buffers to be a printk warning, not a fatal error. The lock will cure the dump(8) interaction, and the warning means that we will still spot out-of-order writes, while not taking the whole kernel down if we collide with a tune2fs(8). The patch also removes a small potential hole in the recovery guarantees. It is not safe for a transaction to steal buffers from checkpoint mode until afte r that transaction has committed. Otherwise, a reboot at the wrong moment might find the old copy of the buffer in the journal had been removed from the recovery set before the new copy was written. Bye, Oleg --- ifmail v.2.15dev5 * Origin: Green's home news server (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/155504906c040.html, оценка из 5, голосов 10
|
|
|