Re: [PATCH] the dm-loop target

Mikulas Patocka
2025-03-04T11:18:22Z

On Tue, 4 Mar 2025, Dave Chinner wrote:

> On Mon, Mar 03, 2025 at 10:03:42PM +0100, Mikulas Patocka wrote:
> >
> >
> > On Mon, 3 Mar 2025, Christoph Hellwig wrote:
> >
> > > On Mon, Mar 03, 2025 at 05:16:48PM +0100, Mikulas Patocka wrote:
> > > > What should I use instead of bmap? Is fiemap exported for use in the
> > > > kernel?
> > >
> > > You can't do an ahead of time mapping. It's a broken concept.
> >
> > Swapfile does ahead of time mapping. And I just looked at what swapfile
> > does and copied the logic into dm-loop. If swapfile is not broken, how
> > could dm-loop be broken?
>
> Swap files cannot be accessed/modified by user code once the
> swapfile is activated. See all the IS_SWAPFILE() checked throughout
> the VFS and filesystem code.
>
> Swap files must be fully allocated (i.e. not sparse), nor contan
> shared extents. This is required so that writes to the swapfile do
> not require block allocation which would change the mapping...
>
> Hence we explicitly prevent modification of the underlying file
> mapping once a swapfile is owned and mapped by the kernel as a
> swapfile.
>
> That's not how loop devices/image files work - we actually rely on
> them being:
>
> a) sparse; and
> b) the mapping being mutable via direct access to the loop file
> whilst there is an active mounted filesystem on that loop file.
>
> and so every IO needs to be mapped through the filesystem at
> submission time.
>
> The reason for a) is obvious: we don't need to allocate space for
> the filesystem so it's effectively thin provisioned. Also, fstrim on
> the mounted loop device can punch out unused space in the mounted
> filesytsem.
>
> The reason for b) is less obvious: snapshots via file cloning,
> deduplication via extent sharing.
>
> The clone operaiton is an atomic modification of the underlying file
> mapping, which then triggers COW on future writes to those mappings,
> which causes the mapping to the change at write IO time.
>
> IOWs, the whole concept that there is a "static mapping" for a loop
> device image file for the life of the image file is fundamentally
> flawed.

I'm not trying to break existing loop.

But some users don't use COW filesystems, some users use fully provisioned
files, some users don't need to write to a file when it is being mapped -
and for them dm-loop would be viable alternative because of better
performance.

The Android people concluded that loop is too slow and rather than using
loop they want to map a file using a table with dm-linear targets over the
image of the host filesystem. So, they are already doing what dm-loop is
doing.

Mikulas