On Sun, Oct 14, 2018 at 1:09 PM, Cerem Cem ASLAN <cerem...@ceremcem.net> wrote: > Thanks for the explanation, I got it now. I still think this is > related with my needs, so I'll keep an eye on this. > > What is the possible use case? I can think of only one scenario: You > have a rootfs that contains a distro installer and you want to > generate distro.img files which uses Btrfs under the hood in different > locations and still have the same hash, so you can publish your > verified image hash by a single source (https://your-distro.org).
The first step is accepting reproducible builds as a worthy goal in and of itself independent of Btrfs. Specifically "Why does it matter?" found here https://reproducible-builds.org/ Btrfs does bring valuable features for installation images: always on checksumming; seed feature permits a straightforward way to setup a volatile overlay on zram device; ability to convert it to a non-volatile overlay, and boot either the seed or overlay; and even installation by adding the install target and removing both overlay and seed. And yet it remains compatible with a conventional copy to another file system if it's not desirable to use Btrfs as root. Win win. By subsetting Btrfs features we don't care about in the installation seed context, can we achieve reproducibility as a consequence, while retaining some of the more interesting features? Of course once sprouted, those limitations wouldn't apply. Basically it's a "btrfs seed device 2.0" idea. But Btrfs is so complicated it's maybe too much work, hence the question. -- Chris Murphy
