[Bug 1469143] Re: kpartx -d fails with image paths longer than 63 characters

Simo Punnonen simo.punnonen at f-secure.com
Mon Jun 29 12:21:59 UTC 2015


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 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



More information about the Ubuntu-server-bugs mailing list