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
next prev parent 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).