On Fri, 2006-11-17 at 09:20 -0600, sandeen@xxxxxxxxxxx wrote:
> > On Fri, 2006-11-17 at 00:34 -0600, sandeen@xxxxxxxxxxx wrote:
> >> and really, now that this is out in the wild, maybe sb_features3
> >> instead of padding is appropriate, and check both for the attr2
> >> bit...? :(
> >
> > Thats not going to work, theres three or four other feature2 bits
> > preceding attr2 as well.
> >
> > The "take a 32 bit systems fs to a 64 bit system" is relatively
> > uncommon, so I suppose its just something we live with (as we did
> > with the log recovery issues in that situation for several years).
>
> So you think this should not be fixed, then? Because if it -is- fixed
I didn't say that. It should be fixed. Noone will notice though,
as its not actually biting anyone... (the attr2 problem will not
be related to this, its gonna be something else).
> then it's not an fs transfer problem; suddenly 64-bit attr2 filesystems
> will think they have attr1 if proper padding is added.
Now to really fry your noodle, attr2 is actually ondisk compatible
with attr1. :) (the SB bit was taken to prevent a repair buglet
from accidentally trashing all inodes using a non-fixed forkoff).
cheers.
--
Nathan
|