default file system, was: Comparison to Workstation Technical Specification

[Josh Boyer]

On Wed, Feb 26, 2014 at 3:32 PM, Chris Murphy <lists at colorremedies.com> wrote:
>
> On Feb 26, 2014, at 7:24 AM, Josh Boyer <jwboyer at fedoraproject.org> wrote:
>
>> On Tue, Feb 25, 2014 at 5:53 PM, Chris Murphy <lists at colorremedies.com> wrote:
>>>
>>> XFS is a really good idea for Server.
>>
>> I've yet to actually advocate against this majorly, but I'm pretty
>> against using btrfs as the default for any product.  At least in the
>> F21 timeframe.  It's simply not ready.
>
> Jolla/Sailfish OS use it on mobile phones; openSUSE also considers it ready for their next release, in approximately the same time frame as Fedora 21. Btrfs has been offered as an guided partition path option since Fedora 18. It's been visible in the UI since Fedora 14 or 15. It was first proposed as a default for Fedora 16.

All true.  (Though for clarity, OpenSUSE is offering a reduced feature
mode by default.)

> I think the WG's need to have some metric by which to make a largely objective decision, and should get their questions/concerns addressed directly from Btrfs developers if they're considering it as a default.

I've discussed some of this with the FS team within Red Hat.  I'm
hoping to draw them out of hiding, and I hope they come with data.

> A certain subjectivity is reasonable too, for example whether Fedora Workstation and Server should be biased more toward production/stability, or development/testing than prior Fedoras. I think answering the bias question makes the file system decision more easily fall into place.

Yes, seems fair.

> Cloud, I think they probably want to stick it out with plain partition ext4 due to booting simplicity.
>
>
>
>>> My main two concerns with Btrfs:
>>> 1. With even minor problems users sometimes go straight to the big hammer approach with "btrfsck/btrfs check --repair" rather than the recommended approaches. Remounting with -o recovery, and even using a newer kernel are recommended on linux-btrfs@ significantly more often than btrfs check --repair.
>>
>> That's a pretty poor user experience either way.  The filesystem
>> should be the last thing the user has to worry about, and forcing them
>> to upgrade to get their FS fixed is indicative of btrfs not being
>> ready.
>
> The same recommendation happens on the XFS list too when people having file system problems have old kernels and repair tools. Btrfs is young, and an "old" kernel is maybe only 6-9 months old.

"Young."  7 years is not young when it comes to having repair and
recovery tools, or surviving things like ENOSPC.  I realize _those_
things in btrfs-land actually are young, but that is kind of providing
some of the hesitation on my side.  It took them this long to have
those basic features available?  How long will it take them to have it
so that the corner cases don't break?

>Fedora kernels are kept exceptionally current, as are the btrfs user space tools which is likely why fewer Fedora users have Btrfs problems compared to distributions that use much older kernels.

mmm... I have no way to compare against other distributions.  I'm glad
Fedora is perceived as having better Btrfs support, but I can assure
you it isn't because of any concerted effort on our part. However,
when it comes to bug reports for filesystems in Fedora kernels, btrfs
is by far the leading FS over ext4 or XFS.  Some of this is due to
age, sure.  Most of it is due to sustained effort by a large community
of people for upstream development, and a reduced feature set compared
to btrfs.  In sort, btrfs has a lot of catching up to do, and it's
trying to do that while also leapfrogging everything else.

> Somewhat less often than users immediately trying btrfsck --repair, are users on the XFS list who report having used xfs_repair -L right after a crash instead of first mounting the file system. That's rather damaging too. The offline repair check/repair utility as the first step after a crash is obsolete 10 years ago, yet people still do such things.

People do stupid things after an error.  Yes.  That isn't what I'm
worried about.  I'm worried about hitting those errors to begin with.

> The reality is that the repair tool fixes edge cases, because the file system is designed to not really need one. The common problems either don't happen in the first place, are fixed on a normal mount, or are fixed with the recovery mount option.
>
> My suggestion for the Workstation WG is find out if btrfsck --repair is too often causing worse problem. I don't know the answer to that, but I think it needs to be put directly to Btrfs developers. Any other source is just an anecdote.

I think I'd like to see if anything gets discussed at LFS in a month
or so.  One of the Fedora kernel team members is going to be around,
so hopefully we can get some more information from multiple sources
involved there.

Also, if btrfsck --repair is a major source of problems, and you have
to ask a developer if you'll lose data if you run it, then is the tool
_really_ ready?  I disagree with the assertion that it isn't needed.
The filesystem might be designed to not need one, but either the
design or implementation is lacking enough that it is needed and now
we're left in a fairly _unstable_ state.  That is not what I want as a
default FS.

Please don't mistake my hesitation on using it as the default as being
against Btrfs.  I'm not.  I would love to have it work, work well, and
used as the default.  It allows much more ease of use and interesting
features than anything else.  I simply do not think it is in a state
where that is a safe choice to make.  I do not, as a member of a WG or
a kernel maintainer, want to continually apologize for people losing
data or having unbootable machines because we choose poorly.  If we
get data and comparisons that show otherwise, as you suggested, then I
will be very interested in looking at it as default.

>>> 2. Supporting multiple device volumes in Anaconda. Although multiple device Btrfs volumes work very well when devices are working, there's no device failure notification yet. When a device fails, the volume becomes read-only; and the volume isn't mountable (or bootable) without the use of "degraded" mount option. While this can be done as a boot parameter, it's sort of a non-obvious thing for the typical user. I think it's valid for either WG to consider reducing exposure by dropping Anaconda support for it, or placarding the feature somehow.
>>
>> If, and it's a very big if, Workstation were to go with btrfs, I would
>> really push for a reduced functionality mode similar to what OpenSUSE
>> is doing.  No RAID, no multi-device, etc.
>
> I agree, but to some degree this is up to the WG's and anaconda folks to work out. Today if a user chooses 2+ disks, and the default/Automatic/guided installation path with Partition Scheme set to Btrfs, those drives have data profile raid0, and metadata profile raid1. It's been this way for a while. So what you're suggesting is a change at least to the automatic/easy path for Btrfs, and possibly also a change for Manual/custom, and reads like a distinct shift in bias of Fedora.next to something more production/stability oriented than past Fedoras.

I agree with what you said here entirely.

I also happen to think that one of the major focus of Workstation is
to produce a _product_ that is more stable than past Fedoras.  So
looking at it from that perspective I don't see a reduced feature set
as being that out of line.

josh