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). You'll sync next release files with the remote servers by using diffs (btrfs send/receive) and they will generate distro.img independently, still having the same hash that you'll later verify by https://your-distro.org. Chris Murphy <li...@colorremedies.com>, 14 Eki 2018 Paz, 21:10 tarihinde şunu yazdı: > > On Sun, Oct 14, 2018 at 6:20 AM, Cerem Cem ASLAN <cerem...@ceremcem.net> > wrote: > > I'm not sure I could fully understand the desired achievement but it > > sounds like (or this would be an example of selective perception) it's > > somehow related with "creating reproducible snapshots" > > (https://unix.stackexchange.com/q/462451/65781), no? > > No the idea is to be able to consistently reproduce a distro installer > image (like an ISO file) with the same hash. Inside the ISO image, is > typically a root.img or squash.img which itself contains a file system > like ext4 or squashfs, to act as the system root. And that root.img is > the main thing I'm talking about here. There is work to make squashfs > deterministic, as well as ext4. And I'm wondering if there are sane > ways to constrain Btrfs features to make it likewise deterministic. > > For example: > > fallocate -l 5G btrfsroot.img > losetup /dev/loop0 btrfsroot.img > mkfs.btrfs -m single -d single -rseed --rootdir /tmp/ -T > "20181010T1200" --uuidv $X --uuidc $Y --uuidd $Z ... > shasum btrfsroot.img > > And then do it again, and the shasum's should be the same. I realize > today it's not that way. And that inode assignment, extent allocation > (number, size, locality) are all factors in making Btrfs quickly > non-determinstic, and also why I'm assuming this needs to be done in > user space. That would be the point of the -rseed flag: set the seed > flag, possibly set a compat_ro flag, fix generation/transid to 1, > require the use of -T (similar to make_ext4) to set all timestamps to > this value, and configurable uuid's for everything that uses uuids, > and whatever other constraints are necessary. > > > -- > Chris Murphy
