GNU bug report logs - #74862
`tests/store-deduplication.scm` fails on Asahi Linux

Previous Next

Package: guix;

Reported by: Lukas Navickas <l.navickas <at> pm.me>

Date: Fri, 13 Dec 2024 23:09:03 UTC

Severity: normal

To reply to this bug, email your comments to 74862 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#74862; Package guix. (Fri, 13 Dec 2024 23:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lukas Navickas <l.navickas <at> pm.me>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Fri, 13 Dec 2024 23:09:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lukas Navickas <l.navickas <at> pm.me>
To: "bug-guix <at> gnu.org" <bug-guix <at> gnu.org>
Subject: `tests/store-deduplication.scm` fails on Asahi Linux
Date: Fri, 13 Dec 2024 21:18:28 +0000
`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'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.




Information forwarded to bug-guix <at> gnu.org:
bug#74862; Package guix. (Fri, 21 Feb 2025 21:35:02 GMT) Full text and rfc822 format available.

Message #8 received at 74862 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Lukas Navickas <l.navickas <at> pm.me>, 74862 <at> debbugs.gnu.org
Subject: Re: bug#74862: `tests/store-deduplication.scm` fails on Asahi Linux
Date: Fri, 21 Feb 2025 13:34:09 -0800
[Message part 1 (text/plain, inline)]
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
[signature.asc (application/pgp-signature, inline)]

This bug report was last modified 175 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.