On 2024-12-13, Lukas Navickas wrote:
> `copy-file/deduplicate, sparse files` tests fail on asahi linux.
>
> i do not have adequate grounding on this topic, but i made a few empirical tests changing the inputs.
>
> the original tests create a file in `/tmp`, and fail.
> if instead the file is on disk, some(all?) tests pass.
> if instead the inputs are changed from 2*4096 to 2*16834, some tests pass.
>
> tmpfs on apple silicon has a block size of 16834. i'm guessing this corresponds to its RAM page size.

I suspect this is the same issue building guix on Debian ppc64el:

  https://buildd.debian.org/status/fetch.php?pkg=guix&arch=ppc64el&ver=1.4.0%2B154710%2Bab1b5-1&stamp=1740138790&raw=0

FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 0/8192/0) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 0/8192/8192) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 0/9999/0) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 0/9999/8192) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 0/16384/0) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 0/16384/8192) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 0/22222/0) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 0/22222/8192) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 3333/8192/0) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 3333/8192/8192) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 3333/9999/0) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 3333/9999/8192) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 3333/16384/0) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 3333/16384/8192) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 3333/22222/0) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 3333/22222/8192) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 8192/8192/0) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 8192/8192/8192) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 8192/9999/0) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 8192/9999/8192) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 8192/16384/0) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 8192/16384/8192) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 8192/22222/0) 
FAIL: tests/store-deduplication.scm - copy-file/deduplicate, sparse files (holes: 8192/22222/8192)


Various architectures have different page sizes, for example:

  https://wiki.debian.org/ArchitectureSpecificsMemo

Even within an architecture, it may vary, as ppc64el uses variable
4k-64k as opposed to arm64 which uses 4k, 16k (e.g. asahi), or 64k which
I believe is fixed at boot time and hardware dependent.


> i'm inferring that this test has a hidden dependency: the block size
> of the underlying filesystem that contains the tested files. it may be
> desirable to account for this dependency.

At the very least, the test should be skipped if assumptions about ram
page sizes are made and the environment does not match those
assumptions...

For the short term, I plan on disabling this test on ppc64el for Debian,
but a better fix upstream would be appreciated! :)


live well,
  vagrant