linux-ext4 - Re: [PATCH 2/2] ext4: journal superblock modifications in ext4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <F64B29C1-A90E-42F5-80CF-5704283D9A1B@sun.com>
Date:	Mon, 16 Nov 2009 15:38:16 -0800
From:	Andreas Dilger <andreas.dilger@...tre.org>
To:	Theodore Tso <tytso@....edu>
Cc:	Eric Sandeen <sandeen@...hat.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 2/2] ext4: journal superblock modifications in	ext4_statfs()

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@...ber ~]$ sync; sleep 10; sync
[adilger@...ber ~]$ 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@...ber ~]$ 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html