On 11/17/2017 02:10 PM, Eric Blake wrote: > On 11/17/2017 01:04 PM, Eric Blake wrote: >> 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. > > Of course, if Kevin sends a v2 pull, it's probably better to just squash > this in to my original testsuite change (since a v2 would probably > invalidate that commit id). >
Whichever way you go, Reviewed-by: John Snow <js...@redhat.com> I don't know how important it is to nail this down, but the purpose of this command is primarily for sanity testing and not necessarily between architectures, so this might just be a limitation to document. Also, don't use this for anything except testing. :(
