From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Marusich Subject: Re: Guix to participate in the Google Summer of Code Date: Wed, 21 Feb 2018 07:23:22 +0100 Message-ID: <87sh9u3lph.fsf@gmail.com> References: <87h8qjp20e.fsf@gnu.org> <871shircab.fsf@gmail.com> <874lmey4ki.fsf@elephly.net> 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]:44151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eoNoS-0006iD-Ux for guix-devel@gnu.org; Wed, 21 Feb 2018 01:23:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eoNoQ-0001Ma-B4 for guix-devel@gnu.org; Wed, 21 Feb 2018 01:23:32 -0500 Received: from mail-it0-x22f.google.com ([2607:f8b0:4001:c0b::22f]:52424) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eoNoQ-0001MI-4I for guix-devel@gnu.org; Wed, 21 Feb 2018 01:23:30 -0500 Received: by mail-it0-x22f.google.com with SMTP id o13so1005601ito.2 for ; Tue, 20 Feb 2018 22:23:29 -0800 (PST) In-Reply-To: <874lmey4ki.fsf@elephly.net> (Ricardo Wurmus's message of "Sun, 18 Feb 2018 11:28:45 +0100") 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: Ricardo Wurmus Cc: Guix-devel --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ricardo Wurmus writes: > Garbage collection in the context of Guix is not very difficult to > understand. The garbage collector may remove any item that has zero > users; the link count on a store item is indicative of the number of > users that item has. For garbage collection you essentially go through > all items and check if the link count is zero. Is this correct? My understanding is that the link count of a store path (i.e., the count of hard links for a given file in the store) is unrelated to whether or not that store path is live. It looks like, in nix/libstore/gc.cc, we basically walk the references graph starting from the GC roots and delete anything that can't be reached from a root. This makes sense, since anything that can be reached from a root is live and must not be deleted, and anything that can't be reached from any root can be deleted. Link counts (e.g., the number of hard links) do not seem to play a role here. In addition to the C++ code, the Nix thesis has a good discussion of the garbage collection algorithm. I don't know if it's accurate, but it helps shed light on the intent. =2D-=20 Chris --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAlqNEFoACgkQ3UCaFdgi Rp0VCQ/7BwvoMMcB3/Opf8lEPt90NKRAsy6nmnHVwJW7BVsbdivvh93m9/loxviq 1ikXJWUXTAcB6HC7H3l+/mRu+JitGyQEGPBdRcGEHMe2WQl82pycF25fUxhp2vwu Zj61LERCbYYNRvCSrSCI+g37qPAZ/hAs/pw681zDsewjpeCsRfJwsSwbla9InmCx G4YkZ64djpA/uv9aeCgq60hsPpOoS3c2hOYETom1L7Vjl4IRIAXc8pAERk91LsHR dM/UYxj3d5qqPDt13wQE1y+KBbuPM7CpqLhtoxoizwRUA3tIzSXCgj2MLVG+grL2 XKqlmkogw74kEp79VZg2jp3BdO/I9VIhmoEYBlKgcqbAVnu6qutoWmCuNQV56nlt JxHpSEVk7kNgzRnU3d2+c6mev0SbC+NK0h5YIoH7FFawBZ2tiQKaokcHt/IIPEqf tx4zKRcMtqIxfaeMxsrZaPNq4CWmEYj+dv7wUzTs6fOrpTekL7elQRWAHrNywiLo iEBtfdEQJDBPB2iWO07dHB7Zn8io+GwB1pz3a0Y9Pqc31IvpbDsZL8i5Cpi+I3s5 0SZ0WQReo0PERLRjs83O34ybmxpQaWmoPH/tgQL2dknfYco1Bi8m8w6V2pUjuYP0 KLjvCOTUDn2jYr4JYv0wRcuFiNlIo7HwecfmWsFjJwBHhfEe+bY= =5+OE -----END PGP SIGNATURE----- --=-=-=--