On 9/3/26 18:57, Fabiano Rosas wrote: > "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. Great.
Clearly postponed, dropping this from watch list. Thanks a lot for your time. Den
