@JJJollyjim, can you take a look at this?

@erikarvstedt We might also then be able to drop the sync commands from the copy_from_host method introduced in 798fcaa.

It's probably fine to not cache - I doubt there's anything performance critical with a lot of IO exchanged via these folders.

@flokli removing the sync in the test driver will lead to bugs in case we add a cached backend in the future. I'll let you decide whether to drop it.

@flokli removing the sync in the test driver will lead to bugs in case we add a cached backend in the future. I'll let you decide whether to drop it.

I consider the sync a workaround implemented to explicitly flush caches, which hides away the broken caching behaviour. If other applications in the test use /tmp/xchg directly, we also can't tell them they need to use sync.

If we add back some caching, it should properly invalidate caches on external changes (like an nfs share would do), so we should remove these workarounds - please drop the sync.

I've had a thorough look at these syncs now.

• with xchg dir caching, this sync is needed to commit the VM data to the host. This sync can be removed when removing caching.
  I'm now removing this sync in my original commit.
• the 3 other syncs in copy_from_host and copy_from_vm try to transfer host data changes to the VM, but this is pointless (irrespective of xchg dir caching) because 1) syncing in the VM can't possibly pull in host data and 2) 9p is accessing the host filesystem on the cached layer anyways, so even syncing on the host would have no effect in the VM.
  (@flokli, would you consider this reasoning to be correct?)
  I'm removing these syncs in a separate commit.

I think your reasoning is correct. Can you prefix the second commit, too (test-driver, virtualization: maybe)?

Also, slightly off-topic, but did you see #85568?

I'll keep an eye on #85568 and jump in when I see new caching-related issues arise.

Thanks!