Anthony and other interested folks, I've been looking a bit further, and it seems like btrfs support shouldn't be too hard to implement. It actually seems simpler then LVM (because lvm has 3 levels: PV,VG and LV; btrfs has just the btrfs itself (~default subvolume) and other subvolumes) subvolumes don't get a new devicefile but i'll probably use something like: /dev/sda:$spec to denote what's what. if $spec is a number, it will become mount option subvolid=$spec; otherwise subvol=$spec although from what i can tell, the id's aren't used often. and it seems more robust to me use names anyway. * which are the requirements your btrfs_advanced mkinitcpio hook implies? what things does aif need to do other then just doing mkfs.btrfs to get the full potential out of btrfs/your hook? please explain why a default btrfs configuration does not suffice. does it have something to do with https://btrfs.wiki.kernel.org/index.php/UseCases#Can_a_snapshot_be_replaced_... ? * I've read a bit more about btrfs and I think an implementation like this will suffice for most users: - allow creation of a btrfs on top of 1-n blockdevices (user can pick raid levels for data and metadata) - allow creation of 0-m subvolumes - each subvolume as well as the default can get an arbitrary mountpoint, as well as specific mount options like compress, ssd, etc. if i understood correctly, that is. However, to be fully compatible with your hook, I will probably "strongly recommend" to create a subvolume __active and mount that as / Right? anything I missed? Dieter