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. -- 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
