Bug#362028: solution not so good for grub2 (maybe also grub1)

[Bela Lubkin]

Copied from a comment I just put into Ubuntu bug 185878:

>Bela<

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...)