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.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
