How should e2fsck clear s_errno/j_errno on an ro mount?

On 7/23/12 2:14 PM, Theodore Ts'o wrote:
>> nWell, I tested e2fsprogs from git and saw the same trouble.  Let me
>> look more closely at that commit.
> 
> Hmm, would it be possible to send me /tmp/loop3.qcow.bz2 after running:
> 
>      e2image -Q /dev/loop3 /tmp/loop3.qcow
>      bzip2 /tmp/loop3.qcow
> 
> Regardless of what the problem ends up being, this looks like
> something for our regression test suite....
> 
> 					- Ted
> 

Sure I can do that, will do it offline.

FWIW, the commit you mentioned changes e2fsck_check_ext3_journal, and
we only get there from main() like this:

        if ((ctx->mount_flags & EXT2_MF_MOUNTED) &&
            !(sb->s_feature_incompat & EXT3_FEATURE_INCOMPAT_RECOVER))
                goto skip_journal;

        retval = e2fsck_check_ext3_journal(ctx);

In my case I am mounted ro and recovery is done, so
EXT3_FEATURE_INCOMPAT_RECOVER is not, set, and so we skip over it with
the goto.

or else from here:

        if (sb->s_feature_incompat & EXT3_FEATURE_INCOMPAT_RECOVER) {
                if (ctx->options & E2F_OPT_READONLY) {
			...
                } else {
			...
                        retval = e2fsck_run_ext3_journal(ctx);

And again, I've already done recovery and am mounted RO so we won't go that way.

If make the first test above a little later:





it clears it up for me but TBH I'm not totally clear on what all is going
on here.

-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Mon, Jul 23, 2012 at 03:21:45PM -0500, Eric Sandeen wrote:
> 
> If make the first test above a little later:
> 
> ...
> 
> 
> it clears it up for me but TBH I'm not totally clear on what all is going
> on here.

Your patch effectively reverts commit 47c1b8e1666: e2fsck: Skip journal
checks if the fs is mounted and doesn't need recovery

The reason why this patch was added was that it slightly speeded up
the HDD boots.  I've looked at this closely, and it's really not that
big of a speed up.  It only saves a single seek and read (to read the
journal superblock).  I've measured what it would be on a 1TB laptop
drive, and the difference is 60ms (70ms versus 10ms).

So I'm going to revert that commit, which should fix the problem that
we're seeing.  But it also turns out that the kernel is not quite
doing the right thing.  It should have never left the journal
superblock with a non-zero s_error indicator after it transfered the
error indicator to the superblock.  The problem was that we weren't
actually flushing the cleared errno field out to the disk for the
journal superblock.

							- Ted

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html