On Fri, Dec 04, 2015 at 10:08:35AM +0800, Qu Wenruo wrote: > Liu Bo wrote on 2015/12/03 17:44 -0800: > > 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. > > +1. > > Although sysfs does not always show up even for supported kernel, e.g > btrfs modules is not loaded after boot. > So we need to consider twice before choosing a fallback method.
There are several factors that we have to take into account for the default behaviour and fallback. I'm close to a final proposal yet missed the possibility of unloaded module that would remove the access to sysfs, as you point out. -- 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
