Fwd: BtrFS as default fs?

Btrfs has been officially proposed as default filesystem for 13.1.

If you have comments on this, you’d better make them on that thread in
the factory mail list. I only forward the post here for your reference.

Carlos E.R.

-------- Original Message --------
Subject: [opensuse-factory] BtrFS as default fs?
Date: Tue, 03 Sep 2013 10:32:48 -0400
From: Jeff Mahoney <>
To: opensuse-factory@opensuse.org, openSUSE Kernel ML
<opensuse-kernel@opensuse.org>

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.

One other aspect to consider: Even though they are independent projects,
we’ve been focusing heavily on btrfs support in the SLES product. As a
result, the openSUSE kernel will end up getting much of that work ‘for
free’ since most of the same people maintain the kernel for both projects.

So that’s the “why it’s safe” part of the proposal. I haven’t gotten to
the “why” yet, but then you probably already know the “whys”.
Subvolumes. Built-in snapshots that don’t corrupt themselves when an
exception table runs out of space. Built-in integrity verification via
checksums. Built-in proactive metadata semantic checking via scrubbing.
Online defrag. Soon we’ll see online deduplication of arbitrary
combinations of files. The code is written, it just needs to be pulled
in. You’ve seen the rest of the feature set. Once we test more of it
under load and ensure that it’s mature enough to roll out, you’ll get
those features for free.

So, I’d like to propose that we use btrfs as the default file system for
the 13.1 release before we release the first beta.

Thanks for your time.

-Jeff


Jeff Mahoney
SUSE Labs

That’s a long discussion (on the factory mailing list). Most of my concerns have been raised, so I won’t participate.

I suppose I should think about whether to switch to btrfs (for the root file system only).

On 2013-09-04 01:24, Carlos E. R. wrote:
>
> Btrfs has been officially proposed as default filesystem for 13.1.

And Stephan Kulow has vetoed it.

+++·······················
Sorry, but if you read the roadmap more carefully, you see that we’re
way past the time to change important details as that. For convenience
I include a pointer: http://en.opensuse.org/openSUSE:Roadmap

You’re free to offer your help to the marketing team to promote btrfs
as perfect choice for experienced users and we switch early for 13.2.
That’s the best I’m willing to offer.
·······················+±

So, not yet.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

On 2013-09-04 03:36, nrickert wrote:

> That’s a long discussion (on the factory mailing list). Most of my
> concerns have been raised, so I won’t participate.

Indeed, long one in a day.

> I suppose I should think about whether to switch to btrfs (for the root
> file system only).

The feature that most interests me (compression) is not deemed
production ready by them. I wanted to do my backups compressed on
another disk.

Anyway, Kulow has decided: not this time, too late for feature inclusion.

I don’t know if I’m happy or not.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

I haven’t read the mail thread yet, but thanks for the alert. As soon as I read the proposal and having looked at the roadmap only yesterday, it was clearly too late for such a serious change. Why would you be happy or not with a non-default status - assuming you can still play with it? :\

Not you, or me, or many here, because they have already decided what to do and know how to avoid a default. But all new openSUSE users will use the default, because they will think it is the best, else it wouldn’t be the default. And the forums then should be ready to answer different then: Sorry, better use ext4 when you want to be stable.

In other words: all problems will land here in the forums.

;).

I should have worded the question more clearly for quoting separately, as in “Why wouldn’t you be happy that btrfs will not be the last-minute default file system?”. It would certainly have adverse consequences if it were made default at this stage. Not only would new openSUSE users take the default, but some wouldn’t ask any questions, read the release notes or any other documentation first.

Carlos E. R. wrote:
>
> Btrfs has been officially proposed as default filesystem for 13.1.
>
> If you have comments on this, you’d better make them on that thread in
> the factory mail list. I only forward the post here for your reference.
>
> Carlos E.R.
>
> -------- Original Message --------
> Subject: [opensuse-factory] BtrFS as default fs?
> Date: Tue, 03 Sep 2013 10:32:48 -0400
> From: Jeff Mahoney <>
> To: opensuse-factory@opensuse.org, openSUSE Kernel ML
> <opensuse-kernel@opensuse.org>
>
>
>
> 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.
>
> One other aspect to consider: Even though they are independent projects,
> we’ve been focusing heavily on btrfs support in the SLES product. As a
> result, the openSUSE kernel will end up getting much of that work ‘for
> free’ since most of the same people maintain the kernel for both projects.
>
> So that’s the “why it’s safe” part of the proposal. I haven’t gotten to
> the “why” yet, but then you probably already know the “whys”.
> Subvolumes. Built-in snapshots that don’t corrupt themselves when an
> exception table runs out of space. Built-in integrity verification via
> checksums. Built-in proactive metadata semantic checking via scrubbing.
> Online defrag. Soon we’ll see online deduplication of arbitrary
> combinations of files. The code is written, it just needs to be pulled
> in. You’ve seen the rest of the feature set. Once we test more of it
> under load and ensure that it’s mature enough to roll out, you’ll get
> those features for free.
>
> So, I’d like to propose that we use btrfs as the default file system for
> the 13.1 release before we release the first beta.
>
> Thanks for your time.
>
> -Jeff
>
>
Now all plans to make 13.1 into a evergreen release will go down the
drain :slight_smile:


GNOME 3.6.2
openSUSE Release 12.3 (Dartmouth) 64-bit
Kernel Linux 3.7.10-1.16-desktop

I couldn’t find anything in your long re-quote to match that comment. Did I miss something. lol!

On 2013-09-04 16:16, consused wrote:
> Why would you be happy
> or not with a non-default status - assuming you can still play with it?
> :\

It means that I have not made a decision within myself.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

On 2013-09-04 20:26, consused wrote:
>
> vazhavandan;2582795 Wrote:
>>
>> Now all plans to make 13.1 into a evergreen release will go down the
>> drain :slight_smile:
> I couldn’t find anything in your long re-quote to match that comment.
> Did I miss something. lol!

Probably because users of Evergreen want long term comfort. As in
reliable, not experimental. Allowing btrfs smells of caution.


Cheers / Saludos,

Carlos E. R.
(from 11.4, with Evergreen, x86_64 “Celadon” (Minas Tirith))

That seems good to me.

For this kind of change, it should be announced in one release as an intended direction for the next. So maybe something could go into Release-Notes about future plans.

To expand on my earlier comment – using btrfs for root might be worth a try. If there’s a problem, it is easy enough to reinstall using ext4. But I would not use it on “/home” at present. That’s where the data is that I don’t want to risk.

I knew what it meant, but the key decision is made. The guinea-pigs will have to opt in, and Evergreen’s official stability will be unaffected by it. :slight_smile:

On 2013-09-04 21:46, consused wrote:
>
> robin_listas;2582816 Wrote:

>> It means that I have not made a decision within myself.

> I knew what it meant, but the key decision is made. The guinea-pigs will
> have to opt in, and Evergreen’s official stability will be unaffected by
> it. :slight_smile:

Yes, but that’s not the decision I was talking about.
I have to decide whether I like it or not :slight_smile:
In other words, I have no opinion yet.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

On 2013-09-04 21:16, nrickert wrote:

> For this kind of change, it should be announced in one release as an
> intended direction for the next. So maybe something could go into
> Release-Notes about future plans.

Yes, it is too late. It means also changes in the installer that can not
be done.

> To expand on my earlier comment – using btrfs for root might be worth a
> try. If there’s a problem, it is easy enough to reinstall using ext4.
> But I would not use it on “/home” at present. That’s where the data is
> that I don’t want to risk.

In my case, root is a lot of work to redo.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

On 2013-09-04 21:05, Carlos E. R. wrote:
> On 2013-09-04 20:26, consused wrote:
>>
>> vazhavandan;2582795 Wrote:
>>>
>>> Now all plans to make 13.1 into a evergreen release will go down the
>>> drain :slight_smile:
>> I couldn’t find anything in your long re-quote to match that comment.
>> Did I miss something. lol!
>
> Probably because users of Evergreen want long term comfort. As in
> reliable, not experimental. Allowing btrfs smells of caution.

makes no sense that last word I wrote. But I don’t remember what other
word I wanted to say… :frowning:


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

I decided to try btrfs. I can’t prove it is the cause, but out of 100 or so openSUSE installs I have an issue with pulseaudio permissions now.

I don’t notice any performance problems, but I am not sure if snapper is useful.

consused wrote:
>
> vazhavandan;2582795 Wrote:
>>
>> Now all plans to make 13.1 into a evergreen release will go down the
>> drain :slight_smile:
> I couldn’t find anything in your long re-quote to match that comment.
> Did I miss something. lol!
>
>
13.1 was probably chosen as Evergreen because a lot of new technologies
introduced in openSUSE 12.x series (systemd,GOME 3.X,…) would have
been stabilised, but if 13.1 will use btfrs then the Evergreen team
might need go back to their drawing boards.

Side note:- I meant to make a post in the thread. I should probably
learn to snip stuff and post when quoting stuff is not necessary.
nntp will take some time to get used to.

GNOME 3.6.2
openSUSE Release 12.3 (Dartmouth) 64-bit
Kernel Linux 3.7.10-1.16-desktop

On 2013-09-05 03:57, vazhavandan wrote:
> 13.1 was probably chosen as Evergreen because a lot of new technologies
> introduced in openSUSE 12.x series (systemd,GOME 3.X,…) would have
> been stabilised, but if 13.1 will use btfrs then the Evergreen team
> might need go back to their drawing boards.

Or not.

Many of the evergreen users are old hands or sysadmins. We know not to
install defaults no matter what their proponents say :wink:


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Yes, but the only decision right now that matters is “not this time”, giving you time for contemplation. Being undecided (perhaps like the majority of openSUSE users) is a happy position compared to being disappointed either by the decision or soon after release through adverse consequences. :slight_smile: