bug#53696: Integer overflow on Guix GC size calculation

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Dienstag, dem 01.02.2022 um 21:54 +0000 schrieb Ekaitz Zarraga:
> 
> Hi,
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 
> On Tuesday, February 1st, 2022 at 10:20 PM, Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
> > 
> > I find it somewhat concerning that you've accumulated more than
> > 2^64 bytes of garbage.
> 
> I'm a dirty boy.
> 
> > Are some items counted double here?
> 
> The number started growing from 0 and then that appeared and it
> continued smoothly from the previous. It's like something went bad in
> the middle.
WDYM by the middle?  Do you mean the jump back to 0 or do you mean
something before those lines?  If you did encounter a "self-correcting"
bit-flip that'd be one thing, but to me it appears as though you have
some very large storage on your hands.  Would you mind me asking where
you purchased that disk 😜

> > Other than that, that's pretty normal size_t wraparound semantics.
> > I don't think that number is used for anything other than
> > displaying.
> 
> Showing wrong information to the people that use the program is
> pretty weird. The program still works but showing wrong data is worse
> than not showing it in my opinion.
> I'll take a look and try to see if I can fix it.
I mean we could switch to GMP for those numbers, but it doesn't make
sense.  Ext4 volume size is capped at 2^60, which is still pretty well
below 2^64.  Even BTRFS can't get larger than that.  So unless you have
a distributed store, I'd hazard a guess that such numbers ought not to
even appear.

Cheers