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