[Feature] Support configuring volatile overlayfs option for all writable layers

[Fricounet]

Feature Description

Add a configuration knob to the nydus-snapshotter (for example overlayfs_volatile = true) so that operators can enable the volatile mount option globally without needing to inject snapshot labels through the container runtime stack.

Problem and Use Case

The nydus snapshotter already supports the volatile overlayfs mount option via the snapshot label containerd.io/snapshot/overlay.volatile with the two mount paths in snapshot/snapshot.go.

However, I couldnt' find a straightforward way to set this label from a Kubernetes environment:

• The kubelet has no mechanism to pass snapshotter labels to containerd.
• The CRI API does not expose snapshot-level options.
• containerd's CRI plugin has no config field (like default_snapshot_opts) to inject snapshot labels globally. (it does have something for the base overlayfs snapshotter but that won't work with nydus I think)

The volatile option skips sync on the overlayfs upper layer, which significantly improves write performance for ephemeral container filesystems. This is a safe trade-off for most container workloads where the writable layer does not need to survive a crash.

Questions

1. Is there a supported way today to pass the containerd.io/snapshot/overlay.volatile label to the snapshotter from a Kubernetes/containerd deployment that I am missing? In which case, maybe we just need to document it.
2. If not, would it make sense to add a nydus-snapshotter configuration option (e.g., in the TOML config) to unconditionally enable volatile on all active (writable) overlayfs mounts?

Related issues

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

[imeoer]

I went through the related code (and also asked Agent :)), and it seems there really isn't a good way to pass this option to the remote snapshotter. However, the overlayfs snapshotter does provide a built-in configuration. We could indeed make this a configurable option for the nydus snapshotter, though it would be a global daemonset-level setting.

[Fricounet]

Thanks for double checking. We can try having this configured at the snapshotter level. I tried thinking through the different use cases were we'll hit the mountRemote and mountNative logics where this volatile will take effect. And the only 2 cases I could think of are:

1. regular active snapshot -> containerd wants to mount the writable layer of a container
2. active snapshot used in a View call

The 1st case is the main case I would like to address with this option. For the second case, as View snapshots are supposed to be read-only, I feel like not forcing a sync is fine because we aren't supposed to write anything there anyway.

If you are fine with that, I've opened a PR to address this #731