On 5/3/19 3:54 PM, Eric Blake wrote: >>> Ugh. Hole granularities are file-system specific, so we need to figure >>> out some way to fuzz the input. It might also be possible to pick nicer >>> size numbers - perhaps if the test image is sized at 64k+1 instead of >>> 43009 (84*512, but NOT evenly divisible by 4k), the +1 byte is more >>> likely to be directly one a hole boundary, rather than being somewhere >>> that causes rounding the hole boundary 2k earlier because of 4k or 64k >>> sizing constraints. >> >> Ok ... sounds like that's definitely something I'd like to leave to you >> or one of the block guys to fix. > > I can certainly prepare a patch that widens the file to 64k+1 instead of > 43008+1, but since I can't (yet) reproduce the failure, I'd be relying > on you to verify that it makes a difference.
Patch posted in another thread. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
