Re: Virtio-fs as upper layer for overlayfs

[Miklos Szeredi <miklos@szeredi.hu>]

On Mon, Jan 6, 2020 at 11:18 PM <eric.ernst@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