[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Bug 1776920] Re: qemu-img convert on Mac OSX creates c
Re: [Qemu-devel] [Bug 1776920] Re: qemu-img convert on Mac OSX creates corrupt images
Sat, 08 Sep 2018 00:44:21 +0200
KMail/5.1.3 (Linux/4.4.0-134-generic; KDE/5.18.0; x86_64; ; )
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?
(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.
(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)