From: Miklos Szeredi <[email protected]>
To: Amir Goldstein <[email protected]>
Cc: Bernd Schubert <[email protected]>,
Moinak Bhattacharyya <[email protected]>,
[email protected], [email protected],
[email protected]
Subject: Re: [PATCH] Fuse: Add backing file support for uring_cmd
Date: Mon, 24 Feb 2025 13:08:27 +0100 [thread overview]
Message-ID: <CAJfpegv=3=rfxPDTP3HhWDcVJZrb_+ti7zyMrABYvX1w668XqQ@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxjhi_0f4y5DgrQr+H01j4N7d4VRv3vNidfNYy-cP8TS4g@mail.gmail.com>
On Fri, 21 Feb 2025 at 19:31, Amir Goldstein <[email protected]> wrote:
> BTW, I am now trying to work out the API for setting up a backing file
> for an inode at LOOKUP time for passthrough of inode operations.
> For this mode of operation, I was considering to support OPEN
> response with FOPEN_PASSTHROUGH and zero backing_id to mean
> "the backing file that is associated with the inode".
> I've actually reserved backing_id 0 for this purpose.
> In this mode of operations the problem at hand will become moot.
>
> One way to deal with the API of FOPEN_PASSTHROUGH in
> io_uring is to only use this mode of operation.
> IOW, LOOKUP response could have a backing fd and not
> a backing id and then the backing ids are not even exposed to
> server because the server does not care - for all practical purposes
> the nodeid is the backing id.
Yeah, the backing-id thing should not be needed for io-uring.
One complaint about the current passthrough API is that it adds extra
syscalls, which is expensive nowadays.
> I personally don't mind if inode operations passthrough
> that are setup via LOOKUP response, will require io_uring.
> Both features are about metadata operations performance,
> so it kind of makes sense to bundle them together, does it not?
Right, this would be the least complex solution. We could also add
an ioctl(FUSE_DEV_IOC_LOOKUP_REPLY), which would work with the
non-uring API.
Thanks,
Miklos
next prev parent reply other threads:[~2025-02-24 12:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-21 15:19 [PATCH] Fuse: Add backing file support for uring_cmd Moinak Bhattacharyya
2025-02-21 15:24 ` Bernd Schubert
2025-02-21 15:36 ` Moinak Bhattacharyya
2025-02-21 16:14 ` Bernd Schubert
2025-02-21 16:17 ` Bernd Schubert
2025-02-21 16:35 ` Amir Goldstein
2025-02-21 17:24 ` Bernd Schubert
2025-02-22 22:33 ` Moinak Bhattacharyya
2025-02-21 16:24 ` Amir Goldstein
2025-02-21 17:13 ` Bernd Schubert
2025-02-21 17:25 ` Amir Goldstein
2025-02-21 17:44 ` Bernd Schubert
2025-02-21 18:13 ` Moinak Bhattacharyya
2025-02-21 18:14 ` Moinak Bhattacharyya
2025-02-21 18:21 ` Amir Goldstein
2025-02-22 22:13 ` Moinak Bhattacharyya
2025-02-21 18:23 ` Bernd Schubert
2025-02-21 18:31 ` Amir Goldstein
2025-02-24 12:08 ` Miklos Szeredi [this message]
2025-02-24 16:06 ` Moinak Bhattacharyya
2025-02-24 16:24 ` Miklos Szeredi
2025-02-24 12:27 ` Pavel Begunkov
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='CAJfpegv=3=rfxPDTP3HhWDcVJZrb_+ti7zyMrABYvX1w668XqQ@mail.gmail.com' \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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