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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox