On Tue, Sep 11, 2007 at 01:51:57PM -0400, Theodore Tso wrote:
>On Tue, Sep 11, 2007 at 04:59:53PM +0100, Steve McIntyre wrote:
>> Package: e2fsprogs
>> Version: 1.39+1.40-WIP-2006.11.14+dfsg-2
>> Severity: normal
>> Tags: upstream
>>
>> This is clearly an upstream bug - a recent Fedora installation shows
>> exactly the same behaviour.
>>
>> If the underlying filesystem has the dir_index flag, e2fsck will
>> always re-optimize directories, whether the -D option is passed on the
>> command line or not.
>
>Err, no. E2fsck will re-optimize an individual directory if it is
>corrupted. If you specify the -D option, it will optimize *all*
>directories.
>
>For example:
>
><[EMAIL PROTECTED]> {/usr/projects/e2fsprogs}, level 2
>502# e2fsck -f /dev/sdb1
>e2fsck 1.40.1 (08-Jul-2007)
>Pass 1: Checking inodes, blocks, and sizes
>Pass 2: Checking directory structure
>Pass 3: Checking directory connectivity
>Pass 4: Checking reference counts
>Pass 5: Checking group summary information
>boot: 62/122624 files (21.0% non-contiguous), 82110/244983 blocks
><[EMAIL PROTECTED]> {/usr/projects/e2fsprogs}, level 2
>503# e2fsck -fD /dev/sdb1
>e2fsck 1.40.1 (08-Jul-2007)
>Pass 1: Checking inodes, blocks, and sizes
>Pass 2: Checking directory structure
>Pass 3: Checking directory connectivity
>Pass 3A: Optimising directories
>Pass 4: Checking reference counts
>Pass 5: Checking group summary information
>
>boot: ***** FILE SYSTEM WAS MODIFIED *****
>boot: 62/122624 files (21.0% non-contiguous), 82110/244983 blocks
>
>If you have a filesystem where you are seeing something else, you're
>going to have to send me an compressed raw e2image file (see the
>"REPORTING BUGS" section of e2fsck).Hi Ted, Hmmm, OK. I thought I'd read the source and understood it but I guess not. What we're seeing is more worrying, then. :-( We're creating a small ext2 filesystem in a file to be used as an initrd for an embedded device. We do the following: * dd to create the empty file * mke2fs to create the filesystem * loopback mount the file * copy files in * unmount * fsck to make sure it will be clean when the embedded box tries to mount it We've triggered different behvaiour as the contents of /dev inside the initrd get bigger. We've just crossed a threshold, it seems. Whereas previously fsck would always quietly succeed, now it's doing a directory re-org on /dev and exiting non-zero to say it has modified the filesystem. This causes our Makefile to stop and report failure. Obviously, the Makefile can be easily fixed to be less paranoid but there still seems to be a problem here. If I add -O ^dir_index to the options given to mke2fs, this all works fine again and reports no changes from e2fsck. Equally, using older versions of the e2fs tools on older machines works fine; I'm assuming that's because they don't support/enable dir_index by default. Hence my suggestion that the dir_index flag is responsible. If e2fsck will only re-org corrupt directories then that suggests we're seeing real corruption. If it helps, we have a tiny tarball (attached) of the contents of the /dev directory of the ramdisk in a known-working state. Simply adding another /dev entry will show the problem. The included Makefile will show it happening - target ramdisk succeeds always, but ramdisk2 will fail. -- Steve McIntyre, Amino [EMAIL PROTECTED] "They say that you play Cambridge twice - once on the way up and once on the way down. It's nice to be back..." --- Armstrong & Miller
e2fstest.tgz
Description: GNU Unix tar archive
