Sorry for following up my own post, but maybe it wasn't clear why I printed (* 17592186042897 (expt 2 20)) in hex ?
That is the value of [17592186042897 MiB] that you've been discussing. (expt 2 20) is one MiB Does that make > --8<---------------cut here---------------start------------->8--- > $ guile --no-auto-compile -c '(use-modules (ice-9 format))(format #t > "~20x\n~20x\n~20d\n" (* 17592186042897 (expt 2 20)) #xa1100000 #xa1100000)'; > ffffffffa1100000 > a1100000 > 2702180352 > --8<---------------cut here---------------end--------------->8--- a little clearer? The discussion seems to be continuing, but no mention of the above. How come? Feeling ignored, and top-posting in desperation ;/ CC-ing ludo, who will instantly know where to fix it, if he hasn't already. On +2022-02-02 13:04:41 +0100, Bengt Richter wrote: > Hi Maxime, Ekaitz, et al, > > On +2022-02-02 11:05:31 +0100, Maxime Devos wrote: > > Ekaitz Zarraga schreef op di 01-02-2022 om 14:06 [+0000]: > > > [17592186042897 MiB] deleting > > > '/gnu/store/wbz6vkiz7cq8c531xvb31lxm28nz332i-ghc-8.10.7' > > > > For comparison, this is about 16 exbibyte. > > According to <https://en.wikipedia.org/wiki/Byte#Multiple-byte_units>, > > that's more than the global monthly Internet traffic in 2004. > > > > According to <https://what-if.xkcd.com/31/>, 16 exbibyte would be about > > 17 million solid-state disks. Even though this ignores deduplication, > > this seems rather expensive. > > > > My guess is that the size of a store item was misrecorded somewhere. > > > > Greetings, > > Maxime. > > s/misrecorded/mis-defined-in-record/ ? > Wild guessing follows: > > --8<---------------cut here---------------start------------->8--- > $ guile --no-auto-compile -c '(use-modules (ice-9 format))(format #t > "~20x\n~20x\n~20d\n" (* 17592186042897 (expt 2 20)) #xa1100000 #xa1100000)'; > ffffffffa1100000 > a1100000 > 2702180352 > --8<---------------cut here---------------end--------------->8--- > > It looks to me like a 32-bit unsigned int should have been turned to 64-bit > unsigned long or bigint > but somehow got cast/interpreted as signed, becoming signed 64-bit long, > which then in turn was seen by the print as 64-bit unsigned long. > > I don't know, but if records are being used, perhaps some slot > integer-widening logic > might be involved? Or a mis-defined int slot that should have been long to > accomodate > big > 31-bit positive integers? > > Just guessing wildly -- I think I saw something about records and defining > their fields > as fixed C ints or longs. > > -- > Regards, > Bengt Richter > > >