BtrFS as default fs?

classic Classic list List threaded Threaded
92 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

BtrFS as default fs?

Jeff Mahoney
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


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: BtrFS as default fs?

Frederic Crozat-4
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).

> 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.

I support this !

--
Frederic Crozat <[hidden email]>
SUSE

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: BtrFS as default fs?

Jeff Mahoney
On 9/3/13 10:41 AM, 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 ;)
Of course. We definitely don't want to break existing users.

> 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).

Yeah, this is definitely doable. Can we get the YaST team on board with
adding that notification and support?

>> 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.
>
> I support this !

Thanks!

-Jeff


--
Jeff Mahoney
SUSE Labs


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: BtrFS as default fs?

Stefan Seyfried
Am 03.09.2013 16:44, schrieb Jeff Mahoney:

>> 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).
>
> Yeah, this is definitely doable. Can we get the YaST team on board with
> adding that notification and support?

Wouldn't it be enough to have the kernel panic with a descriptive
message when the allow_unsupported is needed for the rootfs but not set?

Seems less work :-)

And I personally don't like auto-enabling of "dangerous" features
without my interaction. But that's just my opinion.

--
Stefan Seyfried
"If your lighter runs out of fluid or flint and stops making
 fire, and you can't be bothered to figure out about lighter
 fluid or flint, that is not Zippo's fault." -- bkw
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: BtrFS as default fs?

Arvin Schnell
In reply to this post by Jeff Mahoney
On Tue, Sep 03, 2013 at 10:44:14AM -0400, Jeff Mahoney wrote:
> On 9/3/13 10:41 AM, Frederic Crozat wrote:
> > Le mardi 03 septembre 2013 à 10:32 -0400, Jeff Mahoney a écrit :

> >> 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 ;)
>
> Of course. We definitely don't want to break existing users.
>
> > 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).
>
> Yeah, this is definitely doable. Can we get the YaST team on board with
> adding that notification and support?

YaST doesn't run when using "zupper dup". The right place for
such functionality is a RPM script from my POV.

Regards,
  Arvin

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: BtrFS as default fs?

Olaf Hering-2
In reply to this post by Jeff Mahoney
On Tue, Sep 03, Jeff Mahoney wrote:

> Supported                      Unsupported
> ---------                      -----------
> Snapshots                      Inode cache


In the past the snapshots were enabled automatically. I once installed a
VM with just a 20G disk and soon this small disk was filled up after
some zypper patch/dup calls. It was not immediately obvious why the root
filesystem ran out of space. Google pointed to snapper and somehow I
managed to remove the (unwanted) snapshots.


Unless the snapshot handling has improved to not suddenly fillup the
disk during ordinary usage I suggest to disable them per default. Maybe
add a big red button in the installer proposal to easily enable/disable
them.

Up to now it was easy to install a system/VM by just clicking
Next/Next/+ and get system that continues to work without further
interaction. With enabled snapshots this experience would break.

Olaf
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] BtrFS as default fs?

Cristian Rodríguez-2
In reply to this post by Jeff Mahoney
El 03/09/13 10:32, Jeff Mahoney escribió:
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.

That's not gonna fly, I will fight that to death, please do not add
enterprise crippling module parameters to openSUSE, it *really* does not
belong there at all. that's absolutely insane.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: BtrFS as default fs?

Lars Müller-2
In reply to this post by Stefan Seyfried
On Tue, Sep 03, 2013 at 04:54:46PM +0200, Stefan Seyfried wrote:

> Am 03.09.2013 16:44, schrieb Jeff Mahoney:
>
> >> 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).
> >
> > Yeah, this is definitely doable. Can we get the YaST team on board with
> > adding that notification and support?
>
> Wouldn't it be enough to have the kernel panic with a descriptive
> message when the allow_unsupported is needed for the rootfs but not set?
Which might not be the best approach for remotely operated systems.

> Seems less work :-)
>
> And I personally don't like auto-enabling of "dangerous" features
> without my interaction. But that's just my opinion.

Then we need a notification mechanism which is independent from YaST and
libzypp as Arvin suggested in his reply.

Cheers,

Lars
--
Lars Müller [ˈlaː(r)z ˈmʏlɐ]
Samba Team + SUSE Labs
SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany

signature.asc (197 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] BtrFS as default fs?

Arvin Schnell
In reply to this post by Jeff Mahoney
On Tue, Sep 03, 2013 at 10:32:48AM -0400, Jeff Mahoney wrote:

> 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)

What about quota groups?

Regards,
  Arvin

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] BtrFS as default fs?

Jeff Mahoney
On 9/3/13 11:25 AM, Arvin Schnell wrote:

> On Tue, Sep 03, 2013 at 10:32:48AM -0400, Jeff Mahoney wrote:
>> 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)
>
> What about quota groups?
Oops, yep. Quota groups are supported too.

-Jeff

--
Jeff Mahoney
SUSE Labs


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] BtrFS as default fs?

Cristian Rodríguez-2
In reply to this post by Jeff Mahoney
El 03/09/13 11:53, Jeff Mahoney escribió:


> As I said then, the point isn't to take away functionality from anyone.
> If we have the ability to enable it in YaST (with a warning)
or do it

> automatically (with a warning) if the features are already enabled on an
> older file system, nobody's lost anything. The point is that it will
> prevent users from losing their file systems using a feature set that
> hasn't been well tested.
>
> It's great that you want to try features out that we don't consider safe
> yet. That's how we get bug reports that we can use to improve and
> further gauge the quality of a particular feature set. I just don't
> think that /all/ openSUSE users want to have that particular experience
> without knowing what's up beforehand.

Jeff, I do not object to the idea of warning people that certain
features are unstable or dangerous a log message: "btrfs warning: FOOBAR
is unstable".. will suffice in achiving this result. what I do strongly
object is this pervasive tendency to add SUSE specific flags that are
not documented anywhere else other than probably a wiki page or the
openSUSE documentation, has distribution specific semantics,is not in
upstream plus will cause confusion and increase the load of volunteers
that answer questions in mailing list and the forums.

This makes sense for SLE where you only want to support things known to
be production quality and therefore reducing the number of support
incidents. in the openSUSE land will only cause confusion (pretty much
like the "unsupported module flag")





--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: BtrFS as default fs?

Yamaban
In reply to this post by Jeff Mahoney
On Tue, 3 Sep 2013 16:32, Jeff Mahoney <jeffm@...> wrote:
[snip]
> 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.

To spare us all a rush of headaches, a couple of points to add:

  - Be aware that not every bootloader does supports btrfs for /boot
    (lilo, syslinux, ...)

  - For the Yast installer: Select bootloader before partitioning /
    root-fs selection, be prepared to 'propose' a extra /boot partition
    for non-btrfs aware bootloaders.

Make sure that these points land in the printed manual, and the wiki.

  - Yamaban.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] BtrFS as default fs?

Jeff Mahoney
In reply to this post by Cristian Rodríguez-2
On 9/3/13 12:24 PM, Cristian Rodríguez wrote:

> El 03/09/13 11:53, Jeff Mahoney escribió:
>
>
>> As I said then, the point isn't to take away functionality from anyone.
>> If we have the ability to enable it in YaST (with a warning)
> or do it
>> automatically (with a warning) if the features are already enabled on an
>> older file system, nobody's lost anything. The point is that it will
>> prevent users from losing their file systems using a feature set that
>> hasn't been well tested.
>>
>> It's great that you want to try features out that we don't consider safe
>> yet. That's how we get bug reports that we can use to improve and
>> further gauge the quality of a particular feature set. I just don't
>> think that /all/ openSUSE users want to have that particular experience
>> without knowing what's up beforehand.
>
> Jeff, I do not object to the idea of warning people that certain
> features are unstable or dangerous a log message: "btrfs warning: FOOBAR
> is unstable".. will suffice in achiving this result. what I do strongly
> object is this pervasive tendency to add SUSE specific flags that are
> not documented anywhere else other than probably a wiki page or the
> openSUSE documentation, has distribution specific semantics,is not in
> upstream plus will cause confusion and increase the load of volunteers
> that answer questions in mailing list and the forums.
Your approach is favoring the experienced user over the inexperienced
user, which can be reasonable especially if that's where we want to
focus as a project. But it's dangerous when you also suggest a
completely unintuitive method of informing the user. Nobody checks the
log after successfully mounting a file system to see if there were any
warnings. Documenting that in the release notes as a "best practice"
isn't going to fly either. People do check the log when something
unexpected happens and that's why we issue a message like the following
when we reject a mount with immature features:

"btrfs: compression is not supported, load module with allow_unsupported=1"

(We can change the wording of that for openSUSE so that it reads
"compression is considered an immature feature, load module with
allow_unsupported=1".)

I'm not sure many users will be comforted by being asked if they see a
warning in their log after they've used an immature feature and
discovered the hard way why it's considered immature.

That's why I think an automated approach during upgrade and a yast
checkbox to allow unsupported features is the way to go. Experienced
users still get the full feature set to play with. Users with existing
file systems with immature features enabled get to continue using
them[1]. Inexperienced users get a reasonable picture of what is
considered mature and what isn't and enjoy better data safety as a result.

I'd prefer a better name than "allow_unsupported" but since this feature
comes from SLES, it's better to use the existing name than to introduce
another incompatibility.

> This makes sense for SLE where you only want to support things known to
> be production quality and therefore reducing the number of support
> incidents. in the openSUSE land will only cause confusion (pretty much
> like the "unsupported module flag")

The unsupported module flag was removed from openSUSE for exactly that
reason.

This case is different, though. This isn't about managing support cases.
Well, I suppose it is, but that's a nice side-effect of ensuring that
users expecting that their file system uses only mature features have
their expectations met. The naming of the module option is independent
of the meaning of the option. That's largely a messaging thing and in
the UI, it should be presented as "unstable" or "immature" feature
enablement rather than trying to make a distinction over supportability.

-Jeff

[1] With the exception of file systems not in /etc/fstab.

--
Jeff Mahoney
SUSE Labs


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] BtrFS as default fs?

Roman Bysh
On Tue 03 Sep 2013 01:26:38 PM EDT, Jeff Mahoney wrote:

> On 9/3/13 12:24 PM, Cristian Rodríguez wrote:
>> El 03/09/13 11:53, Jeff Mahoney escribió:
>>
>>
>>> As I said then, the point isn't to take away functionality from anyone.
>>> If we have the ability to enable it in YaST (with a warning)
>> or do it
>>> automatically (with a warning) if the features are already enabled on an
>>> older file system, nobody's lost anything. The point is that it will
>>> prevent users from losing their file systems using a feature set that
>>> hasn't been well tested.
>>>
>>> It's great that you want to try features out that we don't consider safe
>>> yet. That's how we get bug reports that we can use to improve and
>>> further gauge the quality of a particular feature set. I just don't
>>> think that /all/ openSUSE users want to have that particular experience
>>> without knowing what's up beforehand.
>>
>> Jeff, I do not object to the idea of warning people that certain
>> features are unstable or dangerous a log message: "btrfs warning: FOOBAR
>> is unstable".. will suffice in achiving this result. what I do strongly
>> object is this pervasive tendency to add SUSE specific flags that are
>> not documented anywhere else other than probably a wiki page or the
>> openSUSE documentation, has distribution specific semantics,is not in
>> upstream plus will cause confusion and increase the load of volunteers
>> that answer questions in mailing list and the forums.
>
> Your approach is favoring the experienced user over the inexperienced
> user, which can be reasonable especially if that's where we want to
> focus as a project. But it's dangerous when you also suggest a
> completely unintuitive method of informing the user. Nobody checks the
> log after successfully mounting a file system to see if there were any
> warnings. Documenting that in the release notes as a "best practice"
> isn't going to fly either. People do check the log when something
> unexpected happens and that's why we issue a message like the following
> when we reject a mount with immature features:
>
> "btrfs: compression is not supported, load module with allow_unsupported=1"
>
> (We can change the wording of that for openSUSE so that it reads
> "compression is considered an immature feature, load module with
> allow_unsupported=1".)
>
> I'm not sure many users will be comforted by being asked if they see a
> warning in their log after they've used an immature feature and
> discovered the hard way why it's considered immature.
>
> That's why I think an automated approach during upgrade and a yast
> checkbox to allow unsupported features is the way to go. Experienced
> users still get the full feature set to play with. Users with existing
> file systems with immature features enabled get to continue using
> them[1]. Inexperienced users get a reasonable picture of what is
> considered mature and what isn't and enjoy better data safety as a result.
>
> I'd prefer a better name than "allow_unsupported" but since this feature
> comes from SLES, it's better to use the existing name than to introduce
> another incompatibility.
>
>> This makes sense for SLE where you only want to support things known to
>> be production quality and therefore reducing the number of support
>> incidents. in the openSUSE land will only cause confusion (pretty much
>> like the "unsupported module flag")
>
> The unsupported module flag was removed from openSUSE for exactly that
> reason.
>
> This case is different, though. This isn't about managing support cases.
> Well, I suppose it is, but that's a nice side-effect of ensuring that
> users expecting that their file system uses only mature features have
> their expectations met. The naming of the module option is independent
> of the meaning of the option. That's largely a messaging thing and in
> the UI, it should be presented as "unstable" or "immature" feature
> enablement rather than trying to make a distinction over supportability.
>
> -Jeff
>
> [1] With the exception of file systems not in /etc/fstab.
>

How does it handle a computer that looses power versus EXT4?

--
Cheers!

Roman
-------------------------------------------------------
openSUSE -- Get it! Discover it! Share it!
-------------------------------------------------------
http://linuxcounter.net/    #179293
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: BtrFS as default fs?

Roman Bysh
In reply to this post by Yamaban
On 09/03/2013 12:26 PM, Yamaban wrote:

> On Tue, 3 Sep 2013 16:32, Jeff Mahoney <jeffm@...> wrote:
> [snip]
>> 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.
>
> To spare us all a rush of headaches, a couple of points to add:
>
>   - Be aware that not every bootloader does supports btrfs for /boot
>     (lilo, syslinux, ...)
>
>   - For the Yast installer: Select bootloader before partitioning /
>     root-fs selection, be prepared to 'propose' a extra /boot partition
>     for non-btrfs aware bootloaders.
>
> Make sure that these points land in the printed manual, and the wiki.
>
>   - Yamaban.
>
Doesn't btrfs support booting the system without a /boot partition?

--
Cheers!

Roman

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [opensuse-kernel] BtrFS as default fs?

Jeff Mahoney
In reply to this post by Roman Bysh
On 9/3/13 2:16 PM, Roman Bysh wrote:

> On Tue 03 Sep 2013 01:26:38 PM EDT, Jeff Mahoney wrote:
>> On 9/3/13 12:24 PM, Cristian Rodríguez wrote:
>>> El 03/09/13 11:53, Jeff Mahoney escribió:
>>>
>>>
>>>> As I said then, the point isn't to take away functionality from anyone.
>>>> If we have the ability to enable it in YaST (with a warning)
>>> or do it
>>>> automatically (with a warning) if the features are already enabled
>>>> on an
>>>> older file system, nobody's lost anything. The point is that it will
>>>> prevent users from losing their file systems using a feature set that
>>>> hasn't been well tested.
>>>>
>>>> It's great that you want to try features out that we don't consider
>>>> safe
>>>> yet. That's how we get bug reports that we can use to improve and
>>>> further gauge the quality of a particular feature set. I just don't
>>>> think that /all/ openSUSE users want to have that particular experience
>>>> without knowing what's up beforehand.
>>>
>>> Jeff, I do not object to the idea of warning people that certain
>>> features are unstable or dangerous a log message: "btrfs warning: FOOBAR
>>> is unstable".. will suffice in achiving this result. what I do strongly
>>> object is this pervasive tendency to add SUSE specific flags that are
>>> not documented anywhere else other than probably a wiki page or the
>>> openSUSE documentation, has distribution specific semantics,is not in
>>> upstream plus will cause confusion and increase the load of volunteers
>>> that answer questions in mailing list and the forums.
>>
>> Your approach is favoring the experienced user over the inexperienced
>> user, which can be reasonable especially if that's where we want to
>> focus as a project. But it's dangerous when you also suggest a
>> completely unintuitive method of informing the user. Nobody checks the
>> log after successfully mounting a file system to see if there were any
>> warnings. Documenting that in the release notes as a "best practice"
>> isn't going to fly either. People do check the log when something
>> unexpected happens and that's why we issue a message like the following
>> when we reject a mount with immature features:
>>
>> "btrfs: compression is not supported, load module with
>> allow_unsupported=1"
>>
>> (We can change the wording of that for openSUSE so that it reads
>> "compression is considered an immature feature, load module with
>> allow_unsupported=1".)
>>
>> I'm not sure many users will be comforted by being asked if they see a
>> warning in their log after they've used an immature feature and
>> discovered the hard way why it's considered immature.
>>
>> That's why I think an automated approach during upgrade and a yast
>> checkbox to allow unsupported features is the way to go. Experienced
>> users still get the full feature set to play with. Users with existing
>> file systems with immature features enabled get to continue using
>> them[1]. Inexperienced users get a reasonable picture of what is
>> considered mature and what isn't and enjoy better data safety as a
>> result.
>>
>> I'd prefer a better name than "allow_unsupported" but since this feature
>> comes from SLES, it's better to use the existing name than to introduce
>> another incompatibility.
>>
>>> This makes sense for SLE where you only want to support things known to
>>> be production quality and therefore reducing the number of support
>>> incidents. in the openSUSE land will only cause confusion (pretty much
>>> like the "unsupported module flag")
>>
>> The unsupported module flag was removed from openSUSE for exactly that
>> reason.
>>
>> This case is different, though. This isn't about managing support cases.
>> Well, I suppose it is, but that's a nice side-effect of ensuring that
>> users expecting that their file system uses only mature features have
>> their expectations met. The naming of the module option is independent
>> of the meaning of the option. That's largely a messaging thing and in
>> the UI, it should be presented as "unstable" or "immature" feature
>> enablement rather than trying to make a distinction over supportability.
>>
>> -Jeff
>>
>> [1] With the exception of file systems not in /etc/fstab.
>>
>
> How does it handle a computer that looses power versus EXT4?
It's designed to be safe in that case. The CoW behavior means that the
old blocks aren't overwritten until the refcount drops to zero. The
refcount can't drop to zero until the new blocks are safely on disk.

-Jeff

--
Jeff Mahoney
SUSE Labs


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: BtrFS as default fs?

Jeff Mahoney
In reply to this post by Roman Bysh
On 9/3/13 2:22 PM, Roman Bysh wrote:

> On 09/03/2013 12:26 PM, Yamaban wrote:
>> On Tue, 3 Sep 2013 16:32, Jeff Mahoney <jeffm@...> wrote:
>> [snip]
>>> 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.
>>
>> To spare us all a rush of headaches, a couple of points to add:
>>
>>   - Be aware that not every bootloader does supports btrfs for /boot
>>     (lilo, syslinux, ...)
>>
>>   - For the Yast installer: Select bootloader before partitioning /
>>     root-fs selection, be prepared to 'propose' a extra /boot partition
>>     for non-btrfs aware bootloaders.
>>
>> Make sure that these points land in the printed manual, and the wiki.
>>
>>   - Yamaban.
>>
> Doesn't btrfs support booting the system without a /boot partition?
>
Yes, but his point was that while GRUB2 supports it (and GRUB1 with
patches, I forget if we're carrying those), other boot loaders may not
and YaST should be intelligent enough to know which ones don't. That's
where the separate /boot comes in.

-Jeff

--
Jeff Mahoney
SUSE Labs


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: BtrFS as default fs?

Ken Schneider - openSUSE
In reply to this post by Jeff Mahoney
On 09/03/2013 10:32 AM, Jeff Mahoney pecked at the keyboard and wrote:

> 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
>
>

Not as long as any items are in the unsupported colume and as long as
there is no tool to repair a broken filesystem.

--
Ken Schneider
SuSe since Version 5.2, June 1998
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: BtrFS as default fs?

Jeff Mahoney
On 9/3/13 2:54 PM, Ken Schneider - openSUSE wrote:

> On 09/03/2013 10:32 AM, Jeff Mahoney pecked at the keyboard and wrote:
>> 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
>>
>>
>
> Not as long as any items are in the unsupported colume and as long as
The unsupported features might as well be "unimplemented" for the
purposes of this discussion.

> there is no tool to repair a broken filesystem.

There is a btrfsck tool. Have you encountered a file system it was
unable to repair? Bugzilla IDs? The tool can only improve with the
reporting of different types of corruption. Even e2fsck still receives
regular updates.

-Jeff

--
Jeff Mahoney
SUSE Labs


signature.asc (858 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: Re: BtrFS as default fs?

Yamaban
In reply to this post by Roman Bysh
On Tue, 3 Sep 2013 20:22, Roman Bysh <rbtc1@...> wrote:

> On 09/03/2013 12:26 PM, Yamaban wrote:
>> On Tue, 3 Sep 2013 16:32, Jeff Mahoney <jeffm@...> wrote:
>> [snip]
>>> 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.
>>
>> To spare us all a rush of headaches, a couple of points to add:
>>
>>   - Be aware that not every bootloader does supports btrfs for /boot
>>     (lilo, syslinux, ...)
>>
>>   - For the Yast installer: Select bootloader before partitioning /
>>     root-fs selection, be prepared to 'propose' a extra /boot partition
>>     for non-btrfs aware bootloaders.
>>
>> Make sure that these points land in the printed manual, and the wiki.
>>
>>   - Yamaban.
>>
> Doesn't btrfs support booting the system without a /boot partition?

It's a matter of the bootloader.

If the bootloader supports btrfs for /boot, e.g grub2, gummiboot, ...
no extra partition for /boot needed, all other bootloader will
NEED a /boot partiton that is NOT btrfs, but e.g. ext[234]-fs.

For at least another 7-12 years boot via BIOS will matter.
And not all BIOS capable bootloader support btrfs for /boot.

Personally, I have a well founded HATE for grub and grub2,
and I'm not alone in that.

  - Yamaban.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

12345