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