3 ms·
Hello. I was surprised to see someone post this so long after I wrote it. We had several design discussions about this at the time but we struggled to come to
by cyphar 5y ago
Hello. I was surprised to see someone post this so long after I wrote it.
We had several design discussions about this at the time but we struggled to come to an agreement about how we might migrate and various other issues. Tycho and I were the only people pushing for this and it wasn't clear how much other interest there is -- stargz is being pushed as a (pretty clever) attempt to hack around the tar issue by continuing to use tar but structuring it such that you can do random-access (among other things).
I haven't had much time for blogging recently. I did have a draft part 2 written but I decided it might make more sense to have some consensus on where we might go before publishing it -- at this point though, neither have happened so maybe I should've published the blog post regardless (though in fairness I was still writing prototypes so publishing something might've been a bit premature).
The general thesis would've been that we can basically design everything in a similar way to restic (content-defined-chunking and a snapshot-style system where the granularity of the filesystem data is much smaller than the layer level -- allowing for massively increased deduplication and eliminating the vast majority of issues with the layer-based model we have now).
However after looking into it more, there are several other things we should rethink (device inodes for instance -- which would require rethinking how systems like Kubernetes express their requirements
from an image). Also there's a fair argument that we should move compression entirely to distribution (and use decompressed data in the image format), but such a change would possibly require even more discussions with them to make sure that wouldn't be too burdensome.
Also feel free to call me Aleksa lol.