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 --]
next prev 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: linkBe 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).