All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gao Xiang <xiang@kernel.org>
To: "Friendy.Su@sony.com" <Friendy.Su@sony.com>
Cc: Gao Xiang <xiang@kernel.org>, "chao@kernel.org" <chao@kernel.org>,
	"linux-erofs@lists.ozlabs.org" <linux-erofs@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Yuezhang.Mo@sony.com" <Yuezhang.Mo@sony.com>,
	"Daniel.Palmer@sony.com" <Daniel.Palmer@sony.com>,
	Amir Goldstein <amir73il@gmail.com>, Jan Kara <jack@suse.cz>
Subject: Re: [PATCH v1] erofs: enable SB_I_ALLOW_HSM to support fanotify pre access event
Date: Wed, 21 Oct 2026 10:05:15 +0200	[thread overview]
Message-ID: <athyOw_WoXy9-NDR@MacBookPro> (raw)
In-Reply-To: <TY0PR04MB6191A63F6B79E4109D185F41FD9F2@TY0PR04MB6191.apcprd04.prod.outlook.com>

(+cc Amir, Jan)

On Wed, Oct 21, 2026 at 07:18:06AM +0000, Friendy.Su@sony.com wrote:
> Hi Gao,
> 
> Sorry for late reply.
> 
> We have considered fanotify in erofs-utils. I think it must be used with 
> file-backend mount. It actually utilizes FAN_PRE_ACCESS on ext4 or xfs. 
> Also file-backend mount can not support DAX mount.
> 
> But for our case, file-backend mount can not be used. Firstly, there is no 
> ext4 or xfs file system in actual environment to put a sparse erofs image 
> file. We have to mount a normal block device. Secondly, mount must be DAX.
> 
> The basic flow is file content is fetched from remote then filled into 
> local erofs file on the DAX mounted block device in FAN_PRE_ACCESS handler.
> 
> "/dev/loop0" is just an example, not our actual use case. The actual block 
> device is something like /dev/pmem0.
> 
> In order to make SB_I_ALLOW_HSM only set under block device backend, 
> we can do like this:
> 
> if (!erofs_is_fileio_mode(sbi)) {
>         /*
>          * Allow HSM to support fanotify pre access event
>          */

nit: single line /* Allow HSM to support fanotify pre access event */
     according to EROFS code style.

>         sb->s_iflags |= SB_I_ALLOW_HSM;
> }

I am fine with that as long as you limits SB_I_ALLOW_HSM **only if**
s_bdev is valid (IOWs, I hope we don't need to bother it with EROFS
SB_I_ALLOW_HSM + file-backed mounts; it aligns with other filesystems).

Also I think it would be better to add a testcase to check the basic
EROFS SB_I_ALLOW_HSM functionality in erofs-utils (see
experimental-tests). You don't need to add support for EROFS
SB_I_ALLOW_HSM directly in erofs-utils; but a basic functionality
testcase for this is needed.


BTW, for your use cases:

> mount must be DAX.

As for virtio-pmem, why not just use userfaultfd on the host for
virtio-pmem lazy pulling? for example,
https://github.com/firecracker-microvm/firecracker/issues/5740

Personally I still don't think monitoring FAN_PRE_ACCESS of EROFS for
this kind of usage is a good idea.

But anyway, it doesn't matter to much if it applies only to bdev/pmem.

> 
> How do you think?

Also please just adjust the patch subject to:

erofs: set SB_I_ALLOW_HSM for bdev-based mounts

Adjust the commit message accordingly to your use cases, and
explain file-backed mounts are not your cases in the commit message
as well.

And since it enables SB_I_ALLOW_HSM, it might be better to
Cc fsnotify maintainers in the following versions.

Thanks,
Gao Xiang

> 
> Best Regards
> Friendy
> 
> ________________________________________
> From: Gao Xiang <xiang@kernel.org>
> Sent: Sunday, October 11, 2026 5:20
> To: Su, Friendy
> Cc: xiang@kernel.org; chao@kernel.org; linux-erofs@lists.ozlabs.org; linux-kernel@vger.kernel.org; Mo, Yuezhang; Palmer, Daniel (SGC)
> Subject: Re: [PATCH v1] erofs: enable SB_I_ALLOW_HSM to support fanotify pre access event
> 
> 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. 
> 
> 
> 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://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/tree/lib/backends/fanotify.c__;!!O7_YSHcmd9jp3hj_4dEAcyQ!3EhQW78Lg9hjdjMscHBj-V19jmMX6nlYdkPVufSmwLJEM5yM0uTCOLuqwilIL3MGLDqMV8LkNo1Chg$[git[.]kernel[.]org]
> ?
> 
> 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://urldefense.com/v3/__https://github.com/dragonflyoss/nydus/blob/v3/docs/fanotify.md__;!!O7_YSHcmd9jp3hj_4dEAcyQ!3EhQW78Lg9hjdjMscHBj-V19jmMX6nlYdkPVufSmwLJEM5yM0uTCOLuqwilIL3MGLDqMV8IXHHnVqQ$[github[.]com]
> 
> Thanks,
> Gao Xiang
> 
> 


  reply	other threads:[~2026-10-21  8:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-10  9:40 [PATCH v1] erofs: enable SB_I_ALLOW_HSM to support fanotify pre access event Friendy Su
2026-10-10 21:20 ` Gao Xiang
2026-10-21  7:18   ` Friendy.Su
2026-10-21  8:05     ` Gao Xiang [this message]
2026-10-21  8:43       ` Friendy.Su
2026-10-21  9:42         ` Amir Goldstein

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=athyOw_WoXy9-NDR@MacBookPro \
    --to=xiang@kernel.org \
    --cc=Daniel.Palmer@sony.com \
    --cc=Friendy.Su@sony.com \
    --cc=Yuezhang.Mo@sony.com \
    --cc=amir73il@gmail.com \
    --cc=chao@kernel.org \
    --cc=jack@suse.cz \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.