On Tue, Feb 25, 2014 at 5:53 PM, Chris Murphy <lists(a)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(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.
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