Re: losetup on a image file containing (GPT) partition doesn't create partition devices

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]

On 06 Oct 2014 17:56, Francis Moreau wrote:
> On 10/06/2014 05:47 PM, Dale R. Worley wrote:
> > From: Francis Moreau <francis.moro@gmail.com>
> >> Ok, so IMHO I think that losetup(8) should issue its own
> >> ioctl(BLKRRPART) and shouldn't rely on the kernel during the loop setup
> >> since it can fail silently. This way it can check the return value of
> >> ioctl() and moght choose to do it again in case the return value is -EBUSY.
> 
> Hm I was probably not clear, let me phase it again:
> 
> Ok, so IMHO I think that losetup(8) should issue its own
> ioctl(BLKRRPART) and shouldn't rely on the kernel during the loop setup
> since the kernel can fail silently. Using ioctl(BLKRRPART) allows
> losetup(8) to check the return value of ioctl() and might choose to do
> it again in case the return value is -EBUSY.

we've been tracking the same bug in Chromium OS:
  http://crbug.com/411693
basically, under load, using `losetup -P` randomly fails to create the relevant 
partition nodes.  atm we have hacks in place to call `blockdev --rereadpt` when 
it looks like the kernel has failed us.

it would be nice if the kernel didn't ignore the result of the ioctl thus 
allowing all errors to go unnoticed.  you can see this in drivers/block/loop.c 
where it calls ioctl_by_bdev multiple times and doesn't check the return value.

since all current kernels are broken though, and might be for the foreseeable 
future, having losetup issue the ioctl itself might be a good tradeoff.  i 
think it'd trigger unnecessary overhead (rescanning the device after it already 
worked), but seems better than having losetup try and check other sources (like 
if arbitrary partition nodes were created).
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]