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: > > On Sat, Oct 13, 2018 at 8:17 PM Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > >> > >> On Fri, Oct 12, 2018 at 5:26 PM, Marek Marczykowski-Górecki > >> <marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote: > >> > On Fri, Oct 12, 2018 at 03:44:38PM -0600, Chris Murphy wrote: > >> > >> >> mkfs.btrfs has --rootdir and --shrink features to pre-allocate a > >> >> volume with files at mkfs time; I have no idea to what degree it > >> >> depends on kernel code. > >> > > >> > Probably not at all, given it works as non-root user too. > >> > I've tried to run it twice on the same directory (and with the same > >> > --uuid) on 32MB of data and got different images (~2000 lines of hexdump > >> > diff). Could be some timestamps, could be something else. > >> > >> There is volume UUID which is what --uuid affects. But there are other > >> uuids, including the chunk uuid which gets repeated in every leaf and > >> node along with the volume uuid, device uuid, each files tree > >> (subvolume) get its own uuid, etc. Time stamps include atime, otime, > >> mtime, and ctime. Some objects have all 0's for uuid, and some items > >> have only 0.0 for times. I'll float the reproducibility question on > >> the Btrfs list, if it's desirable, useful, and how difficult it is. I > >> think subsetting Btrfs features to reduce complexity generally, and > >> therefore increase reproducibility as a consequence of that, has > >> merit. > >> > > > > 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. > > > squashfs has supported zstd along with btrfs since kernel 4.14. zstd > > support was mainlined into squashfs-tools a year ago: > > https://github.com/plougher/squashfs-tools/commit/6113361316d5ce5bfdc118d188e5617a1fcd747c > > > > However, there's been no releases since the migration from CVS on SF > > to Git on GitHub. > > Ahh I missed that. And looking at koji, it seems like squashfs-tools > are currently FTBFS on Fedora 29. I have F29 but > squashfs-tools-4.3-16.fc28.x86_64. > > > OK, so it sounds to me like the current proposals for this thread as > it relates to installer images for Fedora 30: > > - Drop devicemapper in favor of overlayfs > - Drop squashfs+ext4 images in favor of squashfs only image > - Maybe move to zstd in the squashfs image > > I think part of the feature/change proposal should be building an > example LiveOS image in copr so we can get an idea of how to blow it > up, and ask QA to run it through OpenQA tests and see what sorts of > things break there. > > Neal, any ideas who Marek could be a co-owner of the feature and help > navigate the Fedora process? Maybe someone on the Anaconda or releng > teams? > Brian C. Lane from the Weldr team is probably the guy to work with on this. He is the chief developer of Lorax, which is where livemedia-creator comes from. I've CC'd him to this email. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
