adding desktop@ since they are also looking at file system options
On Feb 25, 2014, at 1:42 PM, Stephen Gallagher <sgallagh(a)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