Re: Btrfs in fedora 25-26

[Chris Murphy]

On Wed, Sep 7, 2016 at 2:49 PM, Hugo Alejandro <haevalencia(a)gmail.com&gt;
wrote:
>  For a while there was much talk about a replacement for ext4 to
> btrfs, for
>  fedora 23 (desktop)...
>
>  I have not read related news to future releases of fedora workstation and
>  btrfs wiki it seems outdated.
>
>  I have some doubts regarding support for Btrfs in fedora and recommended
>  partitioning through Anaconda. I understand that /boot can be part of a 
btrs
>  partition (GRUB2 claims to have support) but it is not possible to
> set it 
on
>  a clean installation. Are there blockers in fedora workstation to set
btrfs
>  by default? 
In no particular order:

- Too late for Fedora 25, no change proposal.

- For Fedora 26, it needs a change proposal, implies owner(s).

- Who'd own this change?  The upstream maintainer who originally proposed
the Btrfs by default change hasn't been at Red Hat for years, and is not
actively involved in Fedora. The btrfs-progs package owner for Fedora is
busy with XFS and ext4 stuff, and Btrfs isn't something he has much time or
interest in, so that's not a path forward either. Meanwhile Red Hat has
upstream maintainers of LVM and XFS, and developers experienced with XFS
and extX.

- Somewhat stale but 2. and 3. are still valid concerns.
https://lists.fedoraproject.org/pipermail/devel/2015-June/211723.html

- I don't expect Btrfs upstream to ever say "it's ready for Fedora" as
their track record is for downstreams to make their own choices including
what Btrfs features to support. Btrfs is ready when Fedora is ready for
Btrfs. That's the bottom line.


As for bugs:

1. Not a blocker, but an annoying Fedora only bug, grubby doesn't grok
Btrfs subvolumes which is why /boot can't be on Btrfs. If the user wants
their installation encrypted though, /boot ends up on its own volume anyway
because right now the installer doesn't support configuring GRUB to unlock
LUKS volumes.
https://bugzilla.redhat.com/show_bug.cgi?id=864198

2. Probably not a blocker, no resize support in the installer
https://bugzilla.redhat.com/show_bug.cgi?id=962143

3. This becomes a blocker if all three are defaults: btrfs+ostree+grub2
confusion causes install failure
https://bugzilla.redhat.com/show_bug.cgi?id=1289752

But then, much of manual storage config is not tested with rpm-ostree,
plenty of other things could be broken for rpm-ostree installations using
manual storage configs.

A way to use Btrfs that doesn't require kernel knowledge, but still would
need a group of advocates to do the actual work -> Using Btrfs on
installation media. Using seed and sprout device support (which has been
present since forever), replace the cumbersome, slow, half broken
checkisomd5 that most people skip; and the cumbersome, slow, more than half
broken LVM based persistent overlay.

This is not an entirely new idea, it extends from this old thread where its
use was rather incidental to the task:

"btrsquash" images (dracut dmsquash-live + btrfs-in-squashfs runtime) by
Will Woods
https://www.redhat.com/archives/anaconda-devel-list/2011-March/msg00263.html

But side effects not discussed there is Btrfs is always doing a media check
on the fly, every time the media is used; the performance penalty is nil;
the user can't opt out; and it doesn't break like media check does now on
Macs or whenever the image is modified (persistent overlay, user home,
etc). Only a tiny bit of metadata needs to be written to setup read-only
seed, and read writeable sprout on an additional partition rather than an
overlay file, with none of the side effects of the current LVM method
(deleting files doesn't free up space on the overlay, it will blow up
without warning when it gets full, isn't repairable once it blows up, and
all the free space indicators are misleading or wrong).

Things impacted by this: dracut, lorax (livemedia-creator), Fedora Media
Writer, and release engineering. I floated it past Martin Bříza (Fedora
Media Writer) and he likes the idea, but all of these folks have higher
priority work to do than this. I could lead the effort as I'm rather Btrfs
adept including having used the Btrfs seed sprout stuff quite a bit, but I
don't code at all. If stakeholders were shown how this simplifies things
and improves user experience and won't blow shit up elsewhere, they'd
probably sign off on it. But it takes more than an idea for things to
actually happen.


--
Chris Murphy