From: Gao Xiang <xiang@kernel.org>
To: Friendy Su <friendy.su@sony.com>
Cc: xiang@kernel.org, chao@kernel.org, linux-erofs@lists.ozlabs.org,
linux-kernel@vger.kernel.org, Yuezhang Mo <Yuezhang.Mo@sony.com>,
Daniel Palmer <daniel.palmer@sony.com>
Subject: Re: [PATCH v1] erofs: enable SB_I_ALLOW_HSM to support fanotify pre access event
Date: Sat, 10 Oct 2026 23:20:54 +0200 [thread overview]
Message-ID: <asqsNhtlXaEOrEky@XiangdeMacBook-Pro.local> (raw)
In-Reply-To: <20261010094000.2036805-1-friendy.su@sony.com>
Hi Friendy,
On Sat, Oct 10, 2026 at 05:40:00PM +0800, Friendy Su wrote:
> This patch makes erofs support a use case below:
>
> erofs file data are not available at local, but need be
> filled at fanotify pre access event handler.
>
> E.g. when format erofs to blob mode, meta data image
> is store locally, blob image size is big so it is stored remotely.
> At erofs mount, a loop device based on a sparse image file is
> used as blob device. The sparse image file size is equal to blob
> image size. Like:
>
> $ sudo mount -o device=/dev/loop1 /dev/sdb1 /mnt/erofs/
>
> Then at file access, need retrieve data from remote, then fill
> into sparse image at FAN_PRE_ACCESS event handler.
>
> Signed-off-by: Friendy Su <friendy.su@sony.com>
> Reviewed-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
> Reviewed-by: Daniel Palmer <daniel.palmer@sony.com>
> ---
> fs/erofs/super.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/erofs/super.c b/fs/erofs/super.c
> index 0967aace9f7f..b92d3353319d 100644
> --- a/fs/erofs/super.c
> +++ b/fs/erofs/super.c
> @@ -659,6 +659,10 @@ static int erofs_fc_fill_super(struct super_block *sb, struct fs_context *fc)
> sb->s_maxbytes = MAX_LFS_FILESIZE;
> sb->s_op = &erofs_sops;
>
> + /*
> + * Allow HSM to support fanotify pre access event
> + */
> + sb->s_iflags |= SB_I_ALLOW_HSM;
Did you notice
https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/tree/lib/backends/fanotify.c
?
I am not sure why EROFS itself needs to set SB_I_ALLOW_HSM because EROFS
is an immutable filesystem, its data should be considered as a golden
one and it shouldn't be partially filled.
Instead, SB_I_ALLOW_HSM should be set on the backing filesystems (ext4,
xfs, ...), and if I understand correctly, combining EROFS file-backed
mounts (pls don't use loop for this) already implements what you said
above.
And this functionality is already released in the latest erofs-utils
and Nydus v3:
https://github.com/dragonflyoss/nydus/blob/v3/docs/fanotify.md
Thanks,
Gao Xiang
prev parent reply other threads:[~2026-10-10 21:21 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 9:40 Friendy Su
2026-10-10 21:20 ` Gao Xiang [this message]
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=asqsNhtlXaEOrEky@XiangdeMacBook-Pro.local \
--to=xiang@kernel.org \
--cc=Yuezhang.Mo@sony.com \
--cc=chao@kernel.org \
--cc=daniel.palmer@sony.com \
--cc=friendy.su@sony.com \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®