[kata-dev] Virtio-fs as upper layer for overlayfs
Miklos Szeredi
miklos at szeredi.hu
Tue Jan 7 09:48:37 UTC 2020
On Mon, Jan 6, 2020 at 11:18 PM <eric.ernst at intel.com> wrote:
> Miklos, I'm still learning a bit more about fs implementations, so my
> apologies if this should be obvious. For virtio-fs, one of the use cases
> that is described is sharing memory between two guests (not necessarily
> the Kata use case). I was guessing the dcache would be within the guest,
> and that in at least the shared memory case, there's potential that a
> revalidate may be neccesary, in case any changes are made by the second guest?
Exactly.
> (I could be mixing up the intended use for revalidate, though).
>
> Can you clarify that "not calling ->revalidate() should not be a
> problem?"
I was referring specifically to the overlayfs case. Overlayfs stacks
on top of some other filesystems, i.e. when ->d_revalidate() is called
on overlayfs it calls ->d_revalidate() on underlying fs. This only
happens for the lower (read-only) layers, not the upper (read-write)
layer. So if the underlying upper fs is modified from another guest,
than that modification is not going to be reflected on the overlayfs.
However, overlayfs documents any changes to underlying layers as
resulting in undefined behavior. It would be strange if docker was
relying on undefined behavior of overlayfs, so not doing the
revalidation should not make a difference.
Thanks,
Miklos
More information about the kata-dev
mailing list