Support remote snapshotter for faster container startup

[ktock]

Initially discussed on containers/podman#4739

Among the container's lifecycle, pulling image is one of the biggest(and well-known) performance bottlenecks on container startup processes. Research shows that time for pulling accounts for 76% of container startup time[FAST '16].

In containerd community, there is a discussion of a new image distribution strategy called remote snapshotter to solve this issue. This enables us to mount container layers without pulling the actual contents.

I'm working on the implementation of remote snapshotter plugin on containerd. We can plug any filesystem into it so we currently support CRFS's stargz-based filesystem(which is compatible with container standards) and we discuss to support CernVM-FS and other filesystems.

I think this kind of feature is beneficial also for podman. Is something like this possible here? I'm keen to work on it.

cc @AkihiroSuda @siscia

[rhatdan]

Sure we would be interested in this. @giuseppe PTAL

[giuseppe]

yes we are surely interested in it and I've already worked on the lower level pieces.

It is still a PoC, but it seems to work fine at least with the images I've tried: https://github.com/giuseppe/crfs-plugin

Setting up fuse-overlays to use a remote image will require a command line similar to:

# fuse-overlayfs -o fast_ino=1,lowerdir=//crfs/$(echo -n docker://localhost:5000/myimages/fedora:stargz | base64 -w0)/$(pwd)/lower,upperdir=upper,workdir=work merged

Should the remote snapshotter be an option for the overlay driver? What I'd like to have in addition to using CRFS, is the possibility of using files that are already present locally in the overlay storage (that involves checksumming all the files present in the storage for a quick lookup)

[rhatdan]

@giuseppe @ktock What's up with this issue?

[rhatdan]

This Issue is going no where?

[AkihiroSuda]

Pending PR: #644

[rhatdan]

@ktock @AkihiroSuda I think this is all merged now, so closing. Reopen if I am mistaken.