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 , > that's more than the global monthly Internet traffic in 2004. > > According to , 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