Re: [Qemu-devel] [Bug 1776920] Re: qemu-img convert on Mac OSX creates corrupt images

[Eric Blake]

On 9/7/18 5:44 PM, Bruno Haible wrote:
> Eric Blake wrote:
> > MacOS comes along, and now both queries return a
> > different offset than your input, but neither fails.  If you optimized
> > by calling SEEK_DATA first, you end up treating the current offset as a
> > hole (data loss). And if you make both calls looking for the
> > POSIX-specified patterns, your logic can be thrown off
>
> How about one of these approaches?
>
> (a) Put some knowledge about the extent boundaries into the code.
>      I.e. round offset down to the previous extend boundary before the
>      two lseek calls?

How do you determine at runtime where an extent boundary begins, short 
of making additional syscalls?  If you're going to be turning one 
syscall into multiple in order to work around the flaw, you might as 
well try to minimize the work...

> (b) Evaluate both
>          d = lseek (fd, SEEK_DATA, offset);
>          h = lseek (fd, SEEK_HOLE, offset);
>      and since you don't know anything about the range from offset
>      to min(d,h)-1, assume it's data.
>      Then, if d < h, you have a data block, or if h < d, you have a hole.

...and thus, this is the minimal solution anyways (ie. merely declaring 
that trying to optimize by making only one of the two calls is going to 
fail because of MacOS data semantics and Solaris hole-at-EOF semantics).

> (c) for (int i = 1; i <= 16; i++)
>        {
>          unsigned long o = max (offset - (1 << i), 0);
>          d = lseek (fd, SEEK_DATA, o);
>          h = lseek (fd, SEEK_HOLE, o);
>          if (d < offset || h < offset)
>            break;
>        }

This seems like an implementation that tries to do (a) - but look at how 
many syscalls it is adding instead of just going straight to (b).

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