Re: [Libguestfs] [RFC] lib: allow to specify physical/logical block size for disks

On Mon, Feb 10, 2020 at 02:22:01PM +0200, Nikolay Ivanets wrote: > Here are what they do stand for: > physical_block_size: The physical block size the disk will report to > the guest OS. For Linux this would be the value returned by the > BLKPBSZGET ioctl and describes the disk's hardware sector size which > can be relevant for the alignment of disk data. We don't have an API > to get this one. > > logical_block_size: The logical block size the disk will report to the > guest OS. For Linux this would be the value returned by the BLKSSZGET > ioctl and describes the smallest units for disk I/O. We have > blockdev-getsz API to get this value. Interestingly parted uses BLKSSZGET (logical_block_size), but does not use BLKPBSZGET (physical_block_size), so I guess that fits with my observations. > How do they use. If your HDD has physical block size = 4096 you might > want make I/O request equals to (or multiple) this value. Otherwise > you might hit performance penalty. I think, the same is valid for > virtual disk image which is located on physical storage with 4K > physical sector size. ... > Here are possible combinations of [pl]blocksize in real world: > > physical | logical > ----------------------- > 4096 | 4096 > 4096 | 512 > 512 | 512 > > Having both values equals works except for case #2 which will not > impact on functionality, only performance might be hit. > If we want to simplify our API - we might expose the only parameter > called 'blocksize' and set physical_block_size and logical_block_size > to the same value. Right, but libguestfs rarely deals with real physical disks. I think even if eg. you attach libguestfs to /dev/sdX there's still going to be a host kernel in between doing its thing. So I'm not clear that the 4K physical / 512b logical case is actually something that libguestfs cares about. (But OTOH I'm also not clear why qemu cares about this case either.)