[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [RFC PATCH v6 2/4] hw/block: Pad undersize

From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [RFC PATCH v6 2/4] hw/block: Pad undersized read-only images with 0xFF
Date: Thu, 7 Mar 2019 11:55:36 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]