From: Andreas Dilger <adilger@sun.com>
To: Theodore Tso <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org
Subject: Re: How were some of the lustre e2fsprogs test cases generated?
Date: Tue, 19 Feb 2008 14:13:46 -0700 [thread overview]
Message-ID: <20080219211346.GR3029@webber.adilger.int> (raw)
In-Reply-To: <20080219122925.GW25098@mit.edu>
On Feb 19, 2008 07:29 -0500, Theodore Ts'o wrote:
> On Tue, Feb 19, 2008 at 04:40:32AM -0700, Andreas Dilger wrote:
> > No, it hasn't always been true that we cleared the _hi fields in the
> > kernel code. But, it has been a year or more since we found this bug,
> > and all CFS e2fsprogs releases since then have cleared the _hi fields,
> > and there has not been any other e2fsprogs that supports extents, so
> > we expect that there are no filesystems left in the field with this
> > issue, and even then the current code will prefer to clear the _hi
> > bits instead of considering the whole extent corrupt.
>
> I checked again, and it looks like the interim code is indeed clearing
> the _hi bits. I managed to confuse myself into thinking it didn't for
> index nodes, but I checked again and it seems to be doing the right
> thing.
>
> The reason why I asked is that the extents code in the 'next' branch
> of e2fsprogs *does* consider the whole extent to be corrupt, since in
> the long run once we start 64-bit block number extent blocks, if the
> physical block number (including the high 16 bits) is greater than
> s_blocks_count, simply masking off the high 16 bits of the 48 bit
> extent block is probably not the right way of dealing with the
> problem.
>
> I think that's probably a safe thing to do since all of your customers
> who might have had a filesystem with non-zero _hi fields have almost
> certainly run e2fsck to clear the _hi bits at least once; do you
> concur that is a safe assumption? Or would you prefer that I add some
> code that tries to clear just the _hi bits, perhaps controlled by a
> configuration flag in e2fsck.conf?
I'm OK with either. We might consider patching e2fsck to return to the
more permissive CFS behaviour with _hi bits for our own releases, or
just leave it. Checking back in our patches, we fixed the kernel code
in July '06 and the e2fsck code in Jan '07, so I hope people have run
an e2fsck on their filesystems in the last 1.5 years.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
prev parent reply other threads:[~2008-02-19 21:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-19 0:06 How were some of the lustre e2fsprogs test cases generated? Theodore Ts'o
2008-02-19 0:36 ` Theodore Tso
2008-02-19 11:28 ` Andreas Dilger
2008-02-19 11:40 ` Andreas Dilger
2008-02-19 12:29 ` Theodore Tso
2008-02-19 21:13 ` Andreas Dilger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080219211346.GR3029@webber.adilger.int \
--to=adilger@sun.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).