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@xxxxxxxxx> > >> 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:
signature.asc
Description: Digital signature
