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