Hey Eric, On Mon, Oct 22, 2012 at 03:24:16PM -0500, Eric Sandeen wrote: > commit 1e309da7a4f7e2a2f456bf6b7cea4c5f1181cd36 fixed xfsdump to > properly save & restore the top 16 bits of a 32-bit projid, which > otherwise was being dropped (and restored as 0) in older xfsdump. > > The original thought was to bump the dump version, so that we know > whether the dump (may) have the top 16 bits filled in. In practice > this would prevent older restores from restoring newer dumps, and > losing the top 16 bits contained in these newer dumps. > > However, in hindsight this appears to be of limited value. I > propose that the dump version change is unuseful/unwanted for a > couple reasons: > > * There is no actual dump *format* change; the structure size > is the same, and the top 16 bits were properly zeroed before; old > restores will read these fixed dumps without problems and without > restoring garbage. IOW, they will behave exactly as buggily as > they did before. And worst case, if a dump containing the top 16 > bits is mangled by an old restore, this can be easily remedied by > simply re-restoring with updated userspace. > > * We have no reliable method to know whether 32 bit project IDs are > in use; the feature flag was not added to the GEOM call at the time > of implementation. Therefore we cannot reliably bump to V4 only > for projid32bit filesystems, and we cannot restrict V4 restores > only to projid32bit filesystems. So the dump version is not > useful for feature cross-checking purposes. > > I spoke with wkendall via email, and although he may not have given > it the most scrutiny (having moved on from xfsdump-land), he also > felt that a version dump may not be warranted. This looks fine to me. I still think that bumping the format version was probably the right thing to do. But in this case it's not so important that I'm inclined to push harder for it. It was good to understand some of the implications of doing that, so maybe next time we do need to bump the version we'll be ready. Warning the user when he could be losing the top 16 bits of the project id is something for the would-be-nice list. Reviewed-by: Ben Myers <bpm@xxxxxxx> Regards, Ben _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
