From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: guix gc: smarter collection & guix.el manual deletion Date: Sun, 29 Jul 2018 05:06:34 -0700 Message-ID: <87k1pekzzp.fsf@gmail.com> References: <876012bfnf.fsf@gmail.com> <87h8klrono.fsf@gmail.com> <874lgkea7x.fsf@gmail.com> <87va8zr7eb.fsf@gmail.com> <87effnejrg.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:49111) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fjkTE-0000TU-9a for guix-devel@gnu.org; Sun, 29 Jul 2018 08:06:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fjkTD-0003J2-5p for guix-devel@gnu.org; Sun, 29 Jul 2018 08:06:44 -0400 Received: from mail-pf1-x42d.google.com ([2607:f8b0:4864:20::42d]:40454) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fjkTC-0003IY-Uy for guix-devel@gnu.org; Sun, 29 Jul 2018 08:06:43 -0400 Received: by mail-pf1-x42d.google.com with SMTP id e13-v6so3319462pff.7 for ; Sun, 29 Jul 2018 05:06:42 -0700 (PDT) List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pierre Neidhardt Cc: Guix-devel --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Pierre Neidhardt writes: >> Perhaps you simply don't have enough garbage available for the collector >> to collect? If you ask for 5 GiB, your system has 3 GiB free, and there >> is only 1 GiB of garbage, the best the collector can do is collect all >> the garbage (1 GiB) and leave you with just 4 GiB of free space. > > Sorry for the sparse details, I forgot to mention that if I run `guix gc = -F8GB`, > then I get 5-6GB back, so it _can_ remove that much garbage indeed! ;) The "guix gc" command appears to be working correctly for me: =2D-8<---------------cut here---------------start------------->8--- [0] marusich@garuda.local:~ $ df -h /gnu/store Filesystem Size Used Avail Use% Mounted on /dev/mapper/encrypted-root 211G 194G 5.8G 98% /gnu/store [0] marusich@garuda.local:~ $ guix gc -F8G guix gc: freeing 2,336.80469 MiBs finding garbage collector roots... deleting garbage... [...] deleted or invalidated more than 2450317312 bytes; stopping [...] [0] marusich@garuda.local:~ $ df -h /gnu/store Filesystem Size Used Avail Use% Mounted on /dev/mapper/encrypted-root 211G 187G 13G 94% /gnu/store =2D-8<---------------cut here---------------end--------------->8--- Above, I began with 5.8 GiB of free space in the store's file system. I asked Guix to increase that value to 8 GiB. Guix correctly determined that it would need to free approximately 8 - 5.8 =3D 2.2 GiB or more to fulfill my request. It then started collecting garbage and stopped once it found that it had freed slightly more space than required. I ended with 13 GiB of free space. Since I asked Guix to collect enough garbage to end up with at least 8 GiB of free space, Guix behaved correctly. Before you run "guix gc" next time, first see how much garbage you have: =2D-8<---------------cut here---------------start------------->8--- [0] marusich@garuda.local:~ $ guix gc --list-dead | tr '\n' '\0' | du -hsc --files0-from - | tail -n 1 finding garbage collector roots... determining live/dead paths... 70G total =2D-8<---------------cut here---------------end--------------->8--- Above, dead paths take up 70 GiB of space in my store. However, even if Guix collects all of those dead paths, it might not actually free up 70 GiB of space. This is because of deduplication. If a dead path and a live path have been deduplicated, it means they had the same content and Guix saved space by converting them to hard links pointing to the same inode. In that case, the amount of space Guix can free is strictly less than 70 GiB, since Guix has to keep the deduplicated storage around for the sake of the live path. In any case, if the current free space plus the space taken up by the dead paths is less than the amount of free space you requested via the =2DF option, then Guix will collect all the garbage, but you'll definitely end up with less free space than you asked for. Hopefully this will help to explain the behavior you're seeing. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAltdrcsACgkQ3UCaFdgi Rp0jPBAAmVrPr55bjfMWGEuEWttSvI9eHVeuEOI7B8d5QZ3vkt0UVriT/kYgbKLk MFwM3K3JLZOPWk6D18HM+Y74txDClmmGr6Kg5hIKYoDeudBolgngEDJG7GE7Fpv4 hDTvcBGqCvwviCFqGuMx8luxKRR9mEYi2krAUwiMWD5iF7fKdihfDQWGq1JZsxO9 ztLenB/CoJ9ecsuJW7zFk1xsRt4Ypldk+MO4GX5XbEToTXbK8SgSzRw1r8LIBKsK rnOIkRDW6jfHYgh9jWF/y3PGrTvWccLv+XEA/bI5p/DUc0Dj5+n7bPrQ5D+3Fkuo piro2URxKEg+4EV0SYrmJw7K6MSCKE8vipjy+0wbPzgLd4f9L+TxnIPpU/r/aneH 2zKGyAxc6J0XuCMvtk+LODJVCVv0j2oqYGknOLm1blGOwBJbUvkFup4BQQmE6hML JZcytd01Xr4qvHyzgywl+FsvIoqWFO8XQSBv4XexTpXHXsssMDaN/9lxLLDS6nyW gARIOJaOPAi8WVvDQTJGsznWQujYfUyYKLGosvt5IFfDzJA93mY+UPGdKKXc6WPG +AzHMQLaJ1eBKHz823wFJXf8AmoqrlXlNf2ro6j2rLeBSBKBPhbLxZ3Hjyxo7hDm j8ReTySV3T86mG8hg5TXSC/+49SN8ndnEbSuYtAwjnCwdLZ3xbc= =7CoA -----END PGP SIGNATURE----- --=-=-=--