From: Eric Sandeen <sandeen@sandeen.net>
To: Josef 'Jeff' Sipek <jeffpc@josefsipek.net>
Cc: David Chinner <dgc@sgi.com>, xfs-dev <xfs-dev@sgi.com>,
xfs-oss <xfs@oss.sgi.com>
Subject: Re: [patch] detect and correct bad features2 superblock field
Date: Sat, 29 Mar 2008 23:53:40 -0500 [thread overview]
Message-ID: <47EF1CD4.7070009@sandeen.net> (raw)
In-Reply-To: <20080330045014.GA26934@josefsipek.net>
Josef 'Jeff' Sipek wrote:
> On Sat, Mar 29, 2008 at 08:30:00PM -0500, Eric Sandeen wrote:
>> Hm, the other problem here may be that if we zero bad_features2, then
>> any older kernel will mount up as attr2... and run into the corruption
>> problem I found on F8...
>>
>> Should we make features2 and bad_features2 match rather than zeroing
>> bad_features2?
>
> I thought that was discussed here (or was it on IRC?), and the conclusion
> was the best way is to always have features2 == bad_features2. It is the
> safest way to handle things - the filesystem is guaranteed to work
> everywhere properly (old & new kernels). Both the userspace (xfs_repair)
> and kernel have to of course do the same thing (or bad_features2 with
> features2, and save the result in both locations).
>
> At least that's what I seem to remember.
>
> Josef 'Jeff' Sipek.
>
It might have been, but it's not what was checked in... *shrug*
http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c#rev1.419
-Eric
next prev parent reply other threads:[~2008-03-30 4:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-20 5:40 [patch] detect and correct bad features2 superblock field David Chinner
2008-02-20 14:09 ` Eric Sandeen
2008-02-20 19:13 ` Christoph Hellwig
2008-02-21 22:49 ` David Chinner
2008-03-29 3:25 ` Eric Sandeen
2008-03-29 16:19 ` Eric Sandeen
2008-03-30 1:30 ` Eric Sandeen
2008-03-30 1:49 ` Eric Sandeen
2008-03-30 4:50 ` Josef 'Jeff' Sipek
2008-03-30 4:53 ` Eric Sandeen [this message]
2008-03-30 5:29 ` Josef 'Jeff' Sipek
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=47EF1CD4.7070009@sandeen.net \
--to=sandeen@sandeen.net \
--cc=dgc@sgi.com \
--cc=jeffpc@josefsipek.net \
--cc=xfs-dev@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.