linux-kernel - Re: 9p caching with cache=loose and cache=fscache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2391219.DQnbcWml7j@silver>
Date:   Tue, 28 Mar 2023 13:53:49 +0200
From:   Christian Schoenebeck <linux_oss@...debyte.com>
To:     Luis Chamberlain <mcgrof@...nel.org>,
        Dominique Martinet <asmadeus@...ewreck.org>
Cc:     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 Tuesday, March 28, 2023 4:31:50 AM CEST 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.
> 
> > 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.
> 
> A word on the qemu wiki "if you want to share with host..." would
> probably be good though.

Hi Luis,

not sure which QEMU wiki page you are referring to. AFAIK we currently have 3
QEMU wiki pages concerning 9p:

1. 9p documentation for users:
https://wiki.qemu.org/Documentation/9psetup

2. 9p documentation for developers only:
https://wiki.qemu.org/Documentation/9p

3. How to setup an entire guest on top of a 9p root filesystem:
https://wiki.qemu.org/Documentation/9p_root_fs

Only the latter wiki page mentions cache=loose at all:

  "To speedup things you can also consider to use e.g. cache=loose instead. 
   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 
   immediately see file changes performed on host side. So choose wisely upon
   intended use case scenario. You can change between cache=mmap or e.g.
   cache=loose at any time."

Which I now changed to:

  "To speedup things you can also consider to use e.g. cache=loose instead.
   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* (as Linux kernel's 9p client 
   currently does not revalidate for fs changes on host side at all, which is
   planned to be changed on Linux kernel side soon though). So choose wisely
   upon intended use case scenario. You can change between cache=mmap or e.g.
   cache=loose at any time."

On the user page it was already clearly mentioned though:

  "Mount the shared folder on guest using

      mount -t 9p -o trans=virtio test_mount /tmp/shared/ -oversion=9p2000.L,posixacl,msize=104857600,cache=none

  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."

Best regards,
Christian Schoenebeck