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
