Mailinglist Archive: opensuse-factory (776 mails)

< Previous Next >
Re: [opensuse-factory] Re: [opensuse-kernel] BtrFS as default fs?
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

< Previous Next >