avoid the use of kpartx in file injection

Bug #1024586 reported by Pádraig Brady
30
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Invalid
Medium
Pádraig Brady

Bug Description

kpartx has various problems...

1. The git repo on kernel.org is no longer available.

2. kpartx -l had side effects:
  $ kpartx -l /bin/ls
  $ ls
  text file busy
To fix you need to run losetup -a to find the assigned loopback device
and then losetup -d /dev/loop...

3. On an unconnected loop device we get warnings, but an EXIT_SUCCESS ?
  # kpartx -a /dev/loop1 && echo EXIT_SUCCESS
  read error, sector 0
  llseek error
  llseek error
  llseek error
  EXIT_SUCCESS

4. Also for a loop device that is connected,
I get a "failed" warning, but the EXIT_SUCCESS
is appropriate in that case as the mapped device
is present and usable
  # kpartx -a /dev/loop0
 /dev/mapper/loop0p1: mknod for loop0p1 failed: File exists

5. There are issues with qcow2 encoded cirros images
# qemu-img info cirros-0.3.0-x86_64-disk.img
image: cirros-0.3.0-x86_64-disk.img
file format: qcow2
virtual size: 39M (41126400 bytes)
disk size: 9.3M
cluster_size: 65536
# qemu-nbd -c /dev/nbd15 $PWD/cirros-0.3.0-x86_64-disk.img
# ls -la /sys/block/nbd15/pid
-r--r--r--. 1 root root 4096 Jun 8 10:19 /sys/block/nbd15/pid
# kpartx -a /dev/nbd15
device-mapper: resume ioctl on nbd15p1 failed: Invalid argument
create/reload failed on nbd15p1

6. There was a report that `kpartx -[ad]` were not synchronous
with the creation/deletion of /dev/mapper/nbdXXpX
requiring sleep calls to avoid failures.

The best way to avoid the need for kpartx is to use the
newer kernel auto partition mapping feature available since kernel 3.2
and only fallback to kpartx if not exists ...
  '%sp%s' % (self.device, self.partition)
Note the nbd module must be mounted with param max_part=16 etc.
so that would need documentation.
Also we would need to test the same applies for raw loopback images
as well as nbd

Revision history for this message
Pádraig Brady (p-draigbrady) wrote :

I just noticed a mail to say in kernel Loop device partition scanning is unreliable
https://lkml.org/lkml/2012/7/19/264
Something to keep an eye on

Revision history for this message
Pádraig Brady (p-draigbrady) wrote :

losetup 2.19.1 doesn't have the -P option to enable scanning
newer versions do have that.

http://lkml.indiana.edu/hypermail/linux/kernel/1108.1/03151.html

Revision history for this message
Vish Ishaya (vishvananda) wrote :

it can be enabled to work with loopback as well, but the loopback driver is often not a separate module so you have to start with kernel parameters (i.e. adding loop.max_part=16 to the end of your grub entry)

Changed in nova:
milestone: folsom-3 → folsom-rc1
Changed in nova:
milestone: folsom-rc1 → none
Revision history for this message
Pádraig Brady (p-draigbrady) wrote :

I noticed qemu-nbd also has a -P option, to expose a particular partition, which could be useful.

Also https://review.openstack.org/#/c/12634/ addresses part of this bug in that
it allows the use of the max_part option to the nbd module, thus supporting
point 5 in this report (re cirros images).

While enabling scanning for loop devices might be problematic as per comment 1,
doing so for nbd is probably catered for by the existing nova code which
sleeps until /sys/block/nbd15/pid is present before proceeding to the mapping stage.

Revision history for this message
Sean Dague (sdague) wrote :

For other reasons we stopped using this path for file injection by default. This bug is sufficiently old that I assume it is no longer in progress.

Changed in nova:
status: In Progress → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.