Re: [Qemu-devel] [RFC PATCH v6 2/4] hw/block: Pad undersized read-only images with 0xFF

[Eric Blake]

On 3/7/19 8:55 AM, Kevin Wolf wrote:

>>     00000ff0:  79 0a 79 0a 79 0a 79 0a 79 0a 00 00 00 00 00 00  
>> y.y.y.y.y.......
>>     read 96/96 bytes at offset 4000
>>     96 bytes, 1 ops; 0.0001 sec (694.444 KiB/sec and 7407.4074 ops/sec)
>>
>>    This patch then pads some more with 0xFF to the flash memory size.
>>
>>    Because of that the way the magic padding works makes no sense, to be
>>    frank.  Going back to v3's zero padding would at least be explainable
>>    without blushing.
>>
>>    I consider the block layer's padding a misfeature here, but right now
>>    we got to play the hand we've been dealt.
> 
> That will be solved as soon as the block layer is consistently converted
> to byte granularity. We've already converted a lot, but bdrv_getlength()
> is still sector (512 bytes) granularity.
> 
> You could argue that file-posix should just reject files that are not
> sector aligned, but that's probably not right either because image
> formats don't necessarily have that alignment for their files.
> 
> Maybe disk device should reject being attached to nodes that aren't a
> multiple of their physical and logical sector size. A 512-byte aligned
> image is probably suitable for most disks, but might not be for a virtual
> native 4k disk.

nbdkit has a filter that allows padding any non-sector-aligned image out
to the next sector alignment, where reads from the tail see zero, writes
_of zero_ to the tail succeed, but writes of non-zero fail (I don't know
if it prefers EIO or ENOSPC, but that's secondary).  I have an open bug
against the nbd block driver where we can trigger assertions on
unaligned file sizes; and it would definitely be nice to fix it globally
in the block layer rather than copy-and-paste piecemeal in every
affected driver.

I may still fix NBD for 4.0 during soft freeze to avoid the assert, but
that fix will be a bare-bones bandaid (enough to avoid the assertion
failures, and no more).  But yes, I definitely agree that a 4.1 project
of making bdrv_getlength() be byte-aware coupled with block-layer smarts
about handling the tail when widening from a smaller alignment to a
larger is going to make a lot of things nicer.

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

signature.asc
Description: OpenPGP digital signature