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

[Karel Zak <kzak@redhat.com>]

On Tue, Dec 02, 2014 at 02:29:59PM -0500, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/27/2014 4:16 PM, Mike Frysinger wrote:
> > 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).
> 
> As long as the kernel has a flag that is supposed to cause it to
> interpret the partition table, then it should *work* and not silently
> fail.  This is a bug in the kernel that should be fixed.

Yes, I don't like the idea with the ioctl workaround in losetup. It's
fine to use such workarounds in stable branches or in distro specific
patches, but I really don't want to use workarounds for bugs in regular
releases (master branch). 

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com