xfs
[Top] [All Lists]

Re: [patch] detect and correct bad features2 superblock field

To: "Josef 'Jeff' Sipek" <jeffpc@xxxxxxxxxxxxxx>
Subject: Re: [patch] detect and correct bad features2 superblock field
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sat, 29 Mar 2008 23:53:40 -0500
Cc: David Chinner <dgc@xxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <20080330045014.GA26934@xxxxxxxxxxxxxx>
References: <20080220054041.GM155407@xxxxxxx> <47EEED18.9090206@xxxxxxxxxxx> <20080330045014.GA26934@xxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
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


<Prev in Thread] Current Thread [Next in Thread>