Re: [PATCH 18/33] fuse: use an unrestricted backing device with iomap pagecache io

["Darrick J. Wong" <djwong@kernel.org>]

On Wed, Apr 29, 2026 at 07:28:23AM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> With iomap support turned on for the pagecache, the kernel issues
> writeback to directly to block devices and we no longer have to push all
> those pages through the fuse device to userspace.  Therefore, we don't
> need the tight dirty limits (~1M) that are used for regular fuse.  This
> dramatically increases the performance of fuse's pagecache IO.
> 
> A reviewer of this patch asked why we reset s_bdi to the noop bdi and
> call super_setup_bdi_name a second time, instead of simply clearing
> STRICTLIMIT and resetting the bdi max ratio.
> 
> That's sufficient to undo the effects of fuse_bdi_init, yes.  However
> the BDI gets created with the name "$major:$minor{-fuseblk}" and there
> are "management" scripts that try to tweak fuse BDIs for better
> performance.
> 
> I don't want some dumb script to mismanage a fuse-iomap filesystem
> because it can't tell the difference, so I create a new bdi with the
> name "$major:$minor.iomap" to make it obvious.  But super_setup_bdi_name
> gets cranky if s_bdi isn't set to noop and we don't want to fail a mount
> here due to ENOMEM so ... I implemented this weird switcheroo code.
> 
> Also, userspace scripts such as udev rules can modify the bdi as soon as
> it appears in sysfs, so we can't run the fuse_bdi_init code in reverse
> and expect that will undo everything.
> 
> Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
> ---
>  fs/fuse/fuse_iomap.c |   21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> 
> diff --git a/fs/fuse/fuse_iomap.c b/fs/fuse/fuse_iomap.c
> index 3136326bafb858..3c40a1e58017b3 100644
> --- a/fs/fuse/fuse_iomap.c
> +++ b/fs/fuse/fuse_iomap.c
> @@ -718,6 +718,27 @@ const struct fuse_backing_ops fuse_iomap_backing_ops = {
>  void fuse_iomap_mount(struct fuse_mount *fm)
>  {
>  	struct fuse_conn *fc = fm->fc;
> +	struct super_block *sb = fm->sb;
> +	struct backing_dev_info *old_bdi = sb->s_bdi;
> +	char *suffix = sb->s_bdev ? "-fuseblk" : "-fuse";
> +	int res;
> +
> +	/*
> +	 * sb->s_bdi points to the initial private bdi.  However, we want to
> +	 * redirect it to a new private bdi with default dirty and readahead
> +	 * settings because iomap writeback won't be pushing a ton of dirty
> +	 * data through the fuse device.  If this fails we fall back to the
> +	 * initial fuse bdi.

Codex points out that it's possible to create non-iomap regular file
inodes after we've set up this fuse.iomap bdi.  If that happens, the
non-iomap files won't be subject the strictlimit/max_ratio restrictions
imposed on non-iomap fuse filesystems.  I don't think this is a serious
concern because one has to have CAP_SYS_RAWIO privilege to enable iomap,
but I'll change this patch to put back the old behavior.

--D

> +	 */
> +	sb->s_bdi = &noop_backing_dev_info;
> +	res = super_setup_bdi_name(sb, "%u:%u%s.iomap", MAJOR(fc->dev),
> +				   MINOR(fc->dev), suffix);
> +	if (res) {
> +		sb->s_bdi = old_bdi;
> +	} else {
> +		bdi_unregister(old_bdi);
> +		bdi_put(old_bdi);
> +	}
>  
>  	/*
>  	 * Enable syncfs for iomap fuse servers so that we can send a final
> 
>