Re: [Qemu-devel] [PATCH v5 01/20] block: Add .bdrv_co_block_status() callback

[Eric Blake <eblake@redhat.com>]

On 12/01/2017 08:40 AM, Kevin Wolf wrote:
>> Note that most drivers give sector-aligned answers, except at
>> end-of-file, even when request_alignment is smaller than a sector.
>> However, bdrv_getlength() is sector-aligned (even though it gives a
>> byte answer), often by exceeding the actual file size.  If we were to
>> give back strict results, at least file-posix.c would report a
>> transition from DATA to HOLE at the end of a file even in the middle
>> of a sector, which can throw off callers; so we intentionally lie and
>> state that any partial sector at the end of a file has the same
>> status for the entire sector.  Maybe at some future day we can
>> report actual file size instead of rounding up, but not for this
>> series.
> 
> In what way does this throw off callers in practice?
> 

Several iotests failed if I didn't do that (it's been a few months, so 
the details are a bit fuzzy).  I think the biggest problem is that 
because we round the size up in bdrv_getlength(), but CANNOT access 
those rounded bytes, then reporting the status of those bytes as a hole 
(which is the only sane thing that file-posix can do) can cause grief 
when the rest of the sector (which we CAN access) is data.

> The rounding will lead to strange effects, and I'm not sure that dealing
> with them is any easier than fixing the callers. Imagine an image file
> like this (very small example, file size 384 bytes):
> 
>      0    128      384  512
>      |    |        |    |
>      +----+--------+----+
>      |Hole|  Data  |    |
>      +----+--------+----+
>                    |
>                    EOF

Unlikely.  Holes are at least a sector in size on all known filesystems 
that have holes; that's also true for qcow2 format.  The only 
non-sector-aligned hole that you can encounter in practice is at EOF.

> 
> bdrv_co_block_status(offset=0, bytes=512) returns 512 bytes of HOLE.
> bdrv_co_block_status(offset=128, bytes=512) returns 384 bytes of DATA.
> bdrv_co_block_status(offset=384, bytes=512) returns 128 bytes of HOLE.
> 
> This is not only contradictory, but the first one is almost begging for
> data corruption because it returns HOLE for a region that actually
> contains data.

I agree that it would be confusing, if it were possible.  But in 
practice it is not possible.

> 
> The only excuse I can imagine is that we say that this can never happen
> because drivers use 512 byte granularity anyway. But why are we
> introducing the new interface then? I don't think this semantics is
> compatible with a bytes-based driver interface.

Really, the ONLY boundary that is unlikely to ever be 512-byte aligned 
is at EOF - and we wouldn't even need to do any rounding if 
bdrv_getlength() didn't round.

One thing I _can_ do: it is ALWAYS valid to report a partial sector as 
data. It may pessimize the code slightly, but while rounding the size of 
a hole up can be wrong if the rounding covers data but the caller 
getting the rounded data treats that data as 0, rounding the size of 
data up will never misbehave because the caller will just read the 
literal zeroes.  So I will tweak the code to make sure that if any 
rounding takes place, that either the driver already set BDRV_BLOCK_EOF 
(all further bytes also read as zero), or else report the rounded region 
as data.  (I thought I could get away with only io.c setting 
BDRV_BLOCK_EOF; but it sounds like setting it in the drivers will be 
helpful).

> 
>> We also add an assertion that any driver using the new callback will
>> make progress (the only time pnum will be 0 is if the block layer
>> already handled an out-of-bounds request, or if there is an error).
>>
>> Signed-off-by: Eric Blake <eblake@redhat.com>
>>
>> +    ret = bs->drv->bdrv_co_block_status(bs, want_zero, aligned_offset,
>> +                                        aligned_bytes, pnum, &local_map,
>> +                                        &local_file);
>> +    if (ret < 0) {
>> +        *pnum = 0;
>> +        goto out;
>> +    }
>> +    assert(*pnum); /* The block driver must make progress */

I debated about combining this assert...

>> +
>> +    /*
>> +     * total_size is always sector-aligned, by sometimes exceeding actual
>> +     * file size. Expand pnum if it lands mid-sector due to end-of-file.
>> +     */
>> +    if (QEMU_ALIGN_UP(*pnum + aligned_offset,
> 
> aligned_offset + *pnum wouldn be the more conventional order.

Sure.

> 
>> +                      BDRV_SECTOR_SIZE) == total_size) {
>> +        *pnum = total_size - aligned_offset;
>> +    }
>> +refine:
>>       /*
>>        * The driver's result must be a multiple of request_alignment.
>>        * Clamp pnum and adjust map to original request.

...with these, but it would trigger on at least vmdk (see patch 17/20)

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