Comments

Add a logical block size attribute as various guest side tools only
increase the filesystem sector size based on it, not the advisory
physical block size.
For scsi we already have support for a different logical block size
in place for CDROMs that we can built upon. Only my recent block
device characteristics VPD page needs some fixups. Note that we
leave the logial block size for CDROMs hardcoded as the 2k value
is expected for it in general.
For virtio-blk we already have a feature flag claiming to support
a variable logical block size that was added for the s390 kuli
hypervisor. Interestingly it does not actually change the units
in which the protocol works, which is still fixed at 512 bytes,
but only communicates a different minimum I/O granularity. So
all we need to do in virtio is to add a trap for unaligned I/O
and round down the device size to the next multiple of the logical
block size.
IDE does not support any other logical block size than 512 bytes.
Signed-off-by: Christoph Hellwig <hch@lst.de>

Am Donnerstag 04 März 2010 14:20:17 schrieb Christoph Hellwig:
> > Add a logical block size attribute as various guest side tools only> increase the filesystem sector size based on it, not the advisory> physical block size.> > For scsi we already have support for a different logical block size> in place for CDROMs that we can built upon. Only my recent block> device characteristics VPD page needs some fixups. Note that we> leave the logial block size for CDROMs hardcoded as the 2k value> is expected for it in general.> > For virtio-blk we already have a feature flag claiming to support> a variable logical block size that was added for the s390 kuli> hypervisor. Interestingly it does not actually change the units> in which the protocol works, which is still fixed at 512 bytes,> but only communicates a different minimum I/O granularity. So> all we need to do in virtio is to add a trap for unaligned I/O> and round down the device size to the next multiple of the logical> block size.> > IDE does not support any other logical block size than 512 bytes.
We did that because we wanted to use DASD devices, which have a 4k
block/sector size as backing for virtio. 512 byte request did work
(thanks to host page cache) but a single 512 byte write might have
triggered a 4k read and O_DIRECT accesses (avoiding host caching)
was also not working.
Testing and review is still in my todo list.
Christian

On Fri, Mar 05, 2010 at 10:26:21AM +0100, Kevin Wolf wrote:
> Is there a check anywhere that the user didn't give us an odd block> size? We could get an interesting bit mask otherwise.
Not yet. I used to have such a check in the first incarnation of
the block topology patches, but I have no idea how to do it in a
centralized way using the qdev attributs.
Does anyone know if there's a better way to do this than just
duplicating the check in every driver?

Am 05.03.2010 10:32, schrieb Christoph Hellwig:
> On Fri, Mar 05, 2010 at 10:26:21AM +0100, Kevin Wolf wrote:>> Is there a check anywhere that the user didn't give us an odd block>> size? We could get an interesting bit mask otherwise.> > Not yet. I used to have such a check in the first incarnation of> the block topology patches, but I have no idea how to do it in a> centralized way using the qdev attributs.> > Does anyone know if there's a better way to do this than just> duplicating the check in every driver?
We could probably introduce a new qdev property type that says "unsigned
16 bit integer, but only powers of two", and doing this looks quite
easy. On the other hand, having a new type for each possible restriction
sounds a bit silly...
Kevin

Am Donnerstag 04 März 2010 14:20:17 schrieb Christoph Hellwig:
> > Add a logical block size attribute as various guest side tools only> increase the filesystem sector size based on it, not the advisory> physical block size.> > For scsi we already have support for a different logical block size> in place for CDROMs that we can built upon. Only my recent block> device characteristics VPD page needs some fixups. Note that we> leave the logial block size for CDROMs hardcoded as the 2k value> is expected for it in general.> > For virtio-blk we already have a feature flag claiming to support> a variable logical block size that was added for the s390 kuli> hypervisor. Interestingly it does not actually change the units> in which the protocol works, which is still fixed at 512 bytes,> but only communicates a different minimum I/O granularity. So> all we need to do in virtio is to add a trap for unaligned I/O> and round down the device size to the next multiple of the logical> block size.> > IDE does not support any other logical block size than 512 bytes.> > Signed-off-by: Christoph Hellwig <hch@lst.de>
Patch looks sane.
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>

2010/3/4 Christoph Hellwig <hch@lst.de>:
>> Add a logical block size attribute as various guest side tools only> increase the filesystem sector size based on it, not the advisory> physical block size.>> For scsi we already have support for a different logical block size> in place for CDROMs that we can built upon. Only my recent block> device characteristics VPD page needs some fixups. Note that we> leave the logial block size for CDROMs hardcoded as the 2k value> is expected for it in general.
By "general" do you mean qemu, or the guests?
Solaris 2.0 - 2.5.1 and SunOS 4.x expect CDROM block size of 512 bytes.
Would have been nice to have the block size for CDROM configurable too.
Currently the CDROMs mentioned above have to be plugged as hard disks
in order to function.