Linux filesystem development
 help / color / mirror / Atom feed
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
> 
> 

  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