All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: Luis Chamberlain <mcgrof@kernel.org>,
	Dominique Martinet <asmadeus@codewreck.org>
Cc: 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
Date: Tue, 28 Mar 2023 13:53:49 +0200	[thread overview]
Message-ID: <2391219.DQnbcWml7j@silver> (raw)
In-Reply-To: <ZCJRlqc/epbRhm93@codewreck.org>

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



  parent reply	other threads:[~2023-03-28 11:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-11 22:47 9p caching with cache=loose and cache=fscache Luis Chamberlain
2023-03-12 18:22 ` Eric Van Hensbergen
2023-03-17 17:01   ` Luis Chamberlain
2023-03-27 13:05     ` Eric Van Hensbergen
2023-03-27 17:39       ` Luis Chamberlain
2023-03-28  2:31         ` Dominique Martinet
2023-03-28  5:14           ` Luis Chamberlain
2023-03-28 11:53           ` Christian Schoenebeck [this message]
2023-03-28 17:41             ` Luis Chamberlain
2023-03-28 22:08               ` Dominique Martinet
2023-03-29 11:19                 ` Christian Schoenebeck
2023-03-29 11:32                   ` Jeff Layton
2023-03-31 16:47                     ` Eric Van Hensbergen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2391219.DQnbcWml7j@silver \
    --to=linux_oss@crudebyte.com \
    --cc=amir73il@gmail.com \
    --cc=asmadeus@codewreck.org \
    --cc=ericvh@gmail.com \
    --cc=jlayton@kernel.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=mcgrof@kernel.org \
    --cc=p.raghav@samsung.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.