default file system, was: Comparison to Workstation Technical Specification

[Chris Murphy]

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.

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]

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

It's a fair question how fail safe the offline repair utility currently is, and should be. In my monitoring of linux-btrfs@, even if btrfs check --repair made things worse, the offline btrfs restore utility enabled files to be extracted.

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.


[1] LVM Thin Provisioning, if ready for production prime time as a default, is a work around. It's actually better than fs resize anyway.

[2] http://www.mail-archive.com/linux-btrfs%40vger.kernel.org/msg29945.html



Chris Murphy