Re: Discussion: what would not blocking on btrfs look like?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 23, 2019 at 2:17 PM Adam Williamson
<adamwill@xxxxxxxxxxxxxxxxx> wrote:
>
> Hey folks!
>
> So, there was recently a Thing where btrfs installs were broken, and
> this got accepted as a release blocker:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1733388
>
> The bug was fixed, so that's fine, but along the way, Laura said this:
>
> "I'm strongly against anything with btrfs being a blocker. If that's in
> the criteria I think we should see about removing btrfs simply because
> we don't have the resources to actually deal with btrfs besides
> reporting bugs upstream."
>
> and Justin followed up with:
>
> "Agreed, btrfs has been a gamble pretty much always. See previous
> discussion around proposals to make btrfs default. Ext4 and xfs should
> be the only release blocking."
>
> So, that's the whole kernel team 'strongly against' blocking on btrfs.
> Which means we should talk about not doing that any more!
>
> This is a bit complicated, though, because of how the Final criteria
> are phrased. Basic does not include btrfs at all, and Beta includes a
> laundry list we can just remove btrfs from:
>
> "When using both the installer-native and the blivet-gui-based custom
> partitioning flow, the installer must be able to:
>
> * Correctly interpret, and modify as described below, any disk with a
> valid ms-dos or gpt disk label and partition table containing ext4
> partitions, LVM and/or btrfs volumes, and/or software RAID arrays at
> RAID levels 0, 1 and 5 containing ext4 partitions
> * Create mount points backed by ext4 partitions, LVM volumes or btrfs
> volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing
> ext4 partitions
> ..."
>
> so those two are easy. However, the Final criterion is not laundry
> list-style. The relevant Final criterion is this:
>
> "The installer must be able to create and install to any workable
> partition layout using any file system and/or container format
> combination offered in a default installer configuration."
>
> with a somewhat apologetic explanatory footnote:
>
> "Wait, what?
> Yeah, we know. This is a huge catch-all criterion and it's subject to a
> lot of on-the-fly interpretation. Broadly what it's 'meant to mean' is
> that you should be able to do anything sane that the Installation
> Destination spoke attempts to let you do, without the installer
> exploding or failing. We are trying to write more specific criteria
> covering this area, but it's not easy. Patches welcome, as the kids
> say..."
>
> so as the footnote says, the rule is basically "if the installer lets
> you do it, it ought to work". It seems a bit awkward to craft an
> exception for btrfs from that. I mean, technically it's easy:
>
> "The installer must be able to create and install to any workable
> partition layout using any file system and/or container format
> combination offered in a default installer configuration, except
> btrfs."
>
> but that's odd. Why is btrfs, alone, an exception? It kinda goes
> against the fundamental idea of the criterion: that we stand behind
> everything the UI offers.

All of this, the criteria, and the UI support for btrfs are from the
many years old proposal to make btrfs the default filesystem.  In the
beginning, it was not ready, but did show promise. This proposal came
up for several releases in a row, and at the end of it, even the
upstream developers recommended against it.  At this point, it is safe
to say that btrfs will not be the default.  Since that time, things
have not gotten better.   Yes, there is active btrfs development
upstream.  It is fairly narrowly focused, and not something we can
rely upon for a supported default among the Fedora use cases.  While
Fedora does enable it in the kernel, and plans to continue doing so,
it is enabled in the "if you break it, you get to keep the pieces"
method of many other options. Sure, we will be happy to bring in a
patch that is headed upstream if it fixes a bug, and someone points us
to it.  No, we aren't going to spend time debugging issues with it
ourselves.  There is no shortage of issues in more "core" kernel
pieces that require attention.

> So...what should we do? Here are the options as I see 'em:
>
> 1. Keep supporting btrfs
> 2. Just modify the criterion with a btrfs exception, even if it's weird
> 3. Rewrite the criterion entirely
> 4. Keep btrfs support in the installer (and blivet-gui) but hide it as
> we used to - require a special boot argument for it to be visible
> 5. Drop btrfs support from the installer
>
I would opt for 4 or 5, and would be in full support of 5.  I do not
think that it can (or should) be dropped from the kernel, because we
don't want to cut off existing users, and it can still be a useful
filesystem for specific cases.

> I'm bringing this to anaconda, kernel and test teams initially to kick
> around; if we agree on an approach we should then probably loop in
> devel@ for wider review, unless the choice is 1).
>
> Thanks for any thoughts, folks!
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> _______________________________________________
> test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list



[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux