On Thursday, August 1, 2024 8:59 PM, Taylor Blau wrote: >On Thu, Aug 01, 2024 at 06:25:51PM -0400, rsbecker@xxxxxxxxxxxxx wrote: >> ls output with second resolution is here - the file system does not have >nanosecond resolution despite showing zeros: >> >> /home/ituglib/randall/git/t/trash >> directory.t7704-repack-cruft/max-cruft-size-prune/.git/objects/pack: >> ls -la --full-time total 11 drwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08- >01 16:18:55.000000000 -0600 . >> drwxrwxrwx 1 ITUGLIB.RANDALL ITUGLIB 4096 2024-08-01 >16:18:48.000000000 -0600 .. >> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB 1156 2024-08-01 >> 16:18:52.000000000 -0600 >> pack-68c6c8c8538900694c32380ac1484201c8b60d8d.idx >> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB 217 2024-08-01 16:18:52.000000000 - >0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.pack >> -r--r--r-- 1 ITUGLIB.RANDALL ITUGLIB 64 2024-08-01 16:18:52.000000000 - >0600 pack-68c6c8c8538900694c32380ac1484201c8b60d8d.rev > >Ah, I suspect that this is even less interesting than imprecise mtime resolution. The >test expects that the packs are larger than 1M so that we can exercise writing >multiple cruft packs as part of the setup. > >But that pack is only 217 bytes, which wouldn't trigger the split. I'm suspicious that >it's even packing the cruft objects at all, so I'm curious if you can find $foo, $bar, >and $baz in the cruft pack's .idx file(s, if multiple) after the first 'git repack -d --cruft'. > >Assuming they are there, it's possible that setting repack.cruftWindow in the test >repository would do the trick. > >But I'm suspicious that that's even what's going on since generate_random_blob()'s >first argument is a seed, and all three objects have different seeds, so I don't think >they would even be considered good delta candidates for one another. But it's also >possible that your >generate_random_blob() behaves differently from my own. I will try to look tomorrow for $foo, $bar, and $baz. On generate_random_blob(), from OpenSSL's standpoint, on ia64, we use PRNGD. It should be of the same order of magnitude as anywhere else, but depends on the randomness measure - we are able to start it, so randomness is proper. On my x86 machine, I use the hardware randomizer, which is better (and FIPS compatible) and might be why we don't see it there.
