On Sun, Oct 14, 2018 at 12:21 PM, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > On Sun, Oct 14, 2018 at 1:58 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> >> On Sat, Oct 13, 2018 at 6:24 PM, Neal Gompa <ngompa13@xxxxxxxxx> wrote: >> > This is a really interesting idea... >> >> >> https://lore.kernel.org/linux-btrfs/CAJCQCtTPwQnzwkpk=4ZsZXfWTC7HymYETxp-9xUU_tsvOTW0ZQ@xxxxxxxxxxxxxx/t.atom >> > > I'm interested to see how that thread turns out... It's a tempting > idea, because it gives you so much more flexibility. Installation onto > a disk could be a "btrfs send" and overlay changes could be easily > flattened on top of the target system. It'd also be much cheaper and > lighter for supporting the live environment. Ha! I just realized after all this time that the Btrfs wiki does not make clear how to make a sprout, even though it mentions the more esoteric recursive seed.[1] Of course you can mkfs.btrfs, mount it, and send/receive. But send requires read only snapshots. Making a sprout is easier, you just remove the seed device. This is supported since 2009. # losetup -r /dev/loop0 root.img # mount /dev/loop0 /mnt/ # btrfs device add /dev/sda3 /mnt # mount -o remount,rw /mnt # btrfs device remove /dev/loop0 /mnt And now it replicates extents from seed to sprout. The copy is faster than pvmove, rsync, dd, or rpm-ostree deploy. OK so let's say you have a USB stick 'sdb' and internal drive 'sda'. And the stick already has a Fedora LiveOS imaged on it, only change is the root.img is a Btrfs seed. The simplistic systemd pre-mount and mount look like: # losetup -r /dev/loop0 root.img # mount -t btrfs /dev/loop0 / # btrfs device add /dev/zram1 / # mount -t btrfs -o remount,rw / - now you have a live overlay in RAM; user can start using this LiveOS environment including making changes like installing software; setting up non-volatile persistence on the stick looks like: # btrfs device add /dev/sdb3 / # btrfs device remove /dev/zram1 / # echo 1 > /sys/class/zram-control/hot_remove - now the extents on zram1 are moved from zram1 to sdb3 (the stick); setting up an installation to the internal drive 'sda' by "flattening" as you say, merely means adding the internal drive to the mounted Btrfs volume and removing all others: # btrfs device add /dev/sda3 / # btrfs device remove /dev/sdb3 / # btrfs device remove /dev/loop0 / - now extents on sdb3 (stick) and loop0 (seed) are copied to sda3 (internal), including any changes the user is making while all of this is happening. In fact, the user does not even have to reboot because once the operation finishes, and the loop is torn down, the stick is not in use by the kernel. The user can just unplug the stick and keep working. A spin or downstream could very sanely, and straightforwardly build a no-UI OS installation. It's not obvious that 'btrfs device add' incorporates a mkfs and that you can now just delete the ro seed. Also not obvious is the 'dev add' on an ro mounted seed causes a new volume UUID to be generated. This is immediately discovered by libblkid. The kernel knows that this new volume is a two device (or three device, whatever the case is) btrfs and which devices they are. And this is such basic btrfs handling code that GRUB and extlinux Btrfs code understand it. [1] https://btrfs.wiki.kernel.org/index.php/Seed-device -- Chris Murphy _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
