Stephen Tweedie - a szerzője és karbantartója az ext3 journaled filerendszernek - patcheket küldött a 2.4-es kernelbe való beillesztés céljából Marcelo Tosattinak. Ahogy megjegyezte: "ezek a patchek tartalmazzák a jelenlegi legnagyobb, legfrissebb változásokat az ext3 filerendszer kódban.". Az összes patch tesztelve lett az ext3 CVS tree-ben. (Stephen Tweedie eredetileg a 2.2-es kernelekhez írta az ext3 filerendszert. Csak később került portolásra a 2.4 kernelbe. A portolást Peter Braam, Andreas Dilger és Andrew Morton végezték, Stephen segítségével. Az ext3 filerendszer a 2.4.15 kernelben lett belolvasztva a 2.4 mainline kernelbe.)
Az első patch amely az ext3 filerendszer kódhoz készült, segít "robusztusabbá tenni a dump(8) vagy a tune2fs(8) munkálatokat a block eszközökkel ``live" filerendszeren." A második patch fixálja a "a race window in buffer refiling" hibát.
Stephen Tweedie levelei:From: Stephen Tweedie
To: Marcelo Tosatti, linux-kernel-mailing-list
Subject: [Patch 0/2] 2.4.20-pre4/ext3: ext3 dirty buffer management
Date: Fri, 23 Aug 2002 00:19:34 +0100
Hi Marcelo,
This patch set contains the biggest recent change to ext3: a change to the way it deals with other dirty buffers in the system, making it robust against things like dump(8) or tune2fs(8) playing with the block device on a live filesystem. This patch has been in ext3 CVS for some time now.
I'll follow up with the other smaller fixes and tweaks in the next batch.
From: Stephen Tweedie
To: Marcelo Tosatti, linux-kernel-mailing-list
Subject: [Patch 1/2] 2.4.20-pre4/ext3: Handle dirty buffers encountered unexpectedly.
Date: Fri, 23 Aug 2002 00:19:36 +0100
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 after 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.
[patch 1]
From: Stephen Tweedie
To: Marcelo Tosatti, linux-kernel-mailing-list
Subject: [Patch 2/2] 2.4.20-pre4/ext3: Fix "buffer_jdirty" assert failure.
Date: Fri, 23 Aug 2002 00:19:36 +0100
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.
