Re: [PATCH 0/3] xfsdump: more projid32bit fixes

From: Eric Sandeen <sandeen@sandeen.net>
To: Eric Sandeen <sandeen@redhat.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH 0/3] xfsdump: more projid32bit fixes
Date: Mon, 22 Oct 2012 09:36:14 -0500	[thread overview]
Message-ID: <508559DE.3060203@sandeen.net> (raw)
In-Reply-To: <50788C50.40600@redhat.com>

On 10/12/12 4:32 PM, Eric Sandeen wrote:
> I recently sent a patch for 32-bit project IDs for xfsdump, to properly
> restore the top 16 bits, which otherwise get lost.  This forced a new
> dump format version 4 (we were currently at 3).
> 
> One thing missing is that we should not restore a dump with 32-bit
> project IDs onto a filesystem w/o that format; the restore will fail
> to restore the top 16 bits (but otherwise it returns success; attribute
> setting failures are not fatal (!?))
> 
> Also, 32-bit project ID is a bit uncommon; bumping the format (and making
> older restore incompatible) is a bit draconian.
> 
> 3 patches here:
> 
> 1/3: extend fs info call to get fs flags as well
> 2/3: default back to V3 and go to V4 only if the projid32 flag is set
> 3/3: fail restore if the target XFS fs doesn't have projid32 set
> 
> I have to say, I'm not super happy with this.  I have nagging fear
> of feature-flag-itis, and I'm not sure how extensible this is as newer
> versions may appear.  But anyway, here's a place to start.
> 
> (p.s. anybody have wkendall's new email?)  ;)

I spoke with Bill, and he actually didn't feel that a new version was
needed for the projid32 fix.  I'd like to get some discussion here,
and reach an agreement.  *NOT* bumping the version simplifies a whole
lot of things.

Here's what I'd said to Bill:

>> If we restore old dumps w/ new xfsdump, nothing special is needed;
>> 0 gets restored for the top 16 bits (vs. garbage, which WOULD be
>> bad).
>> 
>> So bumping the version really only prevents old restore from
>> restoring newer dumps.
>> 
>> If I *didn't* bump the version, then old restore would work, and
>> would simply not restore the top 16 bits - just like an old
>> dump+restore option did.

And Bill replied:

> Had a look at xfsdump, and I agree, there's no need to bump the format
> version. Nice of someone to leave some zeroed pad bytes next to the
> project id. 

so what are people's thoughts?  Moving to a new version has complexity
& compatibility consequences...

Thanks,
-Eric

> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs