iotests: Fix 176 on 32-bit host
commit2807746ff178fe2e62638755693ece57aeeacc05
authorEric Blake <eblake@redhat.com>
Fri, 17 Nov 2017 19:04:22 +0000 (17 13:04 -0600)
committerMax Reitz <mreitz@redhat.com>
Tue, 21 Nov 2017 13:54:02 +0000 (21 14:54 +0100)
tree8a99e3498a9b08a839a6508a9cf3589f138e186c
parent50a3efb0f05bcfbe04201d4ebac0b96551a1b551
iotests: Fix 176 on 32-bit host

The contents of a qcow2 bitmap are rounded up to a size that
matches the number of bits available for the granularity, but
that granularity differs for 32-bit hosts (our default 64k
cluster allows for 2M bitmap coverage per 'long') and 64-bit
hosts (4M bitmap per 'long').  If the image is a multiple of
2M but not 4M, then the number of bytes occupied by the array
of longs in memory differs between architecture, thus
resulting in different SHA256 hashes.

Furthermore (but untested by me), if our computation of the
SHA256 hash is at all endian-dependent because of how we store
data in memory, that's another variable we'd have to account
for (ideally, we specified the bitmap stored in qcow2 as
fixed-endian on disk, because the same qcow2 file must be
usable across any architecture; but that says nothing about
how we represent things in memory).  But we already have test
165 to validate that bitmaps are stored correctly on disk,
while this test is merely testing that the bitmap exists.

So for this test, the easiest solution is to filter out the
actual hash value.  Broken in commit 4096974e.

Reported-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-id: 20171117190422.23626-1-eblake@redhat.com
Reviewed-by: John Snow <jsnow@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
tests/qemu-iotests/176
tests/qemu-iotests/176.out