[arch-releng] btrfs support in aif
Dieter Plaetinck
dieter at plaetinck.be
Sun Dec 12 10:29:27 EST 2010
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_atomically_with_another_snapshot.3F ?
* 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
More information about the arch-releng
mailing list