-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Roland PJ wrote: > Hi Bryn > > Just to avoid confusion, this is a different Roland from the original > query. Hi Roland, Noted ;) > Does this mean that dm-loop does not support sparse loop-back files? This version doesn't, no. It's not hard to add this though, although it does have some implications if they are used. We've had some discussions over whether this is necessary/desirable - is this something you'd like to see? > Also, it seems that the approach with dm-loop is that you sniff the > (current?) file mapping onto its underlying block device. What happens > if the loopback file is modified, or the file system hosting the > loopback file does some re-arranging? (I might be way off-tack here - > this was a first impression of the code). You'll find this in loop_get_file(): + /* + * We overload the S_SWAPFILE flag for loop targets because + * it provides the same no-truncate semantics we require, and holding + * onto i_sem is no longer an option. + */ + mutex_lock(&inode->i_mutex); + inode->i_flags |= S_SWAPFILE; + mutex_unlock(&inode->i_mutex); The bmap approach is also used for swapfiles (mm/swapfile.c) - the S_SWAPFILE inode flag was added in 2.6.16 when the changeover to mutexes happened. > I'd be interested in comparing dm-loop to vanilla loop which we > currently use. > There are patches to dmsetup that allow it to be called as "losetup" or "dmlosetup", providing the same options as the regular version, so it should be straightforward to compare. Regards, Bryn. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFY4nE6YSQoMYUY94RAuFyAJ9heEQvTZZ7dEkaIXQ9nxFy7mDx+gCfTozW FusS8of73r2GfGTchFWRvdc= =Eisk -----END PGP SIGNATURE----- -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
