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 https://fedoraproject.org/wiki/Btrfs.
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?
Cheers
On Wed, Sep 7, 2016 at 2:49 PM, Hugo Alejandro haevalencia@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
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@colorremedies.com:
On Wed, Sep 7, 2016 at 2:49 PM, Hugo Alejandro haevalencia@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:
- 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
- Probably not a blocker, no resize support in the installer
https://bugzilla.redhat.com/show_bug.cgi?id=962143
- 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@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/desktop@lists. fedoraproject.org
desktop@lists.fedoraproject.org
-
Chris Murphy -
Hugo Alejandro