"Denis V. Lunev" <[email protected]> writes: > On 8/27/26 13:03, Daniel P. Berrangé wrote: >> On Thu, Aug 27, 2026 at 12:16:56PM +0200, Thomas Huth wrote: >>> Hi Denis! >>> >>> Please make sure to CC: the qtest maintainer (Fabiano Rosas) on series like >>> this. >>> >>> On 24/08/2026 22.06, Denis V. Lunev wrote: >>>> John reported ide-test dying at startup in the NetBSD VM: >>>> >>>> ERROR:../src/tests/qtest/ide-test.c:1260:main: assertion failed: >>>> (ret == 0) >>>> >>>> The hypothesys is that the ftruncate() of a 64 MiB scratch image. NetBSD >>>> mounts /tmp as a tmpfs sized at 25% of RAM and charges a file its full >>>> length themoment it is extended, so a sparse image is not free there and >>>> the call returns ENOSPC. The assert dates to 2013, nothing regressed. >>> Does NetBSD have another file like /var/tmp that might be friendlier to >>> sparse files? If so, maybe that should be used instead? >>> >>> OTOH, our NetBSD VM in tests/vm/ uses 4G of RAM, so a temporary file with >>> just 64 MiB should really not be a problem...? >> Or this is a concurrency scaling problem, or racing with another test >> that also uses stuff ? >> >> We hard code memory to 4 GB, but -smp we scale to "$NUM-CPUs / 2" >> for the "make vm-build-DIST" commands. >> >> IOW, regardless of whether QEMU is launched with -smp 1 or -smp 20, >> we only give it 4 GB to play with. We could be using a lot of RAM >> for concurrent build jobs leaving almost nothing for the tmpfs for >> the test. >> >> If we were that close to exhaustion I'd expected to see out of >> memory errors, but I'm unclear what NetBSD's behaviour is in >> this respect ? Maybe normal RAM usage can be pushed to swap >> (of which I see another 4 GB) while tmpfs can't be pushed >> to swap ? >> >> >> >> >> With regards, >> Daniel > Guys, > > will somebody take a look into what was done? > This makes sense anyway - unified same class error tracking > plus requirements reduction. >
I cannot reproduce this. I also don't think ENOSPC on 64MB is something worth the churn at all. > Or if nobody care I could just push along with another > test fix? > > Thank you in advance, > Den
