You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See #125 . We need be tracking the loop devices, and what backs them. When we do certain kinds of device lookups, if we're provided a loop, we ought instead return the backing media (but not all the time, of course).
The text was updated successfully, but these errors were encountered:
I think we are tracking this. When I run with a block device connected to a loop device, the loop device shows up just fine, with the backing device as its "model name" (see attached image). The problem is that the underlying device doesn't show up as mounted.
This fundamental weirdness comes down to /proc/mounts showing the loop device, and mount showing the underlying device. Our users will presumably expect to see the underlying device (and the loop device) as related to the mount point. IMHO, the perfect situation would show:
/dev/sdo1 as mounted on /media/usb, perhaps indicating that it is by way of loop0
loop0 as mounted on /media/usb and representing /dev/sdo1 (this is happening already)
/media/usb as being /dev/loop0 is fine (this is happening already)
so all we really need do is link the underlying loop device to the mountpoint in a unidirectional fashion. I.e. you ought be able to unmount the filesystem from the underlying device, and have it run umount /media/usb, naturally destroying the loop0 device and dissolving the mount relationship.
a bigger problem is that we're not even indicating that an ext4 filesystem lives on the underlying device.
See #125 . We need be tracking the loop devices, and what backs them. When we do certain kinds of device lookups, if we're provided a loop, we ought instead return the backing media (but not all the time, of course).
The text was updated successfully, but these errors were encountered: