On Sun, Oct 14, 2018 at 1:58 PM Chris Murphy <lists(a)colorremedies.com> wrote:
On Sat, Oct 13, 2018 at 6:24 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
> On Sat, Oct 13, 2018 at 8:17 PM Chris Murphy <lists(a)colorremedies.com> wrote:
>> On Fri, Oct 12, 2018 at 5:26 PM, Marek Marczykowski-Górecki
>> <marmarek(a)invisiblethingslab.com> 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
> This is a really interesting idea...
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:
> 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
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
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!