All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luis Chamberlain <mcgrof@kernel.org>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: Dominique Martinet <asmadeus@codewreck.org>,
	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 10:41:02 -0700	[thread overview]
Message-ID: <ZCMmrnmZFcH65Orp@bombadil.infradead.org> (raw)
In-Reply-To: <2391219.DQnbcWml7j@silver>

On Tue, Mar 28, 2023 at 01:53:49PM +0200, Christian Schoenebeck wrote:
> 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

It was this one. I hadn't looked at the other ones.

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

My experience is that cache=loose is totally useless.

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

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

I got a wiki account now and I was the one who had clarified this.

  Luis

  reply	other threads:[~2023-03-28 17:41 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
2023-03-28 17:41             ` Luis Chamberlain [this message]
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=ZCMmrnmZFcH65Orp@bombadil.infradead.org \
    --to=mcgrof@kernel.org \
    --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=linux_oss@crudebyte.com \
    --cc=lucho@ionkov.net \
    --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.