Support mode that refreshes contents as image tag is updated on registry? about crfs HOT 7 CLOSED

Most common use case that I can come up with is when there is a "dev" or "latest" tag being constantly overwritten as developed, and the developer has mounted the image between one of those overwrites, and wants to quickly test the changed behavior of the container.

from crfs.

Ok, fair point. So basically a docker container start in crfs would perform first a pull equivalent action, and then update the mountpoint for that image?

from crfs.

So basically a docker container start in crfs would perform first a pull equivalent action,

It'd read some metadata from the registry about the layers, without pulling them.

and then update the mountpoint for that image?

Update which mountpoint? Oh, you mean some existing path like /crfs/gcr.io/proj/image/latest ? Actually the way it'll work is that every time something does an open of such a path, they get a read-only subtree for life. But if process A opens that path at time 1 and process B opens the same path at time 2 (even with the same FUSE process, without restarting it), they may or may not have different read-only snapshots, depending on whether latest changed between times 1 and 2.

from crfs.

Cool, thanks for the clarification

from crfs.

The easy, safe, and performant option is to serve the same static snapshot for the life of the FUSE mount. So that'll always be the default.

Although it might be nice to have some optional mode where the contents refreshed dynamically, doing so in an atomic fashion is difficult without hurting performance. When the kernel goes to ask our userspace process for filesystem info, it asks how long it can cache it for. Currently we say something really long, like a month, since we know it's read-only.

I'm not aware of a way for a FUSE process to tell the kernel to invalidate any previous validity times and revert back to asking the process for all the answers again.

So if we added such a mode, it'd probably be advertised as slow. But I'd need to hear some interesting use cases for such a mode before I accepted code that'd need ongoing maintenance.

from crfs.

But if that container is running a daemon or something, you'll need to remember to restart that too, which might kill the whole container if it's the init program. I think in general it'll prove more problematic than just killing & restarting the container. Especially as the goal of this project is to make even huge containers start quickly, it should always be a reasonable to just kill & restart the container to get new contents, which'll work regardless of whether there's a long-running server running in the ENTRYPOINT.

from crfs.

I think I'm going to close this, as I think the current behavior is what we want, even long term.

If anybody has strong arguments (with use cases) for changing it, though, let us know and we can reopen.

from crfs.