Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CRFS: Container Registry Filesystem

github.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: CRFS: Container Registry Filesystem

#11

Post by maxmcd »

Conceivably this could be leveraged to allow docker for mac to only push deltas to the build virtual machine when running docker build, correct?

Currently docker build compressed everything in the working directory on every build. This is fine for building images for deploy/upload but is annoying for a local dev situation where you're frequently rebuilding.

Seems like it wouldn't be too hard to write an alternate docker build that checks a previously built "Stargz" and just sends the additional files? (There would be some complexity here reassembling a valid tar within hyperkit).

I might be missing something here, it might be misplacing the bottleneck during build, but every time I'm annoying by this problem it seems part of the issue is the single fat tar that needs to be created every time.

edit: this strategy could also work with docker-machine building on remote machines

Re: CRFS: Container Registry Filesystem

#13

Post by catern »

bradfitz wrote: post #10
catern wrote: post #7

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…

Hi, 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.

If you don't want those writes to a block device to happen, then you could store your images in a tmpfs instead.

Re: CRFS: Container Registry Filesystem

#14

Post by david_ar »

koolba wrote: post #3

> Fortunately, we can fix the fact that tar.gz files are unindexed and unseekable, while still making the file a valid tar.gz file by taking advantage of the fact that two gzip streams can be concatenated and still be a valid gzip stream. So you can just make a tar file where each tar entry is its own gzip stream. I'm surprised nobody came up with this idea till now. It's brilliantly simple.

dict uses something similar:

https://linux.die.net/man/1/dictzip

Re: CRFS: Container Registry Filesystem

#16

Post by ithkuil »

catern wrote: post #13
bradfitz wrote: post #10

Earlier quoted context omitted.

Hi, 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.

If you don't want those writes to a block device to happen, then you could store your images in a tmpfs instead.

But 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.

Re: CRFS: Container Registry Filesystem

#17

Post by fulafel »

If the bottleneck of pulling was eliminated by this, it means the test runs didn't need to access most of the image, right? I wonder what this says about carrying unnecessary stuff or test coverage. Especially since the base distro layers were probably cached.

Edit: " For isolation and other reasons, we run all our containers in a single-use fresh VMs." So they had no caching for the base layers unless those were primed in the vm image?

Re: CRFS: Container Registry Filesystem

#18

Post by koolba »

bradfitz wrote: post #9
xyzzy_plugh wrote: post #4

Earlier quoted context omitted.

Well, for one, it's not obviously useful in traditional applications: > This makes images a few percent larger (due to more gzip headers and loss of compression context between files), but it's plenty acceptable. Compressing an entire image is generally great. Compressing all of the individual files in an image, is generally not great.

Maybe not great, but like I said: acceptable. About 7.6% bigger: https://github.com/golang/build/commit/8a5a4d227f08eb1d889fa...

That's what I meant by "brilliantly simple"; namely having something like this work with existing systems while imposing a marginal overhead.

Re: CRFS: Container Registry Filesystem

#19

Post by helper »

tsurkoprt wrote: post #15

Why not directly use www.lucidlink.com, same result but read/write

Because it doesn't solve the problem the author is trying to solve? The goal of this is to be able to produce backwards compatible tar.gz files that can be served from a docker registry that also can be on demand streamed instead of predownloaded.

If they just wanted a S3/GCS fuse filesystem there are plenty of open source options out there.

Re: CRFS: Container Registry Filesystem

#20

Post by [deleted] »

ithkuil wrote: post #16
catern wrote: post #13

Earlier quoted context omitted.

If you don't want those writes to a block device to happen, then you could store your images in a tmpfs instead.

But 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 recentl…

[deleted]
Post reply on HN