default file system, was: Comparison to Workstation Technical Specification

[Liam]

On Feb 25, 2014 6:04 PM, "Adam Williamson" <awilliam at redhat.com> wrote:
>
> On Tue, 2014-02-25 at 15:53 -0700, Chris Murphy 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.
> >
> > Follow-up questions:
> >
> > - Can Server and Workstation WG's choose different defaults for their
> > product's installers?
>
> Given my understanding of anaconda's architecture I don't believe this
> would *technically* present a significant problem. anaconda already has
> the concept of being used to install different products, and using
> different defaults for various things depending on what product it's
> being used to install: this is how RHEL can have different defaults from
> Fedora.
>
> It would be best to ask the anaconda devs, though. Maybe they think it's
> a horrible hack and don't want to extend it any further than their
> paychecks require. CCing bcl and dcantrell.
>
> In terms of *policy*, it'd be up to FESCo, I guess. It seems like a
> perfectly reasonable point of variance between products to me.
>
> > - 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]
>
> <snip>
>
> In addition to Chris' points, we discussed btrfs at this week's QA
> meeting, and agreed that even though it's really not QA's 'job', it
> seems sensible to just check if Desktop WG has talked to the devs who
> have, up until now, been taking the job of deciding when btrfs is 'ready
> for primetime' and developed a plan. Is the btrfs-by-default part of the
> current tech spec more of a long term aspiration, or is it on the table
> for F21? Have the concerns about its readiness been evaluated and
> checked with the domain experts?
>
> Thanks!
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
> --
> desktop mailing list
> desktop at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/desktop

Just wanted to mention that btrfs still seems to have some pretty horrific
issues with some db/logging situations. A couple of days ago I came across
a problem (with a bug already reported) with journald. The problem seems to
be a combination of journald either needing much lower defaults for max
size (mine was around 4G), or to not have to read the entire freaking log
before it's able to a reverse sort, and btrfs.
I'm honestly not sure those small write problems are solvable unless they
occur only infrequently, and I care less about performance than data
integrity (with send/receive being great bonuses).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/desktop/attachments/20140226/d48e3ab8/attachment-0001.html>