[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZCJ3uzqDk6RPd28j@bombadil.infradead.org>
Date: Mon, 27 Mar 2023 22:14:35 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: Christian Schoenebeck <linux_oss@...debyte.com>,
Eric Van Hensbergen <ericvh@...il.com>,
Josef Bacik <josef@...icpanda.com>,
Jeff Layton <jlayton@...nel.org>, lucho@...kov.net,
v9fs-developer@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
Amir Goldstein <amir73il@...il.com>,
Pankaj Raghav <p.raghav@...sung.com>
Subject: Re: 9p caching with cache=loose and cache=fscache
On Tue, Mar 28, 2023 at 11:31:50AM +0900, Dominique Martinet wrote:
> Luis Chamberlain wrote on Mon, Mar 27, 2023 at 10:39:54AM -0700:
> > > I have fixed what
> > > I hope to be my last bug with the new patch series so it should be
> > > going into linux-next today.
> >
> > Nice, thanks, since kdevops relies on a host kernel though and we strive
> > to have stability for that, I personally like to recommend distro
> > kernels and so they're a few kernel releases out of date. So debian-testing
> > is on 6.1 as of today for example.
> > [...]
> > - opts: "ro,trans=virtio,version=9p2000.L,posixacl,cache=loose"
> > + opts: "ro,trans=virtio,version=9p2000.L,posixacl,cache=none"
>
> Yes, if you want something mostly coherent with the host, cache=none (or
> cache=mmap if you need mmap, iirc linux build does for linking? if you
> want to do that on guest...) is what you'll want to use on current
> kernels.
OK cool, we use 9p to build on the host and so all the guest has to do
is just 'make modules_install install'.
> > BTW the qemu wiki seems to suggest cache=loose and its why I used it on
> > kdevops as a default. What about the following so to avoid folks running
> > into similar issues? I can go and update the wiki too.
>
> I've added Christian in Cc for this point, he's more active on the qemu
> side
> (thread started here:
> https://lkml.kernel.org/r/ZA0FEyOtRBvpIXbi@bombadil.infradead.org
> )
>
> I have no opinion on the current wording, the default is there for a
> reason and it's a safe default (none), and cache=loose is clearly
> described with "no attempts are made at consistency, intended for
> exclusive, read-only mounts" which I think ought to be clear enough
> (exclusive means not shared with the host), but if you think it's not
> clear enough it probably isn't.
It certainly was not.
LUis
Powered by blists - more mailing lists