I'll review the patches later this week. Thanks.
On Thu, Jul 14, 2016 at 03:28:11PM +0200, Stanislav Brabec wrote:
> Thing that should be done, but they are above scope of this patch set:
>
> - The current API does not support passing the name of the conflicting
> loop device to the error reported to the user. Just now, only debug
> messages contain it.
Maybe it would be enough to add "for more details see losetup" to the
error message :-)
> - The same what is done for mount needs to be done for losetup.
> API is now ready for it, so it should be simple.
OK
> - Add mount option looprw. It would allow to mount read only but
> initialize loop device R/W. Required for things like:
> mount -oro,loop,looprw,subvol=snapshots/1 -tbtrfs\
> /home.img /home-snapshots/1
> mount -oloop -tbtrfs /home.img /home
> (Without looprw, /home will be mounted read-only.)
It seem like an over-engineering, if you really need so complicated
setup then you can use losetup (rw) and + mount (or).
(All the loopdev support in mount(8) is questionable, there is many
another ways how you can create block device without mount(8) support.
The loopdev has extra support in mount(8) because it has been the
first one.)
> - I am not sure, whether loop reuse with combination of autoclear flag
> differences could cause preliminary releasing of loop device or
> keeping orphan loop device in some situations.
Reuse means another mount, I guess kernel keeps the loopdev alive
until there is any reference (e.g. VFS mount).
# mount /home/archive/fs-images/filesystems/ext2.img /mnt/test1
# losetup
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO
/dev/loop0 0 0 1 0 /home/archive/fs-images/filesystems/ext2.img 0
# mount /dev/loop0 /mnt/test2
# umount /mnt/test1
# losetup
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO
/dev/loop0 0 0 1 0 /home/archive/fs-images/filesystems/ext2.img 0
# umount /mnt/test2
# losetup
<nothing>
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
