Comment 5 for bug 1469143

Simo

Go ahead an propose the patch you are thinking on.

Best!

On Monday, June 29, 2015, Simo Punnonen <email address hidden> wrote:

> is the lo_name which gets stored in the loop_info structure actually
> required to be an actual file path or is it enough to be an arbitrary
> string identifier?
>
> If it doesn't have to be a file path, could it be for instance a sha1
> hash of the provided path? That fits into 40 chars and is relatively
> fast to calculate. A sha1 identifier would make it really hard to
> collide with other loop device identifiers _unless_ you pass and use the
> same relative image path in two separate instances (which is also an
> existing problem).
>
> Alternatively it would be nice if the lo_name identifier wasn't actually
> based on path but some unique property of the mounted file, that way you
> would only need to point to an image, regardless of the path and kpartx
> could find if that specific image is mounted or not.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1469143
>
> Title:
> kpartx -d fails with image paths longer than 63 characters
>
> Status in multipath-tools package in Ubuntu:
> In Progress
> Status in multipath-tools source package in Precise:
> New
> Status in multipath-tools source package in Trusty:
> New
> Status in multipath-tools source package in Utopic:
> New
> Status in multipath-tools source package in Vivid:
> New
>
> Bug description:
> $ apt-show-versions multipath-tools
> multipath-tools:amd64/vivid 0.4.9-3ubuntu12 uptodate
>
> Reproduce:
> Mount an image from a path longer than 63 chars succeeds:
> $ sudo kpartx -av
> asfd1asdf2asdf3asdf4asdf5asdf6asfd7asdf8asdf9asf10asdf11asdf12asdf13/disk.img
> add map loop0p1 (252:0): 0 409600 linear /dev/loop0 2048
> add map loop0p2 (252:1): 0 2 linear /dev/loop0 411648
> add map loop0p5 : 0 819200 linear /dev/loop0 413696
> add map loop0p6 : 0 819200 linear /dev/loop0 1234944
> add map loop0p7 : 0 819200 linear /dev/loop0 2056192
> add map loop0p8 : 0 1316864 linear /dev/loop0 2877440
>
> but dismounting fails:
> $ sudo kpartx -dv
> asfd1asdf2asdf3asdf4asdf5asdf6asfd7asdf8asdf9asf10asdf11asdf12asdf13/disk.img
>
> strace shows that the parameter on the dismount appears to get cut at 63
> chars:
> ioctl(3, DM_LIST_VERSIONS, 0x15b89b0) = 0
>
> stat("asfd1asdf2asdf3asdf4asdf5asdf6asfd7asdf8asdf9asf10asdf11asdf12asdf13/disk.img",
> {st_mode=S_IFREG|0644, st_size=2147483648, ...}) = 0
> stat("/dev/loop0", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 0), ...}) =
> 0
> open("/dev/loop0", O_RDONLY) = 4
> ioctl(4, LOOP_GET_STATUS, {number=0, offset=0, flags=0,
> name="asfd1asdf2asdf3asdf4asdf5asdf6asfd7asdf8asdf9asf10asdf11asdf12a",
> ...}) = 0
> close(4) = 0
> stat("/dev/loop1", {st_mode=S_IFBLK|0660, st_rdev=makedev(7, 1), ...}) =
> 0
> open("/dev/loop1", O_RDONLY) = 4
> ioctl(4, LOOP_GET_STATUS, {number=0, offset=0, flags=0,
> name="asfd1asdf2asdf3asdf4asdf5asdf6asfd7asdf8asdf9asf10asdf11asdf12a",
> ...}) = -1 ENXIO (No such device or address)
>
> if the path is 63 chars or less, the dismount also succeeds.
>
> This is quickly becomes an issue if you want to use full disk paths in
> your shell scripts.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1469143/+subscriptions
>

--
Jorge Niedbalski R.
STS - Engineering Team
GPG:0x3DA28544, irc: niedbalski