Btrfs resize reliability
RHBZ Bug 962143. Summary: The installer doesn't support resizing Btrfs volumes, and also doesn't support placing /boot on Btrfs. A further consequence is that the "guided" path for the installer (i.e. the more automated, non-custom path) is unable to perform an installation of Fedora 19 along side Fedora 18. My question is, resize Btrfs has been in btrfs-progs since 0.16 which dates back to 2008. So I'm wondering how reliable Btrfs shrinking is? Is it mature enough for a major distribution's installer to actively allow the shrinking of the volume by 500MB-1000MB to make room for a new /boot on ext4? It seems less risky to support /boot in a new subvolume on the existing Btrfs volume, but only GRUB2 supports and comes with another consequence (grubby bug, will post separately). Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Btrfs resize reliability
RHBZ Bug 962143. Summary: The installer doesn't support resizing Btrfs volumes, and also doesn't support placing /boot on Btrfs. The consequence is that the "guided" path for the installer (i.e. the more automated, non-custom path) is unable to perform an installation of Fedora 19 along side Fedora 18. My question is, resize Btrfs has been in btrfs-progs since 0.16 which dates back to 2008. So I'm wondering how reliable Btrfs shrinking is? Is it mature enough for a major distribution's installer to actively allow the shrinking of the volume by 500MB-1000MB to make room for a new /boot on ext4? It seems less risky to default to /boot in a new subvolume on the existing Btrfs volume, but only GRUB2 supports and comes with another consequence (grubby bug, will post separately). Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
