On Mon, Nov 23, 2015 at 06:56:09PM +0100, David Sterba wrote: > On Mon, Nov 23, 2015 at 08:56:13PM +0800, Anand Jain wrote: > > Btrfs-progs is a tool for the btrfs kernel and we hope latest btrfs-progs > > be compatible w any set of older/newer kernels. > > > > So far mkfs.btrfs and btrfs-convert sets the default features, for eg, > > skinny-metadata even if the running kernel does not supports it, and > > so the mount fails on the running. > > So the default behaviour of mkfs will try to best guess the feature set > of currently running kernel. I think this is is the most common scenario > and justifies the change in default behaviours. > > For the other cases I'd like to introduce some human-readable shortcuts > to the --features option. Eg. 'mkfs.btrfs -O compat-3.2' will pick all > options supported by the unpatched mainline kernel of version 3.2. This > would be present for all version, regardless if there was a change in the > options or not. > > Similarly for convenience, add 'running' that would pick the options > from running kernel but will be explicit. > > A remaining option should override the 'running' behaviour and pick the > latest mkfs options. Naming it 'defaults' sounds a bit ambiguous so the > name is yet to be determined. > > > Here in this set of patches will make sure the progs understands the > > kernel supported features. > > > > So in this patch, checks if sysfs tells whether the feature is > > supported if not, then it will relay on static kernel version which > > provided that feature (skinny-metadata here in this example), next > > if for some reason the running kernel does not provide the kernel > > version, then it will fall back to the original method to enable > > the feature with a hope that kernel will support it. > > > > Also the last patch adds a warning when we fail to read either > > sysfs features or the running kernel version. > > Your patchset is a good start, the additional options I've described can > be added on top of that. We might need to switch the version > representation from string to KERNEL_VERSION but that's an > implementation detail.
Depending on sysfs is stable but depending on kernel version may be not, we may have a distro kernel which backports some incompat features from upstream, then we have to decide based on sysfs interface. However, this brings another problems, for very old kernels, they don't have sysfs, do you have any suggestions for that? Thanks, -liubo > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to [email protected] > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
