Mailinglist Archive: opensuse-factory (776 mails)

< Previous Next >
Re: [opensuse-factory] BtrFS as default fs?
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@xxxxxxx>
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >