CRFS: Container Registry Filesystem
github.com
CRFS: Container Registry Filesystem
1–10 of 23 posts
Re: CRFS: Container Registry Filesystem
#2This is very cool! I've been waiting to see someone enable tar.gz files to be seekable so they could be object bundles stored in remote blob storage systems that a client could mount and seek through on demand by byte range (so you could treat data in a similar fashion to containers, or like a Mac DMG file that had an open standard for remote mounting).
Re: CRFS: Container Registry Filesystem
#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.
Re: CRFS: Container Registry Filesystem
#4> 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.
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.
Re: CRFS: Container Registry Filesystem
#5> 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.
Compressing individual files would probably result in a bigger file, ofc depending on the content mostly.
Re: CRFS: Container Registry Filesystem
#6> 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.
> This makes images a few percent larger
Teehee. The method is not new at all, for example compressors like xzip do this out of the box, and almost the exact thing they're doing is basically how ZIP files work
The trouble with discarding state on every file is that it really hurts performance with small files, or when using anything like a modern codec, which gzip/deflate is not. Gzip maintains a 32kb dictionary which is quite easy to exceed with contemporary data, but with a modern compressor (like lzma2) losing that window will absolutely devastate ratios
The usual solution is so-called 'solid' compression, where the uncompressed input is partitioned into blocks spanning file boundaries. It configurably trades seek efficiency for reliably preserving compressor context -- including allowing seeking within files. Their format could be modified to support this while retaining backwards compatibility as good as the current method. What they have is already pretty much solid compression, except it only chunks large files. This is basically a weird special case of a simpler and more general design everyone else uses.
Finally on the compatibility angle, the end of stream is visible at an API level, so this isn't going to be 100% perfect. I'd expect one or more obscure implementations (maybe Windows apps? Java?) to potentially break
Re: CRFS: Container Registry Filesystem
#7In 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".
Re: CRFS: Container Registry Filesystem
#8TaaS – Tar as a Service.
Re: CRFS: Container Registry Filesystem
#9> 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.
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...
Re: CRFS: Container Registry Filesystem
#10In 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.