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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
