Re: [PATCH 0/7] tests/qtest: fix the disk tests on a host with a small /tmp

[Fabiano Rosas <farosas@suse.de>]

"Denis V. Lunev" <den@virtuozzo.com> 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