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.

Or if nobody care I could just push along with another
test fix?

Thank you in advance,
    Den

Reply via email to