Re: [PATCH] the dm-loop target

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 03, 2025 at 03:57:23PM +0100, Heinz Mauelshagen wrote:
> dm-loop avoids the file system abstraction, thus gains the resulting
> performance advantage versus the loop driver.

How?

> dm-loop obviously requires full provisioning, thus sparse files are being
> detected and error handled.
> 
> Additionally, block relocation on CoW filesystems has to be prevented.
> dm-loop uses S_SWAPFILE to do so but that flag's limited to swap semantics
> and is overloaded as such.
> 
> Should we avoid the flag and enforce use of non-CoW filesystems for backing
> or checks on non-CoW files (inode->i_flags)?

No, ->bmap is fundamentally flawed.  No new code should be using it, and
we need to move the places still using it (most notably swap and the md
bitmap code) off it.  It can't deal with any kind of changes to the file
system topology and is a risk to data corruption because if used in the
I/O path it bypasses the file system entirely..  If it wasn't we'd use it
in the loop driver.





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux