From: Christian Brauner <brauner@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Jan Kara <jack@suse.cz>
Subject: Re: [PATCH] ovl: factor out some common helpers for backing files io
Date: Wed, 13 Sep 2023 10:29:17 +0200 [thread overview]
Message-ID: <20230913-galaxie-irrfahrt-a815cf10ebdc@brauner> (raw)
In-Reply-To: <20230912185408.3343163-1-amir73il@gmail.com>
On Tue, Sep 12, 2023 at 09:54:08PM +0300, Amir Goldstein wrote:
> Overlayfs stores its files data in backing files on other filesystems.
>
> Factor out some common helpers to perform io to backing files, that will
> later be reused by fuse passthrough code.
>
> Suggested-by: Miklos Szeredi <miklos@szeredi.hu>
> Link: https://lore.kernel.org/r/CAJfpeguhmZbjP3JLqtUy0AdWaHOkAPWeP827BBWwRFEAUgnUcQ@mail.gmail.com
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>
> Miklos,
>
> This is the re-factoring that you suggested in the FUSE passthrough
> patches discussion linked above.
>
> This patch is based on the overlayfs prep patch set I just posted [1].
>
> Although overlayfs currently is the only user of these backing file
> helpers, I am sending this patch to a wider audience in case other
> filesystem developers want to comment on the abstraction.
>
> We could perhaps later considering moving backing_file_open() helper
> and related code to backing_file.c.
>
> In any case, if there are no objections, I plan to queue this work
> for 6.7 via the overlayfs tree.
>
> Thanks,
> Amir.
>
> [1] https://lore.kernel.org/linux-unionfs/20230912173653.3317828-1-amir73il@gmail.com/
>
>
> MAINTAINERS | 2 +
> fs/Kconfig | 4 +
> fs/Makefile | 1 +
> fs/backing_file.c | 160 +++++++++++++++++++++++++++++++++++
I'm sorry but I'm missing mountains of context.
How is that related to the backing file stuff exactly?
The backing file stuff has this unpleasant
file->f_inode == real_inode != file->f_path->dentry->d_inode
that we all agree is something we really don't like. Is FUSE trying to
do the same thing and build an read_iter/write_iter abstraction around
it? I really really hope that's not the case.
And why are we rushing this to a VFS API? This should be part of the
FUSE series that make it necessary to hoist into the VFS not in
overlayfs work that prematurely moves this into the VFS.
next prev parent reply other threads:[~2023-09-13 8:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-12 18:54 [PATCH] ovl: factor out some common helpers for backing files io Amir Goldstein
2023-09-13 5:59 ` Amir Goldstein
2023-09-13 8:29 ` Christian Brauner [this message]
2023-09-13 11:24 ` Amir Goldstein
2023-09-21 15:51 ` Amir Goldstein
2023-09-23 9:52 ` Amir Goldstein
2023-09-13 8:37 ` Christian Brauner
2023-09-13 11:26 ` Amir Goldstein
2023-09-13 12:00 ` Amir Goldstein
2023-09-13 16:41 ` Christian Brauner
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=20230913-galaxie-irrfahrt-a815cf10ebdc@brauner \
--to=brauner@kernel.org \
--cc=amir73il@gmail.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=viro@zeniv.linux.org.uk \
/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