linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Vivek Goyal <vgoyal@redhat.com>,
	overlayfs <linux-unionfs@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Max Reitz <mreitz@redhat.com>
Subject: Re: virtiofs uuid and file handles
Date: Wed, 23 Sep 2020 09:44:06 +0200	[thread overview]
Message-ID: <CAJfpegvNZ6Z7uhuTdQ6quBaTOYNkAP8W_4yUY4L2JRAEKxEwOQ@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxg_FV8U833qVkgPaAWJ4MNcnGoy9Gci41bmak4_ROSc3g@mail.gmail.com>

On Wed, Sep 23, 2020 at 4:49 AM Amir Goldstein <amir73il@gmail.com> wrote:

> I think that the proper was to implement reliable persistent file
> handles in fuse/virtiofs would be to add ENCODE/DECODE to
> FUSE protocol and allow the server to handle this.

Max Reitz (Cc-d) is currently looking into this.

One proposal was to add  LOOKUP_HANDLE operation that is similar to
LOOKUP except it takes a {variable length handle, name} as input and
returns a variable length handle *and* a u64 node_id that can be used
normally for all other operations.

The advantage of such a scheme for virtio-fs (and possibly other fuse
based fs) would be that userspace need not keep a refcounted object
around until the kernel sends a FORGET, but can prune its node ID
based cache at any time.   If that happens and a request from the
client (kernel) comes in with a stale node ID, the server will return
-ESTALE and the client can ask for a new node ID with a special
lookup_handle(fh, NULL).

Disadvantages being:

 - cost of generating a file handle on all lookups
 - cost of storing file handle in kernel icache

I don't think either of those are problematic in the virtiofs case.
The cost of having to keep fds open while the client has them in its
cache is much higher.

Thanks,
Miklos

  reply	other threads:[~2020-09-23  7:44 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <a8828676-210a-99e8-30d7-6076f334ed71@virtuozzo.com>
     [not found] ` <CAOQ4uxgZ08ePA5WFOYFoLZaq_-Kjr-haNzBN5Aj3MfF=f9pjdg@mail.gmail.com>
     [not found]   ` <1bb71cbf-0a10-34c7-409d-914058e102f6@virtuozzo.com>
     [not found]     ` <CAOQ4uxieqnKENV_kJYwfcnPjNdVuqH3BnKVx_zLz=N_PdAguNg@mail.gmail.com>
     [not found]       ` <dc696835-bbb5-ed4e-8708-bc828d415a2b@virtuozzo.com>
     [not found]         ` <CAOQ4uxg0XVEEzc+HyyC63WWZuA2AsRjJmbZBuNimtj=t+quVyg@mail.gmail.com>
     [not found]           ` <20200922210445.GG57620@redhat.com>
2020-09-23  2:49             ` virtiofs uuid and file handles Amir Goldstein
2020-09-23  7:44               ` Miklos Szeredi [this message]
2020-09-23  9:56                 ` Amir Goldstein
2020-09-23 11:12                   ` Miklos Szeredi
2021-05-29 16:05                     ` Amir Goldstein
2021-05-31 14:11                       ` Miklos Szeredi
2021-05-31 18:12                         ` Amir Goldstein
2021-06-01 14:49                           ` Vivek Goyal
2021-06-01 15:42                             ` Amir Goldstein
2021-06-01 16:08                               ` Max Reitz
2021-06-01 18:23                                 ` Amir Goldstein
2022-09-11 10:14                 ` Persistent FUSE file handles (Was: virtiofs uuid and file handles) Amir Goldstein
2022-09-11 15:16                   ` Bernd Schubert
2022-09-11 15:29                     ` Amir Goldstein
2022-09-11 15:55                       ` Bernd Schubert
2022-09-12 13:16                   ` Vivek Goyal
2022-09-12 13:38                     ` Amir Goldstein
2022-09-12 14:35                       ` Vivek Goyal
2022-09-12 15:07                         ` Amir Goldstein
2022-09-12 19:56                           ` Vivek Goyal
2022-09-13  2:07                             ` Amir Goldstein

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=CAJfpegvNZ6Z7uhuTdQ6quBaTOYNkAP8W_4yUY4L2JRAEKxEwOQ@mail.gmail.com \
    --to=miklos@szeredi.hu \
    --cc=amir73il@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=mreitz@redhat.com \
    --cc=vgoyal@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).