From mboxrd@z Thu Jan  1 00:00:00 1970
From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=)
Subject: Re: /gnu/store/.links/
Date: Fri, 09 Feb 2018 18:00:02 +0100
Message-ID: <87372ayu7h.fsf@gnu.org>
References: <20180209112214.GA5316@thebird.nl> <87d11e747o.fsf@elephly.net>
	<20180209142400.GA6348@thebird.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42237)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1ekC1w-0005Xm-Ug
	for guix-devel@gnu.org; Fri, 09 Feb 2018 12:00:12 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ludo@gnu.org>) id 1ekC1t-0002au-SH
	for guix-devel@gnu.org; Fri, 09 Feb 2018 12:00:09 -0500
Received: from hera.aquilenet.fr ([2a0c:e300::1]:57312)
	by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.71) (envelope-from <ludo@gnu.org>) id 1ekC1t-0002YO-Kr
	for guix-devel@gnu.org; Fri, 09 Feb 2018 12:00:05 -0500
In-Reply-To: <20180209142400.GA6348@thebird.nl> (Pjotr Prins's message of
	"Fri, 9 Feb 2018 15:24:00 +0100")
List-Id: "Development of GNU Guix and the GNU System distribution."
	<guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/guix-devel/>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
Sender: "Guix-devel" <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
To: Pjotr Prins <pjotr.public12@thebird.nl>
Cc: Guix-devel <guix-devel@gnu.org>

Pjotr Prins <pjotr.public12@thebird.nl> skribis:

> On Fri, Feb 09, 2018 at 01:11:23PM +0100, Ricardo Wurmus wrote:

[...]

>> I don=E2=80=99t know about scalability.  This number is still well below=
 the
>> limits of ext4 file systems, but accessing a big directory listing like
>> that can be slow.  I would feel a little better about this if we split
>> it up into different prefix directories (like it=E2=80=99s done for brow=
ser
>> caches).  I don=E2=80=99t think it=E2=80=99s necessary, though.
>
> For ext4 it is going to be an issue. Anyway, we'll see what happens.

In practice, when the maximum number of links is reached, we simply
transparently skip deduplication.  See this commit:

  commit 12b6c951cf5ca6055a22a2eec85665353f5510e5
  Author: Ludovic Court=C3=A8s <ludo@gnu.org>
  Date:   Fri Oct 28 20:34:15 2016 +0200

      daemon: Do not error out when deduplication fails due to ENOSPC.

      This solves a problem whereby if /gnu/store/.links had enough entries,
      ext4's directory index would be full, leading to link(2) returning
      ENOSPC.

      * nix/libstore/optimise-store.cc (LocalStore::optimisePath_): Upon
      ENOSPC from link(2), print a message and return instead of throwing a
      'SysError'.

It does scale well, and it=E2=80=99s been here =E2=80=9Cforever=E2=80=9D.

If you=E2=80=99re wondering how much gets deduplicated, see
<https://lists.gnu.org/archive/html/guix-devel/2014-09/msg00422.html>.
:-)

Ludo=E2=80=99.