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
