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