Advantages
always-on data checksumming, skip separate verification (xxhash64 would be better than current isomd5sum method, but sha256 and blake2 are also available on btrfs)
simpler than the current squashfs image which contains a nested ext4 image
optional: leverage snapshots to cheaply create multi-image media
optional: leverage seed-sprout replication for significantly improved performance when the destination is also btrfs (default on Fedora desktops); obviates need to decompress the image first, the compressed extents are copied
Metadata Update from @ngompa: - Issue tagged with: Desktop, Dev
So how would we do this? We'd need to implement this into image building tools, right?
What are the mechanics of how this should work?
cc: @josef, @dcavalca
livemedia-creator, koji, pylorax come to mind.
But at the expense of scope creep, I wonder if we should be looking at the whole chain of creating live images today, and asking how to reduce technical debt, increase maintainability, make it self-describing or maybe even reproducible, and so on. I don't want to change this only to inadvertently make things harder for everyone.
One gotcha is that even if we leverage the seed device feature, we still need to maintain the current mkfs then rsync path for non-Btrfs file systems. In fact, it's vaguely possible Btrfs installations may need mkfs rsync path too because the seed feature bakes in certain mkfs time features that can't be changed later (like checksum algo).
Well, obviously a simple start would be to add support for using btrfs instead of ext4 in the DM loop image, right?
Sure.
The code was at one time assuming only nested ext4. It might be the boot.iso work to support plain squashfs added code to allow for two options, so it might be easier work to extend this to three options than it otherwise would be.
Log in to comment on this ticket.