Content-defined chunking added to Bazel (opens in new tab)

(buildbuddy.io)

63 pointssiggi12d ago10 comments

10 comments

I have done extensive research on CDC and it almost never works out because most utilities don't create compressed archives in an "rsyncable" (rsync does CDC) format, I actually saved a lot of storage using restic when I switched my backups of certain things so that files were stored in archives uncompressed, and sorted in a stable order. I know syncthing eventually removed CDC and just went with constant-size block sizes.

Bazel, on the other hand, is completely in control of this, and it makes perfect sense to do this at that point -- and it seems to be a relatively efficient implementation too, really nice to see!

a_t489d ago

This is something I'm very interested in implementing for Docker builds. I've tested out CDC for the final image outputs, it results in smaller outputs but requires tuning between saved space versus request count when pulling. For build cache it might be even more advantageous.

stabbles9d ago

Isn't that rather difficult given the `.tar.gz` layers?

a_t488d ago

I have a custom pull client/registry/builder that uses a different format, but can output standard OCI if needed.

tracnar9d ago

It also supports .tar but that's probably not very commonly used.

auscompgeek9d ago

In theory eStargz layers should be amenable to CDC.

1 more reply

londons_explore9d ago

Doesn't this mean that malicious inputs can deliberately cause super tiny or super huge chunks?

rienbdj9d ago

Bazel caches tend to have a size limit.

You need to trust your build execution machine anyway. They have your source code and you will be executing the artifacts that they produce!

ramchip9d ago

The same is true without CDC, and you can configure a maximum size.

j / k navigate · click thread line to collapse