qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Thomas Huth <thuth@redhat.com>,
	Qemu-block <qemu-block@nongnu.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Cc: Kevin Wolf <kwolf@redhat.com>, Max Reitz <mreitz@redhat.com>,
	Nir Soffer <nirsof@gmail.com>
Subject: Re: [Qemu-devel] Failing QEMU iotest 175
Date: Fri, 3 May 2019 15:21:06 -0500	[thread overview]
Message-ID: <67a38513-89af-7f54-2fc8-05b5777983ca@redhat.com> (raw)
In-Reply-To: <61685a48-b84e-c379-7193-f456e82635ba@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

On 5/2/19 11:37 PM, Thomas Huth wrote:
> On 02/05/2019 23.56, Eric Blake wrote:
>> On 4/28/19 10:18 AM, Thomas Huth wrote:
>>> QEMU iotest 175 is failing for me when I run it with -raw:
>>>
>>
>>>  == creating image with default preallocation ==
>>>  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576
>>> -size=1048576, blocks=0
>>> +size=1048576, blocks=2
>>
>> What filesystem?
> 
> ext4
> 

Hmm, it's passing for me on ext4, but that probably means we have
different configuration parameters. I'm not sure how to easily show what
parameters a particular ext4 partition uses to compare the differences
between your setup and mine (mine is tuned to whatever defaults Fedora's
installer chose on my behalf), so maybe someone else can chime in.

>> It should be fairly obvious that 'stat -c blocks=%b' is
>> file-system dependent (some allocate slightly more or less space, based
>> on granularities and on predictions of future use), so we may need to
>> update the test to apply a filter or otherwise allow a bit of fuzz in
>> the answer. But 0/2 is definitely different than...
>>>
>>>  == creating image with preallocation off ==
>>>  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 preallocation=off
>>> -size=1048576, blocks=0
>>> +size=1048576, blocks=2
>>>
>>>  == creating image with preallocation full ==
>>>  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 preallocation=full
>>> -size=1048576, blocks=2048
>>> +size=1048576, blocks=2050
>>
>> 2048/2050, so we DO have some indication of whether the file is sparse
>> or fully allocated.
> 
> Maybe we could check that the value after "blocks=" is a single digit in
> the first case, and matches "blocks=20.." in the second case?

I wonder if 'qemu-img map --output=json $TEST_IMG' might be any more
reliable (at least for ignoring any extra block allocations associated
with the file, if it is some journaling option or xattr or other reason
why your files seem to occupy more disk sectors than just the size of
the file would imply).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Eric Blake <eblake@redhat.com>
To: Thomas Huth <thuth@redhat.com>,
	Qemu-block <qemu-block@nongnu.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Cc: Kevin Wolf <kwolf@redhat.com>, Nir Soffer <nirsof@gmail.com>,
	Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] Failing QEMU iotest 175
Date: Fri, 3 May 2019 15:21:06 -0500	[thread overview]
Message-ID: <67a38513-89af-7f54-2fc8-05b5777983ca@redhat.com> (raw)
Message-ID: <20190503202106.__ZV2NUd5FlMNycltA7Uy6OU7nfN3pbZ3vUeOS9fAJg@z> (raw)
In-Reply-To: <61685a48-b84e-c379-7193-f456e82635ba@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]

On 5/2/19 11:37 PM, Thomas Huth wrote:
> On 02/05/2019 23.56, Eric Blake wrote:
>> On 4/28/19 10:18 AM, Thomas Huth wrote:
>>> QEMU iotest 175 is failing for me when I run it with -raw:
>>>
>>
>>>  == creating image with default preallocation ==
>>>  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576
>>> -size=1048576, blocks=0
>>> +size=1048576, blocks=2
>>
>> What filesystem?
> 
> ext4
> 

Hmm, it's passing for me on ext4, but that probably means we have
different configuration parameters. I'm not sure how to easily show what
parameters a particular ext4 partition uses to compare the differences
between your setup and mine (mine is tuned to whatever defaults Fedora's
installer chose on my behalf), so maybe someone else can chime in.

>> It should be fairly obvious that 'stat -c blocks=%b' is
>> file-system dependent (some allocate slightly more or less space, based
>> on granularities and on predictions of future use), so we may need to
>> update the test to apply a filter or otherwise allow a bit of fuzz in
>> the answer. But 0/2 is definitely different than...
>>>
>>>  == creating image with preallocation off ==
>>>  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 preallocation=off
>>> -size=1048576, blocks=0
>>> +size=1048576, blocks=2
>>>
>>>  == creating image with preallocation full ==
>>>  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=1048576 preallocation=full
>>> -size=1048576, blocks=2048
>>> +size=1048576, blocks=2050
>>
>> 2048/2050, so we DO have some indication of whether the file is sparse
>> or fully allocated.
> 
> Maybe we could check that the value after "blocks=" is a single digit in
> the first case, and matches "blocks=20.." in the second case?

I wonder if 'qemu-img map --output=json $TEST_IMG' might be any more
reliable (at least for ignoring any extra block allocations associated
with the file, if it is some journaling option or xattr or other reason
why your files seem to occupy more disk sectors than just the size of
the file would imply).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2019-05-03 20:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-28 15:18 [Qemu-devel] Failing QEMU iotest 175 Thomas Huth
2019-04-28 15:18 ` Thomas Huth
2019-05-02 21:56 ` Eric Blake
2019-05-02 21:56   ` Eric Blake
2019-05-03  4:37   ` Thomas Huth
2019-05-03  4:37     ` Thomas Huth
2019-05-03 20:21     ` Eric Blake [this message]
2019-05-03 20:21       ` Eric Blake
2019-05-03 21:31       ` Nir Soffer
2019-05-03 21:31         ` Nir Soffer
2019-05-10 21:15         ` [Qemu-devel] [Qemu-block] " Nir Soffer
2019-05-04  6:51       ` [Qemu-devel] " Thomas Huth
2019-05-04  6:51         ` Thomas Huth
2019-05-06 17:44         ` Eric Blake
2019-05-15 14:56           ` Stefan Hajnoczi
2019-05-10 13:54 ` Max Reitz
2019-05-10 16:42   ` Thomas Huth
2019-05-10 17:39     ` Max Reitz

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=67a38513-89af-7f54-2fc8-05b5777983ca@redhat.com \
    --to=eblake@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=nirsof@gmail.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /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).