On 02 Dec 2014 14:29, Phillip Susi wrote: > 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. i agree the kernel should be fixed. but like i said, it isn't today, and it won't be for a while, and even then it'll take a while for all those fixed kernel versions to percolate out to distros. > As a workaround though, you might consider just not using losetup -P > in the first place and just run partx when you want to activate > partitions. This also has the advantage of working even when the loop > module is not loaded with the max_parts argument. thanks, wasn't aware of the partx tool -mike
Attachment:
signature.asc
Description: Digital signature
