Liu Bo wrote on 2015/12/03 18:53 -0800:
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.
However, this brings another problems, for very old kernels, they don't
have sysfs, do you have any suggestions for that?
Other fs, like xfs/ext* doesn't even have sysfs feature interface, only
release announcement mentioning default behavior change.
And I don't see many users complaining about it.
Here is the example of xfsprogs changed its default feature recently:
In 10th, June, 2015, xfsprogs v3.2.3 is released, with new default feature
of enabling CRC for fs.
The first supported kernel is 3.15, which is release in 8th Jun, 2014.
Almost one year ago.
It's the same thing, if you use a earlier version(before v5) xfs and a
v5 xfsprogs, you are not going to mount it.
On the other hand, the sysfs feature is introduced at the end of year 2013.
It's already over 2 years.
So just forgot the extra minor case of super old kernel would be good
enough.
Sorry we're not able to do that since most users won't keep up upgrading their
kernels to the latest one, instead they use the stable one they think.
The fact is that btrfs has way more incompatible features than either ext4 or
xfs,
and no complain on ext4/xfs from them won't solve our btrfs issue anyway.
The problem is much more serious for enterprise users which are sort of
conservative, they would backport what they need, if they use
btrfs they will experience the painful things.
Only if enterprise really think btrfs is stable enough.
For this point, xfs is considered more stable than btrfs, but v5 xfs
recent change doesn't introduce such facility to do that compatibility
check in xfsprogs.
There're plenty of fixes for progs code, people needs stabler recovery
tools rather than new features they may not use.
So we'd like to have a univeral progs code for old kernels.
Overall, btrfs is considered as a fast-moving and not that stable fs (at
least not as stable as ext4/xfs).
And users are always encourages to use latest kernel for these reason.
Shouldn't we do such thing when btrfs is stable enough?
Thanks,
Qu
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
