[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251030145402.GV4015566@frogsfrogsfrogs>
Date: Thu, 30 Oct 2025 07:54:02 -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 Thu, Oct 30, 2025 at 07:00:08AM +0100, Christoph Hellwig wrote:
> On Wed, Oct 29, 2025 at 07:38:23AM -0700, Darrick J. Wong wrote:
> > > > 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).
>
> Maybe spell that out.
Will do.
> > "Already does" in the sense that fuse already supports swapfiles(!) if
> > your filesystem implements FUSE_BMAP and attaches via fuseblk (aka
> > ntfs3g).
>
> Yikes. This is just such an amazingly bad idea.
Swapfiles in general (including doing it via iomap)? Or just the magic
hooboo of "turn on this fugly bmapping call and bammo the kernel can
take over your file at any time!!" ?
--D
Powered by blists - more mailing lists