Detailed testing discovered some regressions in the loop reuse code:
1) mount -oloop=/dev/loop1 changed its behavior
Note that the proposed solution keeps overlay checks active. There is
another possible solution: disable all checks:
--- a/libmount/src/context_loopdev.c
+++ b/libmount/src/context_loopdev.c
@@ -215,7 +215,7 @@ int mnt_context_setup_loopdev(struct libmnt_context *cxt)
* mechanism to detect it. To prevent data corruption, the same loop
* device has to be recycled.
*/
- if (backing_file) {
+ if (backing_file && !loopval) {
rc = loopcxt_init(&lc, 0);
if (rc)
goto done_no_deinit;
There is still a small regression that could be fixed in the future:
If both the existing and the requested devices are read-only, it is
safe to not reuse existing loop device.
So we can think about allowing of:
losetup --read-only /dev/loop0 file.img
mount -oro,loop=/dev/loop1 file.img /mnt
2) If mount re-uses an existing loop device, then the loop device is
detached, even if autoclean flag is off.
Note that I was not able to find a mechanism, how mount gets the "loop"
in the output, so I did the change in mount, and not umount.
--
Best Regards / S pozdravem,
Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o. e-mail: sbrabec@xxxxxxxx
Křižíkova 148/34 (Corso IIa) tel: +49 911 7405384547
186 00 Praha 8-Karlín fax: +420 284 084 001
Czech Republic http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76
--
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
