default file system, was: Comparison to Workstation Technical Specification

Josh Boyer jwboyer at fedoraproject.org
Wed Feb 26 14:24:16 UTC 2014


On Tue, Feb 25, 2014 at 5:53 PM, Chris Murphy <lists at colorremedies.com> wrote:
> adding desktop@ since they are also looking at file system options
>
> On Feb 25, 2014, at 1:42 PM, Stephen Gallagher <sgallagh at redhat.com> wrote:
>
>>> === File system ===
>>>
>>> The default file system type for workstation installs should be
>>> btrfs.
>>
>> The default file system is definitely up for some debate, but I'd make
>> an argument for using XFS atop LVM[1] for the default filesystem in
>> the Fedora Server, at least in part because Red Hat's storage experts
>> have done the research for us already and determined that XFS is the
>> recommended fit for Red Hat Enterprise Linux 7.
>
> 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.

> Follow-up questions:
>
> - Can Server and Workstation WG's choose different defaults for their product's installers?
>
> - Other than lack of shrink support in XFS, I'd say XFS is suitable for Workstation as well. Would the Workstation WG have concerns about the lack of fs shrink support in the default file system? [1]

I don't think shrink support is a factor at all for Workstation.

>> Btrfs still makes me somewhat nervous, given that its upstream doesn't
>> consider it stable[3].
>
> That wiki entry appears old. The stable aspect was about disk format, which is now stable. And also the experimental description was removed in kernel 3.13. [2]
>
> 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.

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

josh


More information about the server mailing list