Bug 689517

*** Bug 618133 has been marked as a duplicate of this bug. ***

Hi,

my wishlist :)

1. Allow users to create subvolumes (obviously)
2. / partition be inside a subvolume, which later be used as the default subvolume using 'btrfs subvolume set-default <id> <btrfs mount path>'
3. the real root of the btrfs filesystem is mounted in /dev/btrfs/ or similar using 'mount -o subvolid=0 /dev/btrfs/'

I believe this would provide an experience similar to how LVM is being used right now.

The current anaconda in F16 (livecd) looks like it want to destroy the whole / tree including subvolumes when doing a new clean installation. I havent tried the anaconda in DVD yet, not sure if theres a difference.

 Full support for btrfs is targeted for F17. Support for interactively creating/editing btrfs volumes is somewhat tentative given that entire installer UI is being rewritten this cycle, but kickstart support will be there at a minimum. Support will include subvolumes, raid and possibly compression.

 We are also working on an automatic partitioning scheme that uses btrfs. The current approach is to create a btrfs volume with subvolumes for root and home using available space on any available disks, much like what we do now for lvm autopart. We will also need a separate partition for swap and, depending on bootloader support, possibly a separate /boot.

Grub2 supports btrfs so we should be good on the bootloader.  I was actually going to start on adding the kickstart commands to do the subvolume and raid stuff soon, in fact I had cloned the anaconda tree and was setting up a vm to test but got sucked into btrfs bug squashing.  Are you planning on starting this work soon?

I know that grub2 can handle btrfs to some extent, but I still have concerns:

 1. is btrfs supported on platforms that don't use grub2 yet? (ppc, efi, s390)
 2. can grub2 handle /boot being on a subvolume?
    2.1. if not, what if it's on the default subvolume?
    2.2. if still no, should we use subvol 0 as /boot or use separate /boot?


As for kickstart, I've gotten some code written but am not satisfied with the syntax yet. I'm currently trying to finish writing the installer's btrfs backend code. Once that is functional for automatic partitioning I'll move on to kickstart.

Ah so efi probably not since that still uses grub1, and I'm not worried about secondary arches since btrfs doesn't work with those right yet anyway.  As for #2 that's an excellent question, I'll have to figure that out.

*** Bug 756666 has been marked as a duplicate of this bug. ***

I want the option to create a snapshot on upgrade and make the snapshot the root filesystem for the upgrade.

As a Btrfs user, I had to do some dirty tricks in the F16 install to force Anaconda to install inside of a subvolume. I would like to be able to install F17 without these tricks, but in case someone is trying to install F16 (or F17 doesn't improves the situation), this is how I did it:

1) Create a btrfs filesystem manually with another distro (because the btrfs userspace available in the F16 installer emergency shell was too old and wasn't able to list the available subvolumes, which is needed in the next step) with the disks and configuration you want.
2) Create a subvolume (or a snapshot, if the filesystem already existed) and set it as the default subvolume to be mounted if the user doesn't specifies any.
3) Install disk, enter Anaconda, go to the partition configuration screen. Choose one of the Btrfs partitions as the root filesystem and set the option to format it (because F16 anaconda won't allow to install on top of a non-freshly formatted filesystem)
4) Finish the partition configuration and continue to the screen which shows all the partition changes and filesystem formats planned, and asks for confirmation. Don't confirm it.
5) Go to the emergency shell, and link /sbin/mkfs.btrfs to /bin/true. That will avoid a filesystem format that would have deleted your pool and replication configuration. Go back to Anaconda and complete the install, which will be done inside the subvolume you configured as default.

It looks like the partial support Anaconda has for btrfs has caused Anaconda to actually handle btrfs less well for Fedora 17.

Fedora 18 Beta will support subvolumes and raid. So far we are planning to leave out compression support.

FWIW, GRUB2 does support /boot on Btrfs in a subvol, with all data/mdata profiles, and zlib or lzo compression.

+1 on comment 8, although that's for fedup.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

The plans from comment #11 were implemented in 18 and 19. Closing.

Fedora 18 implements btrfs raid10, Fedora 19 does not and as such is a regression. Unclear why compression as an option isn't going to be supported for newly created volumes.