[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251029143823.GL6174@frogsfrogsfrogs>
Date: Wed, 29 Oct 2025 07:38:23 -0700
From: "Darrick J. Wong" <djwong@...nel.org>
To: Christoph Hellwig <hch@....de>
Cc: miklos@...redi.hu, brauner@...nel.org, linux-ext4@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/1] iomap: allow NULL swap info bdev when activating
 swapfile
On Wed, Oct 29, 2025 at 09:40:48AM +0100, Christoph Hellwig wrote:
> On Tue, Oct 28, 2025 at 05:44:26PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@...nel.org>
> > 
> > All current users of the iomap swapfile activation mechanism are block
> > device filesystems.  This means that claim_swapfile will set
> > swap_info_struct::bdev to inode->i_sb->s_bdev of the swap file.
> > 
> > However, in the future there could be fuse+iomap filesystems that are
> > block device based but don't set s_bdev.  In this case, sis::bdev will
> > be set to NULL when we enter iomap_swapfile_activate, and we can pick
> > up a bdev from the first iomap mapping that the filesystem provides.
> 
> Could, or will be?  I find the way the swapfiles work right now
> disgusting to start with, but extending that bypass to fuse seems
> even worse.
Yes, "Could", in the sense that a subsequent fuse patch wires up sending
FUSE_IOMAP_BEGIN to the fuse server to ask for layouts for swapfiles,
and the fuse server can reply with a mapping or EOPNOTSUPP to abort the
swapon.  (There's a separate FUSE_IOMAP_IOEND req at deactivation time).
"Already does" in the sense that fuse already supports swapfiles(!) if
your filesystem implements FUSE_BMAP and attaches via fuseblk (aka
ntfs3g).
--D
Powered by blists - more mailing lists
 
