From: Gao Xiang <hsiangkao@gmx.com>
To: Giuseppe Scrivano <gscrivan@redhat.com>
Cc: Chao Yu <chao@kernel.org>,
linux-erofs@lists.ozlabs.org, cyphar@cyphar.com,
hsiangkao@linux.alibaba.com, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v5] erofs: accept source file descriptor via fsconfig
Date: Tue, 4 Aug 2026 07:37:25 +0800 [thread overview]
Message-ID: <anEmNQWJzo-osec6@XiangdeMacBook-Pro.local> (raw)
In-Reply-To: <874ihbxviy.fsf@redhat.com>
On Mon, Aug 03, 2026 at 02:01:41PM +0200, Giuseppe Scrivano wrote:
> Chao Yu <chao@kernel.org> writes:
>
> > On 7/29/26 00:05, Giuseppe Scrivano wrote:
> >> Allow userspace to pass an already-opened file descriptor as the mount
> >> source instead of a path string. This is useful for tools that already
> >> hold an fd to the image, such as composefs reusing an existing erofs
> >> backing file.
> >> Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
> >> ---
> >> v4: https://lore.kernel.org/linux-fsdevel/20260717134147.1602735-1-gscrivan@redhat.com/
> >> v3: https://lore.kernel.org/linux-fsdevel/20260714154917.489993-1-gscrivan@redhat.com/
> >> v2: https://lore.kernel.org/linux-fsdevel/20260711071137.4130824-1-gscrivan@redhat.com/
> >> v1: https://lore.kernel.org/linux-fsdevel/ak5GfvVfWLJU1EwK@debian/
> >> Documentation/filesystems/erofs.rst | 15 ++++++
> >> fs/erofs/super.c | 73 ++++++++++++++++++++++++-----
> >> 2 files changed, 77 insertions(+), 11 deletions(-)
> >> diff --git a/Documentation/filesystems/erofs.rst
> >> b/Documentation/filesystems/erofs.rst
> >> index 4230884fb359..774e8b236d09 100644
> >> --- a/Documentation/filesystems/erofs.rst
> >> +++ b/Documentation/filesystems/erofs.rst
> >> @@ -139,6 +139,21 @@ inode_share Enable inode page sharing for this filesystem. Inodes wi
> >> page cache.
> >> =================== =========================================================
> >> +File-backed mounts
> >> +==================
> >> +
> >> +When CONFIG_EROFS_FS_BACKED_BY_FILE is enabled, EROFS file-backed images
> >> +can be mounted directly without a loopback block device. The backing file
> >> +can be given either as a path, or as an already-opened file descriptor.
> >> +
> >> +When a file descriptor is used, the kernel resolves its path and records it
> >> +so that /proc/mounts and similar interfaces can still report the mount
> >> +source.
> >> +
> >> +Only regular files are accepted as backing files; to mount an image that
> >> +resides on a block device, use the traditional block device mount path
> >> +instead.
> >
> > Do we need to add an entry to describe the new mount option source= in
> > "Mount options" section in erofs.rst?
> >
> > Thanks,
>
> I've another patch "erofs: reuse superblock for file-backed mounts" that
> also touches erofs.rst and it is currently based on top of this version.
> I wonder what is your preferred way to handle them.
EROFS dev branch usually has a small number of patches. Since Chao gave
a new suggestion, I think a v6 is needed (but you could add all
previous reviewed-by:).
And "erofs: reuse superblock for file-backed mounts" needs to be rebased
too, I will find time to play with it this week (or you could add a
testcase in erofs-utils experimental-tests if you have time.)
>
> Will maintainers deal with conflicts or do I need to submit them as a
> single series?
>
> Do you prefer a new submission v6 with the following fixup?
>
> diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst
> index c972a869f3e9..49c4e7dbc5d6 100644
> --- a/Documentation/filesystems/erofs.rst
> +++ b/Documentation/filesystems/erofs.rst
> @@ -137,6 +137,8 @@ fsoffset=%llu Specify block-aligned filesystem offset for the primary d
> inode_share Enable inode page sharing for this filesystem. Inodes with
> identical content within the same domain ID can share the
> page cache.
> +source=%s (For file-backed mounts) Specify the backing image as a path
> + or as an already-opened file descriptor.
Not quite sure "an already-opened file descriptor" is "%s", but I'm fine
since it's quite a minor one (it's unneeded to nitpick the
documentation).
Thanks,
Gao Xiang
>
> Thanks,
> Giuseppe
>
>
next prev parent reply other threads:[~2026-08-03 23:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 16:05 [PATCH v5] erofs: accept source file descriptor via fsconfig Giuseppe Scrivano
2026-07-29 1:40 ` Gao Xiang
2026-07-29 9:57 ` Jan Kara
2026-07-29 20:19 ` Gao Xiang
2026-07-30 9:45 ` Christian Brauner
2026-08-03 11:24 ` Chao Yu
2026-08-03 12:01 ` Giuseppe Scrivano
2026-08-03 23:37 ` Gao Xiang [this message]
2026-08-04 6:06 ` Giuseppe Scrivano
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=anEmNQWJzo-osec6@XiangdeMacBook-Pro.local \
--to=hsiangkao@gmx.com \
--cc=chao@kernel.org \
--cc=cyphar@cyphar.com \
--cc=gscrivan@redhat.com \
--cc=hsiangkao@linux.alibaba.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-fsdevel@vger.kernel.org \
/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