Re: 9p caching with cache=loose and cache=fscache

[Luis Chamberlain]

On Sun, Mar 12, 2023 at 01:22:34PM -0500, Eric Van Hensbergen wrote:
> I was looking at kdevops the other day - cool stuff.  Was trying to
> figure out how we could do v9fs CI with it.

Happy to help any questions you may have about it!

> Both cache=loose and cache=fscache currently don't validate via host.

What does this mean exactly?

Right now a host with debian 6.0.0-6-amd64 certainly does not seem to push
out changes to 9p clients on VMs but Josef informs me that with 6.2-rc8
he did see the changes propagate.

So I'm about to upgrade the host forward now in hopes that this is
somehow resolved on a newer debian testing kernel.

1) The simple test is boot up the guest, read a file mounted with 9p.
2) On the host append a file and sha1sum it.
3) Client side sha1sums after a few seconds

Today on 6.0.0 I see absolutely no updates, I have to reboot the guest.
Josef seems to indicate he does not see this issue on 6.2-rc8. So
curious if this was a bug fixed.

> I have a patch series which adds some new cache modes (readahead and
> writeback) that give closer to the loose performance but with tighter
> consistency (open-to-close) - these patches are in my ericvh/for-next
> tree.

Good to know!

For the typical workflow for kdevops we do kernel compilations on the
host over and over and over again. Take your typical kernel day, that's
how often we do that. So it is conventiant to just have the guest run
'make modules_install install' instead of:'reboot; make modules_instal install',

Do none of the existing 9p cache modes not support open-to-close policies
at all?

Right now the cache mode used is cache=loose as that's the default,
what do you recommend for a typical kernel development environemnt?

> I've also started on some patches to add cache=tight which will
> do dir caching like loose but with validation, and potentially also
> will add a new flag that will indicate how often loose should
> revalidate.  There is also some discussion of decoupling fscache from
> the revalidation policy.

I see !

> So the stuff in for-next will make it into the next kernel, there is a
> writeback fix patch that still has some bugs when cache=fscache that
> I'm working through, but the base patches add the new cache modes.
> The new dir cache along with tight policy will hopefully get done in
> the next month and so should be ready for next merge window as well.

Nice!

  Luis