| 1 |
Thanks for the replies; my apologies for the delay in repying |
| 2 |
back.... |
| 3 |
|
| 4 |
Based on the replies, I was able to track the problem down. The cdb |
| 5 |
"patch" is incompatable with the latest version of portage. Removing |
| 6 |
that from /etc/portage/modules allows portage to work. |
| 7 |
|
| 8 |
That said, there is still the bug of using the filesystem as a |
| 9 |
database. It now takes about thirty minutes for any emerge run |
| 10 |
to finish reading in /var/cache/edb/dep and most of /var/db/pkg. |
| 11 |
|
| 12 |
It is imperative that portage use a single file for those databases. |
| 13 |
(One per db is fine, in case the above is ambiguous.) |
| 14 |
|
| 15 |
This is the same problem that git ran into, leading to pack files, |
| 16 |
or that cnews and inn hit, leading to the rotating spool files. |
| 17 |
|
| 18 |
It may work reasonably well on a headless server, with only a few |
| 19 |
packages installed. But on a general purpose workstation with |
| 20 |
many packages installed it falls over hard. |
| 21 |
|
| 22 |
Incidently, the above 30 minute minimum run time is even when |
| 23 |
running with --nodeps. |
| 24 |
|
| 25 |
I'll also be posting a bug report about unmerging. Portage is |
| 26 |
stat(2)ing *every* file under a directory that might need removal |
| 27 |
rather than just checking whether there are any entries in the dir. |
| 28 |
Running stat(2) on everything in /usr/lib, /usr/bin, /usr/share/doc |
| 29 |
and similar completely thrashes the dirent cache. It is even worse |
| 30 |
than running ldconfig when no changes were made in dirs that ldconfig |
| 31 |
monitors. |
| 32 |
|
| 33 |
Thanks for the work; I hope to see performance improvements this year. |
| 34 |
|
| 35 |
-JimC |
| 36 |
-- |
| 37 |
James Cloos <cloos@×××××××.com> OpenPGP: 1024D/ED7DAEA6 |
| 38 |
|
| 39 |
|
| 40 |
-- |
| 41 |
gentoo-portage-dev@g.o mailing list |
Archives