Re: [PATCH 2/2] ext4: journal superblock modifications in ext4_statfs()

[Andreas Dilger <andreas.dilger@lustre.org>]

On 2009-11-14, at 19:29, Theodore Tso wrote:
> On Sun, Nov 08, 2009 at 09:41:28PM -0700, Andreas Dilger wrote:
>>
>> The reason we added this was for running a read-only e2fsck on a
>> filesystem without getting spurious errors just because the  
>> superblock
>> summaries were incorrect.  The other alternative is to change e2fsck
>> so that it doesn't consider just a block/inode summary an error.
>
> We've been doing this for a while --- e2fsprogs 1.34, since April
> 2003.  In e2fsck/super.c:check_super_block():
>
> 	if ((free_blocks != sb->s_free_blocks_count) ||
> 	    (free_inodes != sb->s_free_inodes_count)) {
> 		if (ctx->options & E2F_OPT_READONLY)
> 			ext2fs_unmark_valid(fs);
> 		else {

The problem is that if you do "e2fsck -fn" it will still report this  
as an error in the filesystem, even though "e2fsck -fp" will silently  
fix it.  I just repeated this test and still see errors, even 30  
minutes after a file was modified, even after multiple syncs.

[adilger@webber ~]$ sync; sleep 10; sync
[adilger@webber ~]$ e2fsck -fn /dev/dm-0
e2fsck 1.41.6.sun1 (30-May-2009)
Warning!  /dev/dm-0 is mounted.
Warning: skipping journal recovery because doing a read-only  
filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 884739 has zero dtime.  Fix? no

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -1784645
Fix? no

Inode bitmap differences:  -884739
Fix? no


home: ********** WARNING: Filesystem still has errors **********

home: 72709/2621440 files (17.6% non-contiguous), 4730591/5242880 blocks
[adilger@webber ~]$ echo $?
4

> Hence, I think it's safe to eliminate the updates in ext4_statfs()
> altogether.


Not yet.  I'd be happy if the "-n" e2fsck treated these fields in the  
same
way as it does for the real e2fsck.

The other thing that comes to mind is that we don't recover the journal
for a read-only e2fsck, but we DO recover it on a read-only mount  
seems inconsistent.  It wouldn't be hard to have e2fsck -n read the  
journal and
persistently cache the journal blocks in its internal cache (i.e. flag
them so they can't be discarded from cache) before it runs the rest of  
the
e2fsck.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.