Re: [PATCH v2 6/6] iotests: Test committing to short backing file - Vladimir Sementsov-Ogievskiy

From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"stefanha@redhat.com" <stefanha@redhat.com>,
	"qemu-block@nongnu.org" <qemu-block@nongnu.org>,
	"mreitz@redhat.com" <mreitz@redhat.com>
Subject: Re: [PATCH v2 6/6] iotests: Test committing to short backing file
Date: Thu, 21 Nov 2019 13:02:58 +0000	[thread overview]
Message-ID: <c2b90dda-d5e7-d2e5-73fd-ba9110ccb50a@virtuozzo.com> (raw)
In-Reply-To: <20191121113943.GF6007@linux.fritz.box>

21.11.2019 14:39, Kevin Wolf wrote:
> Am 21.11.2019 um 11:30 hat Vladimir Sementsov-Ogievskiy geschrieben:
>> 21.11.2019 13:28, Vladimir Sementsov-Ogievskiy wrote:
>>> 20.11.2019 21:45, Kevin Wolf wrote:
>>>> Signed-off-by: Kevin Wolf<kwolf@redhat.com>
>>>
>>> Hmm, allocating 7G will break tests on small disks, for example,
>>> on my 2G tmpfs.
>>>
>>> So, we probably should
>>> detect "+qemu-img: Failed to resize underlying file: Could not write zeros for preallocation: No space left on device"
>>> errors and skip test. (better skip testcases, but it's not possible for text-comparing tests :(
>>
>> Or could you just use smaller disks for resize? What is the purpose of such a big size?
> 
> I want to exceed a 32 bit byte count for the write_zeroes operation so
> that it would break if patch 1 were missing. I guess I could reduce it
> to a little over 4 GB, but not less.
> 
> Hm, though that is only for preallocation=off, which shouldn't actually
> allocate the space anyway. I could use smaller sizes for falloc and
> full, even though I'm not sure if we're still testing these modes with
> sizes larger than INT_MAX anywhere.
> 

Yes, preallocation=off works for me with big disk, so this should work.

-- 
Best regards,
Vladimir