Ok, thank you very much for giving me such complete information. I see that
the short and medium term (even long-term) will not be an option for fedora
workstation.
Reading information btrfs seems a very advanced file system, but if the core
fedora is not ready (and will not) change, I prefer to keep using ext4 and keep
my data safe.
cheers
2016-09-08 16:34 GMT-03:00 Chris Murphy <lists(a)colorremedies.com>:
On Wed, Sep 7, 2016 at 2:49 PM, Hugo Alejandro <haevalencia(a)gmail.com>
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
--
desktop mailing list
desktop(a)lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/desktop@lists.
fedoraproject.org