This is a consolidated post, responding to multiple parties.

Pete Travis lists at petetravis.com Tue May 5 15:45:11 UTC 2015
I've seen people get themselves into tricky partitioning layout situations
- especially on non-GPT systems - and the flexibility of LVM made it
possible for them to install Fedora. Sometimes they did it to themselves,
sometimes it's from the OEM.  I suspect with admittedly no hard data that
LVM as default transparently handled many, many situations where without
LVM, relatively complex manual partitioning would be required.

For any preexisting 3 primary partition layout, the remaining MBR partition can become an extended partition, and Anaconda/GRUB can (and do) use only logical partitions. For capturing non-contiguous partitions and presenting them as one volume, either LVM or Btrfs would be needed.

People get themselves into tricky partitioning layouts because Linux installers are explicitly designed let them do crazy things. This doesn't happen on Windows, OS X or mobile devices. It's one size fits all, you get what you get, no discussion.

Yet despite the complexity of the installer's custom partitioning, it can't delete either LVM VG's or Btrfs volumes, instead this only happens once the user manually deletes all LVs or subvolumes first; and it requires the user manually create required partitions on UEFI. It's a task and knowledge not required for BIOS hardware for all of Fedora's history, and for no benefit. And yet it's not a bug. [6]

As far as I know this is still a bug, it basically breaks boot of any prior OS using LVM because its LVs aren't made active during Fedora installation, therefore boot entries aren't created for it.
Anaconda should run grub2-mkconfig when LVM devices are active
https://bugzilla.redhat.com/show_bug.cgi?id=825236



Josh Boyer jwboyer at fedoraproject.org  Tue May 5 13:32:50 UTC 2015
And it's a great example of why we don't immediately default to using
something shiny and new just because it exists.  Btrfs is neither
shiny or new at this point, and we look at it every release and
discuss it with upstream and it still isn't ready to be default.

More correctly these days, Fedora isn't ready for Btrfs. Even if Btrfs were as stable as ext4 Fedora couldn't use it by default right now.

The installer still has problems dealing with it [1], and installer team expects Btrfs development to be slim to none in the near future [2]. Grubby still doesn't support /boot on Btrfs [3]. For any other file system those would be blockers. Fedora release criteria considers Btrfs equal, without exceptions, to other file systems, but in practice at blocker reviews pretty much anything Btrfs gets a hand waive.

GNOME Disks doesn't support resize, snapshots, subvolume creation or deletion, gnome-shell gets confused with multiple disk Btrfs when mounting and umounting, and understanding volume size [4]. But openSUSE ships GNOME with Btrfs by default, so obviously these bugs aren't show stoppers, but still no bueno.

None of these are Btrfs kernel code or btrfs-progs related. The fact is, Btrfs is not a priority on Fedora, maybe not even of tertiary importance to either Fedora or Red Hat who have a pile of ext4, XFS, and LVM developers but no Btrfs developers. So to properly pin the tail on this donkey, it's at least as much Fedora's non-readiness and disinterest in Btrfs right now.

Other things to consider: ext4 on LVM is not well suited for eventual conversion to Btrfs. It can be done, it should work, if it doesn't it's a bug. But it just adds complexity for no good reason. Presently (and I'll argue properly) the installer doesn't permit LVM + Btrfs. There's an open question on backups and Btrfs volumes especially in the context of snapshots. We could use a tool that leverages btrfs send/receive so everything can be backed up, not just mounted subvolumes. The LVM and file system question opens up a bunch of related things, and I think they all need an integrated big picture approach rather than it just being a list of LVM pros/cons being used to arrive at a decision.



Stephen Gallagher sgallagh at redhat.com  Tue May 5 20:54:56 UTC 2015
This should probably be its own thread, but I'll note that the current state of encryption on Workstation is less than ideal (speaking as someone using it). Offline updates with encrypted partitions means re-entering the password twice; once to enter the offline-update mode and once to boot again afterwards. This is a bigger inconvenience than it sounds.

Offline updates requiring two reboots is asinine. Encryption by default just makes it more obvious. Windows likes to do these double reboots on updates from time to time too, so it's not completely foreign. But for the most part they quit the user session, do updates, and reboot once. That's what happens on OS X also.

To do encryption by default, there needs to be a way for gnome-control-center>users>change password to also reset the KEK in LUKS, as well as to add keys when users are added. Right now, LUKS supports 8 key slots, which may be a problem for encryption by default. Otherwise I support the idea of encryption by default. [5]


Chris Murphy



[1]
Can't resize btrfs
https://bugzilla.redhat.com/show_bug.cgi?id=962143
Custom partitioning can't delete Btrfs volumes (manual full teardown of each subvolume must be done by the user)
https://bugzilla.redhat.com/show_bug.cgi?id=1185117

[2]
https://bugzilla.redhat.com/show_bug.cgi?id=585525#c5


[3] This single bug has had numerous side effect bugs related to kernel upgrades failing to boot, crashes due to the lack of an initramfs entry in the grub.cfg, install failures. It goes back to 2012, is 102 messages long, no sane person will click on this link.
https://bugzilla.redhat.com/show_bug.cgi?id=864198

[4]
https://bugzilla.gnome.org/show_bug.cgi?id=746769
https://bugzilla.gnome.org/show_bug.cgi?id=710156
https://bugzilla.gnome.org/show_bug.cgi?id=708786

[5] It's a drag there's no open source UEFI driver to enable FDE OPAL 2.0 support. Many SSDs (I think now all Samsung SSDs) come with OPAL support and already always encrypt the drive, but it's always unlocked by default so it appears to be unencrypted.

[6]
https://bugzilla.redhat.com/show_bug.cgi?id=1022316

--
Chris Murphy