From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 08 23:11:34 2021 Received: (at 51427) by debbugs.gnu.org; 9 Nov 2021 04:11:34 +0000 Received: from localhost ([127.0.0.1]:60238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkITu-0004ph-5R for submit@debbugs.gnu.org; Mon, 08 Nov 2021 23:11:34 -0500 Received: from mail-qk1-f182.google.com ([209.85.222.182]:45010) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mkITs-0004pO-M0 for 51427@debbugs.gnu.org; Mon, 08 Nov 2021 23:11:33 -0500 Received: by mail-qk1-f182.google.com with SMTP id bj27so16003306qkb.11 for <51427@debbugs.gnu.org>; Mon, 08 Nov 2021 20:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=kLECGrFl2ZF+KKyKoR9Z1g+7lY0MK3HG1Htt0LGjF44=; b=jJjWWla3QSN0VxxI2EmfXpc+Sdlk3spcDX6WRhoBWsyDp+KF0e+daCgfFKc96QUmMy 1GURApm32tSrdLy6Y1UpLeEjBFc8ZO0mG5udqfNgW1IpDDs8plAy/8udffulU35K8fGm bVhxBqsw7CClyCUK7bdtS20/kzTN0ryqlpUSbYdxn0zz1vV7SUCM0/1gSmTpblVLUQWz Ok6KN80wIM4iqyk+522yUAfm7XaGB68WkAHsTdfi2Pylohus4wFfspEaYO61N/HJ4PdE hEw4RfoYA4rbNHctD0V0uul4LUZ0qBXPhkvdsUQpI/GGgLuaSAWMgLKpgwv9G6+xNHko YmAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=kLECGrFl2ZF+KKyKoR9Z1g+7lY0MK3HG1Htt0LGjF44=; b=LUVbZhB6e3boLZg+3ayWNf5fiXw45gYCyjN2hMpwXPpFinDX1tb3NoN5nDuHH5+VG+ ds3AWhCFyIw9g1Oj26hMefeO02fwwH+BRuCIXMO9HO+2ejEtzyhtHsP1n/KR8l4qV/xy jGYwSPPHzgMjzbmaQ6IZgy1qPTzZI19ZXkal1BSOSC7w2IyQ1FdhtibcvkKMONQsWnJF /nCeqNxxAsIZjZUwy3OyqXcfH24w9Pl+UxzvDtD5IhWPGAjdvMw1MTPLmHjc+OCPEK6l lf5w+QFdwyPkYW/xJPdhgER7zXDyOU0Q1EJt8gNDzy94aGIEY5l4cJhneY+vbitG3502 Npzw== X-Gm-Message-State: AOAM531DcA1Dh0vFESEaHmIqc+2hcqL71vIxkZQg7wBUwTN1KiVReQGH 3EqsZA2GGK4svTsWn8FgJa4f5YdseAU6Bg== X-Google-Smtp-Source: ABdhPJxt6hJIZhrPAeuCxsi2vOtr0t0WV3ZUO4ZdmtozGrzRPf/lzx+vABCcs4j8sDoROTEgfE/ykA== X-Received: by 2002:a37:b4b:: with SMTP id 72mr3473478qkl.79.1636431086096; Mon, 08 Nov 2021 20:11:26 -0800 (PST) Received: from hurd (dsl-236-125-16.b2b2c.ca. [207.236.125.16]) by smtp.gmail.com with ESMTPSA id h16sm897497qtx.20.2021.11.08.20.11.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Nov 2021 20:11:25 -0800 (PST) From: Maxim Cournoyer To: Ludovic =?utf-8?Q?Court=C3=A8s?= Subject: Re: bug#51427: [PATCH] nix: libstore: Do not remove unused links when deleting specific items. References: <20211027034918.4591-1-maxim.cournoyer@gmail.com> <87o8795j61.fsf@gnu.org> <5c2dd60acfaa7d74b7554babb3e223bc855bac8a.camel@gmail.com> <87h7cxp9tl.fsf@gnu.org> <87sfwg7w9z.fsf@gmail.com> <87ee7tmdbd.fsf@gnu.org> Date: Mon, 08 Nov 2021 23:11:22 -0500 In-Reply-To: <87ee7tmdbd.fsf@gnu.org> ("Ludovic =?utf-8?Q?Court=C3=A8s=22'?= =?utf-8?Q?s?= message of "Sat, 06 Nov 2021 17:57:58 +0100") Message-ID: <87k0hi0xzp.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 51427 Cc: 51427@debbugs.gnu.org, Liliana Marie Prikler X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hi, Ludovic Court=C3=A8s writes: > Hi Maxim and all, > > Maxim Cournoyer skribis: > >> Ludovic Court=C3=A8s writes: > > [...] > >>> You seem to be proposing to remove =E2=80=98-D=E2=80=99 altogether. I = agree it has the >>> shortcomings you write, but I think it=E2=80=99s occasionally useful >>> nonetheless. >>> >>> My proposal would be either the status quo, or removing just the one >>> link that matters from /gnu/store/.links upon =E2=80=98-D=E2=80=99. >> >> The second proposal makes sense. > > Maybe that proposal is bogus though because you=E2=80=99d need to know th= e hash > of the files being removed, which means reading them=E2=80=A6 Oops :-). >> I didn't care about freeing space, as my use case was getting around >> corrupting an item in my store due to >> https://issues.guix.gnu.org/51400, which the patch proposed here >> allowed me to do without wasting hours of cleaning up links (nearly 1 >> GiB of store on spinning drives). > > The ideal solution as zimoun writes would be to address > . Seems there's some improvement ready, but which needs more testing/measurements? I'd suggest simply invoking GNU sort; if it has many pages of program for doing what it does, it's probably doing something fancier/faster than we can (are ready to) emulate -- for free! > Perhaps that phase needs to be implemented using a different strategy, > say an sqlite database that records the current link count (hoping that > =E2=80=98SELECT * FROM links WHERE NLINKS =3D 1=E2=80=99 would be faster = than traversing > all of =E2=80=98.links=E2=80=99) as well as a mapping from store item to = file hashes. Hmm. I'll need to dive in the problem a bit more before I can comment on this. > BTW, those using Btrfs can probably use =E2=80=98--disable-deduplication= =E2=80=99 and be > done with it. I erroneously used to think that Btrfs could do live deduplication, but it doesn't. There are external tools to do out of band / batch deduplication though [0]; so if they perform better than the guix daemon's own dedup, perhaps we could document this way out for our Btrfs users. [0] https://btrfs.wiki.kernel.org/index.php/Deduplication Thank you, Maxim