Simo Go ahead an propose the patch you are thinking on.
Best! On Monday, June 29, 2015, Simo Punnonen <simo.punno...@f-secure.com> 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 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1469143 Title: kpartx -d fails with image paths longer than 63 characters To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1469143/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
