From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 29DEA13877A for ; Tue, 12 Aug 2014 18:10:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F2395E0CE9; Tue, 12 Aug 2014 18:10:34 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A6146E0C4E for ; Tue, 12 Aug 2014 18:10:33 +0000 (UTC) Received: from marcec ([77.22.138.176]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lw1vh-1WLKK50i9V-017paq for ; Tue, 12 Aug 2014 20:10:32 +0200 Date: Tue, 12 Aug 2014 20:10:25 +0200 From: Marc Joliet To: gentoo-user@lists.gentoo.org Subject: [gentoo-user] Portage metadata cache backend: sqlite or not? Message-ID: <20140812201025.51c97196@marcec> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.24; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/0PW4.385+OwBlPtgHw4tpM1"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:21gS0lZFa1k6pbQo9qWTM2ZPfurUIMYnPSBPaPmyzRh6St3cH6x 6px4X0Hh29Dj8pfmV3+QrSaKmsjjHtJO7BXn06cYZa+TAZzahvL3ulLMg3qCWo/6+Sslu/X ouURAQEAjh8UWou8npZZHted79LnlJe2exkROm/rE8eSZTF8dAQcZRUKotvaqm0AQT3O1Hn E+Fz4cTEKmfpAvYbos3yg== X-UI-Out-Filterresults: notjunk:1; X-Archives-Salt: 02c6baf3-1507-4fe2-a086-361fa38714cc X-Archives-Hash: d9b7582c7c4024a81035b307c9a14a41 --Sig_/0PW4.385+OwBlPtgHw4tpM1 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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 faste= r 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 cac= he, that is, I don't (consciously) use any software that accesses those DBs, ex= cept 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 r= eports of those, and several fixes slated for 3.16). Anyway, I'm also unsure of unint= ended consequences, or other settings I might have to change, too. Also, does anybody have any performance data and/or experience on using btr= fs with compression in this context? [0] http://www.gentoo-wiki.info/TIP_speed_up_portage_with_sqlite Greetings, --=20 Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup --Sig_/0PW4.385+OwBlPtgHw4tpM1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT6liWAAoJEL/Q5oYsiHj0J5EQAKxI/7GYYcO+CQZ35mVGaFjM bzwIY+PnEzjBfNbYPzcVXzt04YnO2XqJbhb1LxaIUTz1JtXmYXHsdSottey33HiC +aylp1Cp6IE0v7Vtlt/L2xKy6yhhXPcPxa4D9tlcxH5AJKvk3C6bg6NdfJcTUal6 X+cWq0oIRuSKU0vIGd6iBHPV5Ku0pWPHUvI1ye2GzPrr7tHUYJS0Q0wwgtwyAboH CZEOQDNYMETtB6d8bpbzcmcHbq3orQAoT91wRhMcI0HhofgpkgK6O2pUZx9Pb6kK gcAL9/0MReVJHm9itf36nJGDxlh0IE+ArrNqKV1d30taIDZFWhhqUKnPfiiMrYH7 5Pm5ZKr2kr88Ml0tOUfYlXp64eSilSoWzl5XZL/N74cljq0S7TbfgBSeNYzIx0A1 RsxlFyd9ohFksJFPPcAGk9Ai0RuKmSATelACT+4SIp21aObLQPgtDrgrMs3Xtbxg 5aWYrtDOYG6PsKpyrz24ecSDdwy6ZXLx7cRL5uPY09+DMbQuO5YvWCK+9PXi3EYQ QRD5IkzPia8COq71DVV7PawPIkNvSn7aFUs1SLmKr2g2D6o73zQY4FquPr0P7usE gHQp1nrIcM+ZF4IZmOgpq3LoGu+1nabkOGsJw9GfPa8PsXAhM81uN5XjBBfEXdQv UnO0+ApgdYnAOt0QNCze =/sPt -----END PGP SIGNATURE----- --Sig_/0PW4.385+OwBlPtgHw4tpM1--