1 |
Hi list |
2 |
|
3 |
For the longest time I've had portage configured to use the sqlite metadata |
4 |
cache backend as per an old HOWTO [0], however, I thought that it would be a |
5 |
good idea to revisit that decision. |
6 |
|
7 |
Now apparently, this was supposed to speed up portage, although even that |
8 |
depends. For instance, [0] says that the metadata_overlay backend is faster on |
9 |
fast storage; since all of portage is on an SSD, that ought to be the case for |
10 |
me. However, [0] is pretty outdated, so I don't really know, and don't have any |
11 |
comparison. |
12 |
|
13 |
In addition to that, I don't explicitly make use of the sqlite metadata cache, |
14 |
that is, I don't (consciously) use any software that accesses those DBs, except |
15 |
for eix (except for overlays, where one would need to run "emerge --regen" |
16 |
first, which is *ssssslllllloooowwwww*), which can make use of them if |
17 |
CACHE_METHOD is set appropriately; this speeds up eix-update considerably. |
18 |
|
19 |
Does anybody here have experience with this, or a recommendation? I tried |
20 |
switching to the default cache method temporarily to see how things perform, |
21 |
and "emerge @world -uDNva" slowed down by about 30 seconds, so preliminary |
22 |
results point to sticking with sqlite (although it could at least partly be a |
23 |
btrfs performance regression in Linux 3.15, since there have been several reports of |
24 |
those, and several fixes slated for 3.16). Anyway, I'm also unsure of unintended |
25 |
consequences, or other settings I might have to change, too. |
26 |
|
27 |
Also, does anybody have any performance data and/or experience on using btrfs |
28 |
with compression in this context? |
29 |
|
30 |
[0] http://www.gentoo-wiki.info/TIP_speed_up_portage_with_sqlite |
31 |
|
32 |
Greetings, |
33 |
-- |
34 |
Marc Joliet |
35 |
-- |
36 |
"People who think they know everything really annoy those of us who know we |
37 |
don't" - Bjarne Stroustrup |