Messages in this thread | | | Date | Wed, 29 Mar 2023 07:08:26 +0900 | From | Dominique Martinet <> | Subject | Re: 9p caching with cache=loose and cache=fscache |
| |
Luis Chamberlain wrote on Tue, Mar 28, 2023 at 10:41:02AM -0700: > > "To speedup things you can also consider to use e.g. cache=loose instead. > > My experience is that cache=loose is totally useless.
If the fs you mount isn't accessed by the host while the VM is up, and isn't shared with another guest (e.g. "exclusive share"), you'll get what you expect.
I have no idea what people use qemu's virtfs for but this is apparently common enough that it was recommended before without anyone complaining since that started being recommended in 2011[1] until now?
[1] https://wiki.qemu.org/index.php?title=Documentation/9psetup&diff=2178&oldid=2177
(now I'm not arguing it should be recommended, my stance as a 9p maintainer is that the default should be used unless you know what you're doing, so the new code should just remove the 'cache=none' altogether as that's the default. With the new cache models Eric is preparing comes, we'll get a new safe default that will likely be better than cache=none, there is no reason to explicitly recommend the historic safe model as the default has always been on the safe side and we have no plan of changing that.)
> > That will deploy a filesystem cache on guest side and reduces the amount of > > 9p requests to hosts. As a consequence however guest might not see file > > changes performed on host side *at* *all* > > I think that makes it pretty useless, aren't most setups on the guest read-only? > > It is not about "may not see", just won't. For example I modified the > Makefile and compiled a full kernel and even with those series of > changes, the guest *minutes later* never saw any updates.
read-only on the guest has nothing to do with it, nor has time.
If the directory is never accessed on the guest before the kernel has been built, you'll be able to make install on the guest -- once, even if the build was done after the VM booted and fs mounted.
After it's been read once, it'll stay in cache until memory pressure (or an admin action like umount/mount or sysctl vm.drop_caches=3) clears it.
I believe that's why it appeared to work until you noticed the issue and had to change the mount option -- I'd expect in most case you'll run make install once and reboot/kexec into the new kernel.
It's not safe for your usecase and cache=none definitely sounds better to me, but people should use defaults make their own informed decision.
>> In the above example the folder /home/guest/9p_setup/ shared of the >> host is shared with the folder /tmp/shared on the guest. We use no >> cache because current caching mechanisms need more work and the >> results are not what you would expect." > > I got a wiki account now and I was the one who had clarified this.
Thanks for helping making this clearer.
-- Dominique
| |