unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 51427@debbugs.gnu.org, Liliana Marie Prikler <liliana.prikler@gmail.com>
Subject: [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items.
Date: Mon, 08 Nov 2021 23:11:22 -0500	[thread overview]
Message-ID: <87k0hi0xzp.fsf@gmail.com> (raw)
In-Reply-To: <87ee7tmdbd.fsf@gnu.org> ("Ludovic Courtès"'s message of "Sat, 06 Nov 2021 17:57:58 +0100")

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Maxim and all,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>> You seem to be proposing to remove ‘-D’ altogether.  I agree it has the
>>> shortcomings you write, but I think it’s occasionally useful
>>> nonetheless.
>>>
>>> My proposal would be either the status quo, or removing just the one
>>> link that matters from /gnu/store/.links upon ‘-D’.
>>
>> The second proposal makes sense.
>
> Maybe that proposal is bogus though because you’d need to know the hash
> of the files being removed, which means reading them…

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
> <https://issues.guix.gnu.org/24937>.

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
> ‘SELECT * FROM links WHERE NLINKS = 1’ would be faster than traversing
> all of ‘.links’) 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 ‘--disable-deduplication’ 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




  reply	other threads:[~2021-11-09  4:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27  3:49 [bug#51427] [PATCH] nix: libstore: Do not remove unused links when deleting specific items Maxim Cournoyer
2021-10-28 14:16 ` Ludovic Courtès
2021-10-31  8:50   ` Liliana Marie Prikler
2021-10-31 14:07     ` Ludovic Courtès
2021-10-31 14:39       ` Liliana Marie Prikler
2021-10-31 20:51       ` Maxim Cournoyer
2021-11-03 10:45         ` zimoun
2021-11-06 16:57         ` Ludovic Courtès
2021-11-09  4:11           ` Maxim Cournoyer [this message]
2021-11-09  4:57             ` Jack Hill
2021-11-09 12:56               ` Ludovic Courtès
2021-11-09 18:10           ` zimoun
2021-11-17 10:02             ` Ludovic Courtès
2021-11-17 11:49               ` zimoun
2022-07-18 13:57                 ` Ludovic Courtès
2022-07-18 17:03                   ` Liliana Marie Prikler
2022-07-19  8:34                     ` Ludovic Courtès
2022-07-19 18:42                       ` Liliana Marie Prikler
2022-07-19 19:25                         ` Tobias Geerinckx-Rice via Guix-patches via
2022-07-21  9:21                           ` Ludovic Courtès
2022-07-21 18:02                             ` Liliana Marie Prikler
2022-07-22 12:14                               ` Ludovic Courtès
2022-07-22 13:39                                 ` Maxime Devos
2022-07-22 23:07                                   ` Ludovic Courtès
2022-07-23  6:52                                     ` Liliana Marie Prikler
2022-07-23 10:24                                     ` Maxime Devos
2023-06-12 20:55 ` Felix Lechner via Guix-patches via
2023-06-13  4:26   ` Liliana Marie Prikler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k0hi0xzp.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=51427@debbugs.gnu.org \
    --cc=liliana.prikler@gmail.com \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).