[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
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?


More information about the arch-releng mailing list