Linux: Data corrupting ext3 bug in 2.4.20

Versioni i sapolindur 2.4.20 i kernel te Linux permban nje bug ne suportin per filesystem ext3. Prandaj kujdes ne perdorimin e tij.
Ne vazhdim po ju percjell mesazhin e derguar tek linux-kernel Mailing List nga zbuluesi i ketij difekti:

From: Andrew Morton
To: linux-kernel Mailing List
Subject: data corrupting bug in 2.4.20 ext3, data=journal
Date: Sun Dec 01 2002 - 03:11:41 EST

In 2.4.20-pre5 an optimisation was made to the ext3 fsync functionwhich can very easily cause file data corruption at unmount time. Thiswas first reported by Nick Piggin on November 29th (one day after 2.4.20 wasreleased, and three months after the bug was merged. Unfortunate timing)

This only affects filesystems which were mounted with the `data=journal'option. Or files which are operating under `chattr -j'. So most peopleare unaffected. The problem is not present in 2.5 kernels.The symptoms are that any file data which was written within the thirtyseconds prior to the unmount may not make it to disk. A workaroundis to run `sync' before nmounting.

The optimisation was intended to avoid writing out and waiting on theinode's buffers when the subsequent commit would do that anyway. Thisoptimisation was applied to both data=journal and data=ordered modes.
But it is only valid for data=ordered mode.

In data=journal mode the data is left dirty in memory and the unmountwill silently discard it.

The fix is to only apply the optimisation to inodeswhich are operating under data=ordered.

--- linux-akpm/fs/ext3/fsync.c~ext3-fsync-fix Sat Nov 30 23:37:33 2002+++ linux-akpm-akpm/fs/ext3/fsync.c Sat Nov 30 23:39:30 2002@@ -63,10 +63,12 @@ int ext3_sync_file(struct file * file, s */ ret = fsync_inode_buffers(inode);

- /* In writeback mode, we need to force out data buffers too. In
- * the other modes, ext3_force_commit takes care of forcing out
- * just the right data blocks. */
- if (test_opt(inode->i_sb, DATA_FLAGS) == EXT3_MOUNT_WRITEBACK_DATA)
+ /*
+ * If the inode is under ordered-data writeback it is not necessary to
+ * sync its data buffers here - commit will do that, with potentially
+ * better IO merging
+ */
+ if (!ext3_should_order_data(inode))
ret |= fsync_inode_data_buffers(inode);

ext3_force_commit(inode->i_sb);

_

From: Andrew Morton
To: linux-kernel Mailing List
Subject: Re: data corrupting bug in 2.4.20 ext3, data=journal
Date: Sun Dec 01 2002 - 03:52:23 EST

Andrew Morton wrote:
> ...
> The fix is to only apply the optimisation to inodes which are operating
> under data=ordered.
>

That "fix" didn't fix it. Sorry about that.

Please avoid ext3/data=journal until it is sorted out.