-----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. 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUfhM3AAoJENRVrw2cjl5RvhcH/iaVXICM0zOxyc7YFTeQ4Tkk 5NgLJpZGy8yp4maxJcoPJ8Eryfs6SuQdglVtfjtGLhTOVEvUObe9ALey1/oilfUI RCzBYyr+j9raD09MMA+yiNsYpeeptvWPRnPZF9TahRKWTMYSiOZoDMGQjvc1Rj3w uSLDcmcknt/YA0nOSml8xuI84k1EeaV/s9Gt5Q9Rgjw8kvv3C5xROM9JfgC7unY8 4nF3n8F5jfGeGU/NtJAYJn+WnsX69AyAvveeo5e3GdO43NP818rF2K/6d9tyyN0Z 5159ZqRur75m/pC2PqQFMeoJ/3vefbWEMrQ3D73yH22f41ignZobzKHbGcDygD4= =qPDy -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
