Bug#573565: linux-image-2.6.26-2-amd64: ext3: umount with pending long symlinks and other I/O results in corrupted symlinks

[Jonathan Nieder <jrnieder@gmail.com>]

fixed 573565 linux-2.6/2.6.29-1
# fix is in the longterm tree
tags 573565 + fixed-upstream
quit

Jonathan Teh wrote:

> cd /path-to-ext3-partition
> tar xzf <path-to-tarball>
> cd /
> umount /path-to-ext3-partition
>
> On mounting the ext3 partition again, some long symlinks are
> observed to be corrupted and appear to contain data from previously
> deleted files.
>
> Further investigation shows that this bug was fixed upstream in
> 2.6.28 as commit c87591b719737b4e91eb1a9fa8fd55a4ff1886d6.
> In 2.6.29, that was reverted and fixed in jbd in commit
> 8fe4cd0dc5ea43760c59eb256404188272cc95dd.

Thanks for reporting it.

c87591b7 was backported to the longterm tree as v2.6.27.6~47 (ext3:
wait on all pending commits in ext3_sync_fs, 2008-11-07).  The fix in
jbd (8fe4cd0d, 2009-02-11) and revert of c87591b7 (02ac597c,
2009-02-11) were not backported.  I agree with you that it probably
makes sense to apply the ext3 fix for lenny.

By contrast, for ext4, Greg picked up all three patches (to ext4,
jbd2, and the revert of the patch to ext4):

 - v2.6.27.8~10 (ext4: wait on all pending commits in ext4_sync_fs(),
   2008-11-16)
 - v2.6.27.20~11 (jbd2: Fix return value of jbd2_journal_start_commit(),
   2009-02-24)
 - v2.6.27.20~10 (Revert "ext4: wait on all pending commits in
   ext4_sync_fs()", 2009-02-24)

As you mention, all these commits have nice testcases in their log
messages.

Thanks for your help.
Jonathan