3 ms·
In the introduction: >Currently, however, starting a container in many environments requires doing a pull operation from a container registry to read the entir
by catern 8y ago
In the introduction:
>Currently, however, starting a container in many environments requires doing a pull operation from a container registry to read the entire container image from the registry and write the entire container image to the local machine's disk. It's pretty silly (and wasteful) that a read operation becomes a write operation.
What's silly is to claim that this is the problem. Any read is going to be a write operation, at multiple levels, thanks to systems of transparent caching: To a nearby CDN, to local disk, to local memory, to your CPU cache, etc. These are optimizations, they aren't making your container startup any slower.
The real problem, which this tool indeed helps to solve, is that reading the entire image must complete before you're able to start further processes which read specific parts of the image. Not anything to do with "reads causing writes".
- bradfitz 8y agoHi, author here. The unnecessary writes I care about are to my cloud VM's small block device, which is I/O limited. The best way to not wait for those is to not do the writes in the first place.
- catern 8y agoIf you don't want those writes to a block device to happen, then you could store your images in a tmpfs instead.
- ithkuil 8y agoBut then you have to provision space in memory for the whole image size or else you'll need to spill the excess on disk, even those that are not technically dirty (binaries and libraries and support files meant to be just read, I.e. likely most of the image) Demand paging the bits you actually use from the network solves both the problem of not even loading cold pages, but also the ability to throw away least recently used pages knowing you can fetch them again when needed.
- deleted 8y ago[deleted]
- catern 8y ago>But then you have to provision space in memory for the whole image size No, you can have your container system load parts of the image on demand into that tmpfs. That's my point: this doesn't have anything to do with writing to memory, writing to block device, etc. etc. This is just a matter of indexing the image so that it can be lazily loaded. Which is of course good, but let's be clear that it's orthogonal from whether you stick the images on local disk, stick them only in memory, or whatever.