From: Eric Sandeen <sandeen@sandeen.net>
To: Barry Naujok <bnaujok@sgi.com>
Cc: "xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: [REVIEW] User-space support for bad_features2 patch
Date: Fri, 22 Feb 2008 11:41:55 -0600 [thread overview]
Message-ID: <47BF0963.6020809@sandeen.net> (raw)
In-Reply-To: <op.t6w1h5f53jf8g2@pc-bnaujok.melbourne.sgi.com>
Barry Naujok wrote:
> The attached patch fixes mkfs.xfs writing the bad features2 in the first
> place (the change to xfs_sb.h does this).
>
> Next xfs_db support printing of this superblock field and xfs_check can
> report the bad_features2 field is set.
>
> xfs_repair can correct the error in the same fashion that David Chinner's
> mount code does it.
>
> This patch applies to the lazy-count xfs_repair conversion code that I
> posted a short time before this patch.
>
> Barry.
>
+ * Check bad_features2, if set and features2 is zero, copy
+ * bad_features2 to features2 and zero bad_features2.
+ */
+ if (sb->sb_bad_features2 != 0) {
+ if (sb->sb_features2 == 0)
+ sb->sb_features2 = sb->sb_bad_features2;
+ sb->sb_bad_features2 = 0;
+ primary_sb_modified = 1;
+ do_warn(_("superblock's features2 field is in the wrong "
+ "location, correcting\n"));
+ }
My only thought here is that if you repair it, then use an older kernel
w/o the fix, suddenly your fs behavior changes, whereas before you often
got lucky, and both userspace & kernelspace swapped the same way, and
you found the bits you were looking for out of luck :) (same goes for
the recent kernel fix too, I guess)
Should we flag the bad_features2 as "already copied to features2" but
otherwise leave it? Hmm I guess that would look like an unsupported
feature flag to old kernels, wouldn't it. Urgh.
-Eric
next prev parent reply other threads:[~2008-02-22 17:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-22 7:52 [REVIEW] User-space support for bad_features2 patch Barry Naujok
2008-02-22 17:41 ` Eric Sandeen [this message]
2008-02-25 0:39 ` Barry Naujok
2008-02-25 8:42 ` Eric Sandeen
2008-02-25 9:55 ` Jan Derfinak
2008-02-23 5:00 ` David Chinner
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=47BF0963.6020809@sandeen.net \
--to=sandeen@sandeen.net \
--cc=bnaujok@sgi.com \
--cc=xfs@oss.sgi.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.