Re: QEMU policy for real file tests

[Christian Schoenebeck <qemu_oss@crudebyte.com>]

On Donnerstag, 17. September 2020 14:40:42 CEST Peter Maydell wrote:
> (Ideally we'd put in some more consistent framework for temp files
> used by tests to put them all in a single subdir or something, for
> convenience in cleaning up afterwards.)

Yes, a unified interface for creating and auto wiping these, as well as 
communicating limits for them would be nice to allow test cases adapting to 
low quota vs. generous environments automatically.

For now I take Thomas' advice of 4GB as very rough barrier to stay away from.

On Donnerstag, 17. September 2020 15:11:18 CEST Peter Maydell wrote:
> On Thu, 17 Sep 2020 at 14:04, Thomas Huth <thuth@redhat.com> wrote:
> > On 17/09/2020 14.06, Christian Schoenebeck wrote:
> > [...]
> > 
> > > Final question: if at some later point one large file needs to be
> > > created for some test case, is there some approximate size limit to
> > > stay below for not causing issues with free CI cloud services?
> > 
> > FWIW, I know that 4G is already too big for some containers on Travis,
> > see commit 178d383f10e15f5e5a7.
> 
> Yes. Also "it's sparse" doesn't always help -- eg on OSX there is
> no sparse-file support so a 4GB file really does take 4GB even
> if it's mostly zeroes...

While I agree not using sparse files for test cases, as many environments 
don't support them; as a side note though: macOS actually supports sparse 
files for a long time, both on APFS and HPFS+ volumes. There is F_PUNCHHOLE 
and F_PREALLOCATE for that purpose and st_size reflects the logical file size, 
whereas st_blocks*S_BLKSIZE returns the actual allocated physical file size.

Best regards,
Christian Schoenebeck