From: John Snow <jsnow@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
QEMU Developers <qemu-devel@nongnu.org>,
Qemu-block <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] hd-geo-test creates 4GB files on FSes that don't support sparse images, doesn't delete them on error
Date: Mon, 31 Aug 2015 14:54:10 -0400 [thread overview]
Message-ID: <55E4A2D2.4090000@redhat.com> (raw)
In-Reply-To: <87mvxb8sv9.fsf@blackfin.pond.sub.org>
On 08/28/2015 09:06 AM, Markus Armbruster wrote:
> John Snow <jsnow@redhat.com> writes:
>
>> On 08/27/2015 11:29 AM, Eric Blake wrote:
>>> On 08/27/2015 09:17 AM, Peter Maydell wrote:
>>>> I've noticed recently that tests/hd-geo-test.c creates test disk
>>>> images which are 4GB in size, which is a problem if the filesystem
>>>> on the host doesn't support sparse files. In particular, OSX's HFS+
>>>> doesn't have sparse file support, and Windows probably doesn't either.
>>>
>>> Windows NTFS supports sparse files (minimum hole size of 64k), but it
>>> can be a pain to set up, and while it saves disk space, it may actually
>>> slow your program down.
>>>
>>> [At one point cygwin created sparse files on windows by default, but
>>> because it was demonstrated to hurt performance in dealing with sparse
>>> files, because Windows doesn't handle sparse files efficiently, the
>>> cygwin defaults were switched so that it now requires an explicit opt-in
>>> mount option before even attempting sparse files]
>>>
>>>> Worse, if the test fails an assertion somewhere the test doesn't
>>>> clean up after itself and leaves a 4GB file lying around in /tmp/.
>>>>
>>>> It would be nice if we could skip these tests on filesystems that
>>>> don't have sparse file support...
>>>
>>> Or even where sparse files are supported but not default.
>>>
>>
>> Does this test *require* the raw format?
>
> If memory serves, the test doesn't require a specific format, only the
> size and the contents of the MBR matters.
>
>> Use tests/libqos/libqos.c mkqcow2 instead. I'll send a patch.
>
> Go right ahead.
>
Oh, taking a look at it, it needs to writethat MBR data to the file
before it opens it. We don't have an existing qemu-io dependency here to
use.
I could add it, but the line between iotest and qtest starts to get
pretty fuzzy.
Thoughts?
--js
next prev parent reply other threads:[~2015-08-31 18:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-27 15:17 [Qemu-devel] hd-geo-test creates 4GB files on FSes that don't support sparse images, doesn't delete them on error Peter Maydell
2015-08-27 15:29 ` Eric Blake
2015-08-27 16:48 ` John Snow
2015-08-28 13:06 ` Markus Armbruster
2015-08-31 18:54 ` John Snow [this message]
2015-08-31 19:25 ` Peter Maydell
2015-09-01 6:02 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55E4A2D2.4090000@redhat.com \
--to=jsnow@redhat.com \
--cc=armbru@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).