On Thu, Mar 08, 2012 at 10:38:32AM -0600, Ben Myers wrote: > On Thu, Mar 08, 2012 at 09:42:21AM -0600, Eric Sandeen wrote: > > So, after thinking about this (and talking on irc) some more, I'm > > not convinced that a feature flag is the way to go. > > > > If we set a feature flag, suddenly old filesystems with 64-bit > > inodes will grow a new feature, and this will force a userspace > > upgrade - but there is no real new feature. This seems like a bad > > idea. My original patch (which Dave responded to with this one) > > simply made inode64 default, with no feature flags. > > > > Unless someone has a really compelling argument for the flag, > > I'm thinking this is the wrong approach after all. > > > > Perhaps I should resend the just-make-it-default patch. > > > > Comments? > > Ew! Forcing a userspace upgrade is not desireable. Since we would only > want to set the feature bit if userspace were already upgraded, and only > if there are 64 bit inos... How about two bits: one is set by mkfs and > checked by the kernel to see if it is ok to set the other. ;) > > The first bit could also act as 'now its ok to default to inode64'. Too complex, IMO. Just add an xfs_admin command to set the inode64 feature bit. That then overrides the inode64/inode32 mount option, and guarantees that the user has already upgraded userspace. i.e. the mount options are only valid if the feature bit it not set, and the feature bit can only be set via xfs_admin after a userspace upgrade. Kernels that don't understand the feature bit will refuse to mount, keeping in line with the current practise of requiring both kernel and userspace upgrades to occur in step to use new features.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
