Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 29 Mar 2023 07:08:26 +0900
From:   Dominique Martinet <asmadeus@codewreck.org>
To:     Luis Chamberlain <mcgrof@kernel.org>
Cc:     Christian Schoenebeck <linux_oss@crudebyte.com>,
        Eric Van Hensbergen <ericvh@gmail.com>,
        Josef Bacik <josef@toxicpanda.com>,
        Jeff Layton <jlayton@kernel.org>, lucho@ionkov.net,
        v9fs-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org,
        Amir Goldstein <amir73il@gmail.com>,
        Pankaj Raghav <p.raghav@samsung.com>
Subject: Re: 9p caching with cache=loose and cache=fscache
Message-ID: <ZCNlWnQTbWoBBPd2@codewreck.org>
References: <ZA0FEyOtRBvpIXbi@bombadil.infradead.org>
 <ZCHU6k56nF5849xj@bombadil.infradead.org>
 <ZCJRlqc/epbRhm93@codewreck.org>
 <2391219.DQnbcWml7j@silver>
 <ZCMmrnmZFcH65Orp@bombadil.infradead.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ZCMmrnmZFcH65Orp@bombadil.infradead.org>
Precedence: bulk

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