guix gc: smarter collection & guix.el manual deletion

guix gc: smarter collection & guix.el manual deletion

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1643 bytes --]

Hi!

I run GuixSD on a rather small partition (<25GB) and quite often the
partition gets full during a transation and I end up having to clean up
the store (e.g. "guix gc -F5G").

The problem is that more often than not, "guix gc" will remove store
items that are almost always needed for the next transaction, which
results in a huge re-update of those newly missing packages.  What a
waste of time...

It would be nice if "guix gc" would be a bit smarter and remove items
that are less likely to be needed for the next transaction.

Or maybe I'm missing the point?

The store does not have timestamps, so removing old items would not work
I guess.  But what about removing older versions first?  Say I have
glibc-2.24 and glibc-2.25, only remove glibc-2.24 if that's enough to
free the required space.

Maybe we could introduce a "whitelist" of packages to delete last.

In the end I figured that the most convenient way to clean up the store
might be to do it manually with "guix gc --delete PATH".  Well, not so
from the commandline, but with guix.el I thought we could do something
nice.  So I gave it a (quick&dirty™) shot:

	https://gitlab.com/emacs-guix/emacs-guix/issues/2

With guix.el loaded, `eval' my example and run "M-x guix-store".
This will return a list of all the dead links, which you can sort by
name or by size.  You can then mark items ("m") and delete them ("k").

What do you people think?


While I'm at it, I'd like to note that something might be wrong with the
`-F` option: I never get the promised amount of free space back, only
about 2/3 of it.

--
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: guix gc: smarter collection & guix.el manual deletion

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> I run GuixSD on a rather small partition (<25GB) and quite often the
> partition gets full during a transation and I end up having to clean up
> the store (e.g. "guix gc -F5G").
>
> The problem is that more often than not, "guix gc" will remove store
> items that are almost always needed for the next transaction, which
> results in a huge re-update of those newly missing packages.  What a
> waste of time...
>
> It would be nice if "guix gc" would be a bit smarter and remove items
> that are less likely to be needed for the next transaction.

You might be interested in the following guix-daemon options:

      --gc-keep-derivations[=yes/no]
                             tell whether the GC must keep derivations
                             corresponding to live outputs
      --gc-keep-outputs[=yes/no]   tell whether the GC must keep outputs of
                             live derivations

Perhaps by setting them to "yes", you can avoid collecting store items
that you'd rather keep around.  I think these default to "no".

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: guix gc: smarter collection & guix.el manual deletion

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

Thanks for mentioning this.  I'm very confused by the documentation however:

--8<---------------cut here---------------start------------->8---
‘--gc-keep-outputs[=yes|no]’
     Tell whether the garbage collector (GC) must keep outputs of live
     derivations.

     When set to “yes”, the GC will keep the outputs of any live
     derivation available in the store—the ‘.drv’ files.  The default is
     “no”, meaning that derivation outputs are kept only if they are GC
     roots.  *Note Invoking guix gc::, for more on GC roots.
--8<---------------cut here---------------end--------------->8---

Specifically this: "derivation outputs are kept only if they are GC roots'".
Would that mean that other live outputs are deleted?!?  I must get this wrong! :p

That said, I think my `guix-store.el' suggestion still has the following benefit: 
whenever there is a huge build-input in the store for an item that is only
seldom rebuilt, it allows the users to chose for themselves if it's OK to delete
it.

-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: guix gc: smarter collection & guix.el manual deletion

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 3074 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> Thanks for mentioning this.  I'm very confused by the documentation however:
>
> ‘--gc-keep-outputs[=yes|no]’
>      Tell whether the garbage collector (GC) must keep outputs of live
>      derivations.
>
>      When set to “yes”, the GC will keep the outputs of any live
>      derivation available in the store—the ‘.drv’ files.  The default is
>      “no”, meaning that derivation outputs are kept only if they are GC
>      roots.  *Note Invoking guix gc::, for more on GC roots.
>
> Specifically this: "derivation outputs are kept only if they are GC roots'".
> Would that mean that other live outputs are deleted?!?  I must get this wrong! :p
>
> That said, I think my `guix-store.el' suggestion still has the following benefit: 
> whenever there is a huge build-input in the store for an item that is only
> seldom rebuilt, it allows the users to chose for themselves if it's OK to delete
> it.

By the way, I think you're right about the manual.  I think it should
say: "The default is 'no', meaning that derivation outputs are kept only
if they are _reachable from_ a GC root."

I've fixed this and added a little more information to the manual in
commit 346a632144b89f45b3966732edacc2bfa07126a7.

> Fantastic review!
> Thank you so much for this: very clear, very thorough, it scattered all
> remaining confusions!  I thumb up for a blog post! :D

I'm glad it helped!  But I must confess, I'm cheating: This is all
described in Eelco Dolstra's thesis [1].  It's a good read if you want
to learn more about how the daemon and the store are designed.

> I find emacs-guix tremendously useful, I highly recommend you give it a try (the
> learning curve is very flat).  Any reason why you'd rather not use it?

I just haven't gotten around to it yet.  I'll try it sooner or later!

>> > While I'm at it, I'd like to note that something might be wrong with the
>> > `-F` option: I never get the promised amount of free space back, only
>> > about 2/3 of it.
>>
>> I think that's normal.  My understanding is that if you say "guix gc -F
>> 3GiB", you aren't asking Guix to free 3 GiB; you're asking Guix to try
>> to free enough space so that when it's done, the store will have 3 GiB
>> of free space.  For example, if the store begins with 2 GiB of free
>> space and there is 5 GiB of garbage, Guix will only collect 1 GiB in
>> order to bring the free space up to 3 GiB.
>
> No, I'm talking total disk usage here.  If I ask 5G back, then `df /` tells me
> that root has about 3-4G free, it never has the promised amount.  Can someone
> confirm this?  Might be a bug.

Perhaps you simply don't have enough garbage available for the collector
to collect?  If you ask for 5 GiB, your system has 3 GiB free, and there
is only 1 GiB of garbage, the best the collector can do is collect all
the garbage (1 GiB) and leave you with just 4 GiB of free space.

Footnotes: 
[1]  Page 128: https://nixos.org/~eelco/pubs/phd-thesis.pdf

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: guix gc: smarter collection & guix.el manual deletion

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

> Perhaps you simply don't have enough garbage available for the collector
> to collect?  If you ask for 5 GiB, your system has 3 GiB free, and there
> is only 1 GiB of garbage, the best the collector can do is collect all
> the garbage (1 GiB) and leave you with just 4 GiB of free space.

Sorry for the sparse details, I forgot to mention that if I run `guix gc -F8GB`,
then I get 5-6GB back, so it _can_ remove that much garbage indeed! ;)
-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: guix gc: smarter collection & guix.el manual deletion

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 3063 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

>> Perhaps you simply don't have enough garbage available for the collector
>> to collect?  If you ask for 5 GiB, your system has 3 GiB free, and there
>> is only 1 GiB of garbage, the best the collector can do is collect all
>> the garbage (1 GiB) and leave you with just 4 GiB of free space.
>
> Sorry for the sparse details, I forgot to mention that if I run `guix gc -F8GB`,
> then I get 5-6GB back, so it _can_ remove that much garbage indeed! ;)

The "guix gc" command appears to be working correctly for me:

--8<---------------cut here---------------start------------->8---
[0] marusich@garuda.local:~
$ df -h /gnu/store
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/encrypted-root  211G  194G  5.8G  98% /gnu/store
[0] marusich@garuda.local:~
$ guix gc -F8G
guix gc: freeing 2,336.80469 MiBs
finding garbage collector roots...
deleting garbage...
[...]
deleted or invalidated more than 2450317312 bytes; stopping
[...]
[0] marusich@garuda.local:~
$ df -h /gnu/store
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/encrypted-root  211G  187G   13G  94% /gnu/store
--8<---------------cut here---------------end--------------->8---

Above, I began with 5.8 GiB of free space in the store's file system.  I
asked Guix to increase that value to 8 GiB.  Guix correctly determined
that it would need to free approximately 8 - 5.8 = 2.2 GiB or more to
fulfill my request.  It then started collecting garbage and stopped once
it found that it had freed slightly more space than required.  I ended
with 13 GiB of free space.  Since I asked Guix to collect enough garbage
to end up with at least 8 GiB of free space, Guix behaved correctly.

Before you run "guix gc" next time, first see how much garbage you have:

--8<---------------cut here---------------start------------->8---
[0] marusich@garuda.local:~
$ guix gc --list-dead | tr '\n' '\0' | du -hsc --files0-from - | tail -n 1
finding garbage collector roots...
determining live/dead paths...
70G	total
--8<---------------cut here---------------end--------------->8---

Above, dead paths take up 70 GiB of space in my store.  However, even if
Guix collects all of those dead paths, it might not actually free up 70
GiB of space.  This is because of deduplication.  If a dead path and a
live path have been deduplicated, it means they had the same content and
Guix saved space by converting them to hard links pointing to the same
inode.  In that case, the amount of space Guix can free is strictly less
than 70 GiB, since Guix has to keep the deduplicated storage around for
the sake of the live path.

In any case, if the current free space plus the space taken up by the
dead paths is less than the amount of free space you requested via the
-F option, then Guix will collect all the garbage, but you'll definitely
end up with less free space than you asked for.

Hopefully this will help to explain the behavior you're seeing.

-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: guix gc: smarter collection & guix.el manual deletion

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 219 bytes --]

That could be it.

Also I realize that I never see this message:

> deleted or invalidated more than 2450317312 bytes; stopping

Strange... I'll investigate more next time I run `guix gc`.
-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: guix gc: smarter collection & guix.el manual deletion

[Efraim Flashner]

[-- Attachment #1: Type: text/plain, Size: 3651 bytes --]

On Sun, Jul 29, 2018 at 05:06:34AM -0700, Chris Marusich wrote:
> Pierre Neidhardt <ambrevar@gmail.com> writes:
> 
> >> Perhaps you simply don't have enough garbage available for the collector
> >> to collect?  If you ask for 5 GiB, your system has 3 GiB free, and there
> >> is only 1 GiB of garbage, the best the collector can do is collect all
> >> the garbage (1 GiB) and leave you with just 4 GiB of free space.
> >
> > Sorry for the sparse details, I forgot to mention that if I run `guix gc -F8GB`,
> > then I get 5-6GB back, so it _can_ remove that much garbage indeed! ;)
> 
> The "guix gc" command appears to be working correctly for me:
> 
> --8<---------------cut here---------------start------------->8---
> [0] marusich@garuda.local:~
> $ df -h /gnu/store
> Filesystem                  Size  Used Avail Use% Mounted on
> /dev/mapper/encrypted-root  211G  194G  5.8G  98% /gnu/store
> [0] marusich@garuda.local:~
> $ guix gc -F8G
> guix gc: freeing 2,336.80469 MiBs
> finding garbage collector roots...
> deleting garbage...
> [...]
> deleted or invalidated more than 2450317312 bytes; stopping
> [...]
> [0] marusich@garuda.local:~
> $ df -h /gnu/store
> Filesystem                  Size  Used Avail Use% Mounted on
> /dev/mapper/encrypted-root  211G  187G   13G  94% /gnu/store
> --8<---------------cut here---------------end--------------->8---
> 
> Above, I began with 5.8 GiB of free space in the store's file system.  I
> asked Guix to increase that value to 8 GiB.  Guix correctly determined
> that it would need to free approximately 8 - 5.8 = 2.2 GiB or more to
> fulfill my request.  It then started collecting garbage and stopped once
> it found that it had freed slightly more space than required.  I ended
> with 13 GiB of free space.  Since I asked Guix to collect enough garbage
> to end up with at least 8 GiB of free space, Guix behaved correctly.
> 
<...snip...>
> 
> Hopefully this will help to explain the behavior you're seeing.
> 

$ guix gc --help
Usage: guix gc [OPTION]... PATHS...
Invoke the garbage collector.

  -C, --collect-garbage[=MIN]
                         collect at least MIN bytes of garbage
  -F, --free-space=FREE  attempt to reach FREE available space in the store
  -d, --delete           attempt to delete PATHS
      --optimize         optimize the store by deduplicating identical files
      --list-dead        list dead paths
      --list-live        list live paths

      --references       list the references of PATHS
  -R, --requisites       list the requisites of PATHS
      --referrers        list the referrers of PATHS
      --derivers         list the derivers of PATHS

      --verify[=OPTS]    verify the integrity of the store; OPTS is a
                         comma-separated combination of 'repair' and
                         'contents'
      --list-failures    list cached build failures
      --clear-failures   remove PATHS from the set of cached failures

  -h, --help             display this help and exit
  -V, --version          display version information and exit

Report bugs to: bug-guix@gnu.org.
GNU Guix home page: <https://www.gnu.org/software/guix/>
General help using GNU software: <http://www.gnu.org/gethelp/>

`guix gc -F 8GB' should try to free space until there is 8GB of free
space, you're thinking of `guix gc -C 8 GB' which tries to free 8GB of
space.


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: guix gc: smarter collection & guix.el manual deletion

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 112 bytes --]

No, I really meant "-F5G" to have 5G+ of free space in total on my root
partition.


-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: guix gc: smarter collection & guix.el manual deletion

[Ludovic Courtès]

Hi!

Pierre Neidhardt <ambrevar@gmail.com> skribis:

>> Perhaps you simply don't have enough garbage available for the collector
>> to collect?  If you ask for 5 GiB, your system has 3 GiB free, and there
>> is only 1 GiB of garbage, the best the collector can do is collect all
>> the garbage (1 GiB) and leave you with just 4 GiB of free space.
>
> Sorry for the sparse details, I forgot to mention that if I run `guix gc -F8GB`,
> then I get 5-6GB back, so it _can_ remove that much garbage indeed! ;)

Note that in the presence of deduplication, the daemon overestimates how
much it’s going to free.  So usually it ends up freeing a bit less than
what you asked for.

As a workaround you can run “guix gc -F8G” a couple of times or run
“guix gc -F9G”, something like that.  :-)

Ludo’.

Re: guix gc: smarter collection & guix.el manual deletion

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 70 bytes --]

OK, makes sense.
Thanks for the explanation!
-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: guix gc: smarter collection & guix.el manual deletion

[Chris Marusich]

[-- Attachment #1: Type: text/plain, Size: 8910 bytes --]

Pierre Neidhardt <ambrevar@gmail.com> writes:

> Thanks for mentioning this.  I'm very confused by the documentation however:
>
> ‘--gc-keep-outputs[=yes|no]’
>      Tell whether the garbage collector (GC) must keep outputs of live
>      derivations.
>
>      When set to “yes”, the GC will keep the outputs of any live
>      derivation available in the store—the ‘.drv’ files.  The default is
>      “no”, meaning that derivation outputs are kept only if they are GC
>      roots.  *Note Invoking guix gc::, for more on GC roots.
>
> Specifically this: "derivation outputs are kept only if they are GC roots'".
> Would that mean that other live outputs are deleted?!?  I must get this wrong! :p

Live outputs are never eligible for garbage collection.  The behavior of
these options might be a little non-obvious, so I'll explain what I
understand about it, and hopefully it will help.

First, let's assume that you've set both --gc-keep-derivations=no and
--gc-keep-outputs=no.  Let's also suppose that you've installed
hello@2.10 into your profile.  Since your profile is a GC root, this
means that hello@2.10's output (e.g., /gnu/store/...krfy-hello-2.10) is
live.  However, its derivation isn't live, since the derivation is
neither in your profile nor in the output's closure.

To query for the deriver of hello@2.10, you can do this:

--8<---------------cut here---------------start------------->8---
$ guix build -d hello@2.10
/gnu/store/p2hmc4wv59kxvhvxa1dwjjps0g38ikc1-hello-2.10.drv
--8<---------------cut here---------------end--------------->8---

That derivation describes precisely how to build hello@2.10, all the way
down to how to fetch the sources.  That's because it refers to other
dependencies.  Here they are:

--8<---------------cut here---------------start------------->8---
$ guix gc --references $(guix build -d hello@2.10)
/gnu/store/1bjlh3cyij46a3mwi0ikyrn1pb70bd8m-gawk-4.2.1.drv
/gnu/store/1dv1gyyqfn50i2zrq4fvr7fbgwm3hlkx-hello-2.10-guile-builder
/gnu/store/2n4fdhjq47cgifbp2wsmyapqxih73bm4-ld-wrapper-0.drv
[... in total, there are 25 store items like this ...]
--8<---------------cut here---------------end--------------->8---

You can consider these store items to be the "direct dependencies" of
the hello@2.10 derivation.  Many of them are derivations themselves,
which makes sense because you cannot start the hello@2.10 derivation
until after all the things it requires have been built.  Furthermore,
these derivations may in turn refer to other derivations.  Here are the
"direct and transitive dependencies" of the hello@2.10 derivation (which
includes the hello@2.10 derivation itself):

--8<---------------cut here---------------start------------->8---
$ guix gc --requisites $(guix build -d hello@2.10)
/gnu/store/xc0wliwjngcsx26wh65dx07xnas4v146-gcc-4.9.4.tar.xz-builder
/gnu/store/lmfvf4iwkzn4wibvb7ik3cadxq07pjvi-gcc-libvtv-runpath.patch
/gnu/store/d57l8pc992bdqd20l5piqk9k47dqirzm-gcc-4.9-libsanitizer-fix.patch
/gnu/store/5752c05gravrwk2kvy1n2zrgl9j0kxhg-gcc-4.9.4.tar.bz2.drv
[... in total, there are 308 store items like this ...]
--8<---------------cut here---------------end--------------->8---

These 308 store items make up the closure of the hello@2.10 derivation.
Compare this to the closure of hello@2.10's output:

--8<---------------cut here---------------start------------->8---
$ guix gc --requisites $(guix build hello@2.10)
/gnu/store/1r3dlhi2vasb8yw630728jlrk40mygj1-bash-static-4.4.19
/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib
/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27
/gnu/store/bihfrh609gkxb9dp7n96wlpigiv3krfy-hello-2.10
--8<---------------cut here---------------end--------------->8---

The output's closure contains only 4 items!  And if you examine these 4
items, you'll find that none of them appear in the closure of the
hello@2.10 derivation.  Therefore, even though the output of hello@2.10
is live because you've installed it into your profile, none of those 309
store items that were required for building hello@2.10 are live.  They
are all eligible for garbage collection.

However, if you set --gc-keep-derivations=yes, then the hello@2.10
derivation will be treated as live.  As a result, every store item in
the hello@2.10 derivation's closure becomes live, also.  In this way,
--gc-keep-derivations=yes causes liveness to flow from outputs to
derivations.

But we're not done yet.  Consider one of the derivations that shows up
in the hello@2.10' derivation's closure:

/gnu/store/5752c05gravrwk2kvy1n2zrgl9j0kxhg-gcc-4.9.4.tar.bz2.drv

This derivation builds a tarball of gcc's sources.  Let's build it:

--8<---------------cut here---------------start------------->8---
$ guix build /gnu/store/5752c05gravrwk2kvy1n2zrgl9j0kxhg-gcc-4.9.4.tar.bz2.drv
/gnu/store/1j3mqrcp3y4xlb9jl5d0ri5aszn8mfii-gcc-4.9.4.tar.bz2
--8<---------------cut here---------------end--------------->8---

The output path of this derivation is
/gnu/store/...mfii-gcc-4.9.4.tar.bz2, which appears in neither the
closure of hello@2.10's derivation nor the closure of hello@2.10's
output.  So, if you had built this derivation while building hello@2.10,
the derivation's output (/gnu/store/...mfii-gcc-4.9.4.tar.bz2) would be
eligible for garbage collection even if you had specified
--gc-keep-derivations=yes.

This is where --gc-keep-outputs=yes comes in.  If you specify it, then
the /gnu/store/...mfii-gcc-4.9.4.tar.bz2 store item will be treated as
live, since it is the output of a live derivation
(/gnu/store/...kxhg-gcc-4.9.4.tar.bz2.drv).  In this way,
--gc-keep-outputs=yes causes liveness to flow from derivations to
outputs.

In Guix, the defaults are --gc-keep-outputs=no and
--gc-keep-derivations=yes.  In this configuration, derivations tend to
be kept, and outputs tend to be collected.  Derivations usually don't
take up much space (invoke "guix size $(guix build -d hello)" to get an
idea of how small they are), but their outputs can be large.  If you set
--gc-keep-outputs=yes in addition to --gc-keep-derivations=yes, you will
retain package outputs that you install, as well as all the derivations
necessary for building the package, as well as all the outputs that you
built while running those derivations.  If you build from source instead
of downloading substitutes, this means you'll have a lot of intermediary
outputs stored in your local file system, and you won't be able to
collect them, since they'll all be live.

You should try setting both to yes explicitly and see if this makes your
experience any better.  Hopefully it does!  However, there is a chance
it might actually cause even more disk usage, and you might not be able
to collect enough garbage to free up space.

Anyway, I hope that helps clarify what these options do.  I had
forgotten about it, myself, so it was fun to remind myself how it works.

Pierre Neidhardt <ambrevar@gmail.com> writes:

> The store does not have timestamps, so removing old items would not work
> I guess.  But what about removing older versions first?  Say I have
> glibc-2.24 and glibc-2.25, only remove glibc-2.24 if that's enough to
> free the required space.
>
> Maybe we could introduce a "whitelist" of packages to delete last.

These might help, but I think the options I suggested are the best thing
to try first.  Do they help in your case?  You might need to
aggressively delete old profile generations, also, to make sure you have
some garbage to collect.

> In the end I figured that the most convenient way to clean up the
>store
> might be to do it manually with "guix gc --delete PATH".  Well, not so
> from the commandline, but with guix.el I thought we could do something
> nice.  So I gave it a (quick&dirty™) shot:
>
> 	https://gitlab.com/emacs-guix/emacs-guix/issues/2
>
> With guix.el loaded, `eval' my example and run "M-x guix-store".
> This will return a list of all the dead links, which you can sort by
> name or by size.  You can then mark items ("m") and delete them ("k").
>
> What do you people think?

I don't use emacs-guix, so I can't comment on it, I'm afraid.  Maybe
someday I'll get around to using it, and then I can say something
useful!

> While I'm at it, I'd like to note that something might be wrong with the
> `-F` option: I never get the promised amount of free space back, only
> about 2/3 of it.

I think that's normal.  My understanding is that if you say "guix gc -F
3GiB", you aren't asking Guix to free 3 GiB; you're asking Guix to try
to free enough space so that when it's done, the store will have 3 GiB
of free space.  For example, if the store begins with 2 GiB of free
space and there is 5 GiB of garbage, Guix will only collect 1 GiB in
order to bring the free space up to 3 GiB.


-- 
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: guix gc: smarter collection & guix.el manual deletion

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 1505 bytes --]

Fantastic review!
Thank you so much for this: very clear, very thorough, it scattered all
remaining confusions!  I thumb up for a blog post! :D

While I had understood most of it, I was completely ignorant of the separation
between the .drv closure and the output closure.  It all makes much more sense now.

I think the documentation of `--gc-keep-outputs` ought to be updated.

> I don't use emacs-guix, so I can't comment on it, I'm afraid.  Maybe
> someday I'll get around to using it, and then I can say something
> useful!

I find emacs-guix tremendously useful, I highly recommend you give it a try (the
learning curve is very flat).  Any reason why you'd rather not use it?

> > While I'm at it, I'd like to note that something might be wrong with the
> > `-F` option: I never get the promised amount of free space back, only
> > about 2/3 of it.
>
> I think that's normal.  My understanding is that if you say "guix gc -F
> 3GiB", you aren't asking Guix to free 3 GiB; you're asking Guix to try
> to free enough space so that when it's done, the store will have 3 GiB
> of free space.  For example, if the store begins with 2 GiB of free
> space and there is 5 GiB of garbage, Guix will only collect 1 GiB in
> order to bring the free space up to 3 GiB.

No, I'm talking total disk usage here.  If I ask 5G back, then `df /` tells me
that root has about 3-4G free, it never has the promised amount.  Can someone
confirm this?  Might be a bug.
-- 
Pierre Neidhardt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]