grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

update-grub and grub-probe


From: Kevin Mitchell
Subject: update-grub and grub-probe
Date: Sun, 26 Jul 2009 02:46:46 -0700

I have found the update-grub process to be excruciatingly slow on at
least two SATA systems. On my older system with a VIA
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE, controller
things seem to work quite nicely.

One of the SATA systems is a Thinkpad T60 laptop with a 82801GBM/GHM
(ICH7 Family) SATA AHCI Controller, the other is a server with a 3ware
8506-4LP 4 port RAID controller runing raid10 so you could say that
the problem spans a decent spectrum. Other than the IDE/SATA
distinction between the working/not working as nicely cases, the two
SATA systems are using XFS file systems wheras the IDE system is using
Reiser. There is a Debian bug #508834
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508834 in which I and
at least one other user have experienced this problem. To sumarize,
the problematic area seems to be at util/grub-probe.c:368
grub_init_all ()

Without understanding what exactly this problem is, or how to solve it
on a fundamental level, it does seem kind of silly that grub-probe
gets called so many times during the update-grub process. Each time it
is called it must go through the grub_init_all () again which even in
the best of circumstances can't be that efficient. One obvious problem
seems to be that grub-probe can only process one query at a time. As a
result there are several places in the update-grub code path where
grub-probe is called in rapid succession to obtain different pieces of
information about the same device.

The less trivial problem is there are a lot of circumstances in which
grub-probe is called to get the same information about the same device
more than once in an update-grub run. The problem is that in most
cases this is being done because in general, these could in fact be
different devices based on your configuration. There would therefore
need to be some kind of caching mechanism to store information already
gathered and then some way of determining if a given grub-probe target
had already been probed.

I was thinking of trying to see if I couldn't improve the efficiency
of the update-grub process, but I wanted to hear from the pros if
there are any caveats or deliberate design decisions that have been
made in this area.

Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]