On Tue, 3 Sep 2013, Frederic Crozat wrote:
Le mardi 03 septembre 2013 ? 10:32 -0400, Jeff Mahoney a ?crit :
Hi all -
Last month I posted queries to this list (and several other locations, including the forums) asking about people's experiences with btrfs. For the most part it seemed like the experience had improved over time. Most of the concerns were either with interactions with zypper or old perceptions of instability that were based more on old impressions than new testing. With the exception of an ENOSPC issue that had been recently fixed, users actively using the file system seemed pretty satisfied with it.
I posted a followup question a week or two later asking what people thought about limiting the 'supported' feature set in the way we do in SLES so that it's clear to all users which parts of the file system are considered stable.
A quick table of what that looks like:
Supported Unsupported --------- ----------- Snapshots Inode cache Copy-on-Write Auto Defrag Subvolumes RAID Metadata Integrity Compression Data Integrity Send / Receive Online metadata scrubbing Hot add/remove Manual defrag Seeding devices Manual deduplication (soon) Multiple devices "Big" Metadata (supported read-only)
Over time this table will change. Items from the Unsupported list will move to the Supported list as they mature.
That proposal was pretty well received except, predictably, by those using the features listed. In practice, all that's required for those users to continue uninterrupted is to add the 'allow_unsupported=1' option to the btrfs module either on the kernel command line or /etc/modprobe.d. There is nothing inherently limiting to any openSUSE user with this practice. The features are all still in the code and available immediately just by setting a flag. It can even be done safely after module load or even after file systems that don't use the unsupported features have been mounted. I intend to introduce this functionality into openSUSE soon.
My main worry with your proposal is the upgrade path, since I would expect some people having enabled some options (compression, autodefrag) on install and forgetting to disable it (or to set the allow_unsupported flag) when doing a "zypper dup" upgrade, ending up with a unbootable system.. (After all, I was using compression until you said it was unstable ;)
Maybe some "trigger" trick should be added when upgrading to the "kernel with unsupported flag", creating a drop-in file in /etc/modprobe.d when unsupported flags are detected in /etc/fstab and displaying a warning (and a link to a webpage giving hints on how to revert to a supported configuration).
I really wonder why this is a kernel module parameter and not a mount option. Is it so that you consider the unsupported features "running" on one filesystem "corrupting" another filesystem that does not use the unsupported features? In the table I also miss a checkbox whether a (un-)supported feature manifests itself in the FS metadata in a way that the FS will not be mountable (R/O?) with the feature "turned off". That is, can the feature set of a filesystem be autodetected at mount time (thus even making the mount option unnecessary as you can simply flag a whole filesystem as unsupported?) As developer whose main filesystem load is compiling GCC I'd be interested in a speed comparison to ext3 (what I happen to be using). I suppose I cannot rely on the btrfs module for this as we ship it in the 3.0.13-0.27-default SLE11 kernel? Thanks, Richard. -- Richard Biener <rguenther@suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org