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 think I should self-NAK this patchset, after a bit more thought.
Because the PROJID32BIT feature flag isn't available via the GEOM
ioctl for almost every kernel in existence (it'll be in what, 3.8?),
2/3) we'll fall back to V3 even if projid32bit is actually in use, and/or
3/3) we'll refuse to restore perfectly valid V4 dumps with 32-bit
projids to older kernels just because they don't report the feature.
I think this'd cause more confusion/trouble than it's worth, since we've
been lacking the GEOM flag for so long.
-Eric
> 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?) ;)
>
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
>
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
