Comment 27 for bug 185878

Martin & Colin,

I've analyzed a performance problem in `grub-probe` on my Karmic system, in grub2, and found that it was caused by repeated BLKFLSBUF ioctls. Each call takes about .5 second and the overall probe does the ioctl dozens of times. Of course both of those factors will be different on each system, but in general I would expect them to be worse -- this system has 2.5GHz QC CPU, 4GiB memory, only one disk and only 2 OS partitions -- it could be _much_ worse.

In comment #17, Colin Watson wrote:

> grub needs to close and reopen the disk device, or (more easily) use the BLKFLSBUF ioctl.

In my grub2 `strace grub-probe` output, every single open() of a disk device was followed by a close() of that device before any other disk devices were accessed. In fact, it so happened that fd #4 was used every for every single read from a whole-disk or partition device, so clearly there was no overlap of open times.

Due to this problem, each OS update which changes anything to do with grub (e.g. grub2 updates, but also kernel updates [which trigger a grub rescan & initrd rebuild]) takes many minutes to complete. Karmic has what appear to be dozens if not hundreds of duplicate bug reports about grub install failing -- many with error codes indicating a user interrupt. I take these to mean that the grub update is taking so long that the user manually aborts it, then raises a bug about the abort!

I have not tested your grub1 PPA (or grub1 at all). I just wanted to alert you to this: _if_, during the process of scanning, it ends up doing a lot of BLKFLSBUF ioctls, it will have this problem. I suspect that the alternative solution of always making sure one has closed whole-disk devices before opening partition devices & vice-versa, won't have this performance problem.

I'm going to email this same comment to the Debian 362028 tracker (assuming it will receive email from a random email address...)