5 ms·
Images don't need to be stored in this format on disk, the format is for transport/interchange. But out of curiosity, why do you say that a dependency graph wo
by cpuguy83 9y ago
Images don't need to be stored in this format on disk, the format is for transport/interchange.
But out of curiosity, why do you say that a dependency graph would be better here?
In terms of on disk storage and transport of layers, the layers are already content addressed.
- dlor 9y agoNot the OP so I'm just speculating, but being able to "mount" content-addressable blobs into different locations in the resulting rootfs would enable more incrementality and sharing of blobs. With a flat list, the same logical set of files will have a different checksum depending on where in the final rootfs it needs to end up, right?
- cpuguy83 9y agoThese blobs are already shared. (In Docker) Since each layer is only the diff from the layer before it, the content address is only from the change set. Technically you can share blobs even between an image that is `FROM centos` and one that is `FROM ubuntu` as long as the layer hashes are the same. If you have a hierarchical dependency chain, and addressing content based on the content that comes before it in the chain, you can only share blobs between images if they have a common ancestry.
- dlor 9y agoHere's the example I'm thinking of: One image has a large file at a specific path, added via something like: "COPY largefile /etc/path1". Another image wants to add this same file to a different location: "COPY largefile /etc/path2/". My understanding is that these two blobs will have a different hash and can't be shared because the changeset includes both the file itself, and the destination location in the image. Is that correct?
- cpuguy83 9y agoYes, however I'm not sure this would be shared in any format right now.