Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size

[Avi Kivity <avi@redhat.com>]

On 01/05/2010 02:56 PM, Rusty Russell wrote:
>
>> Those should be the same for any sane interface.  They are for classical
>> disk devices with larger block sizes (MO, s390 dasd) and also for the
>> now appearing 4k sector scsi disks.  But in the ide world people are
>> concerned about dos/window legacy compatiblity so they came up with a
>> nasty hack:
>>
>>   - there is a physical block size as used by the disk internally
>>     (4k initially)
>>   - all the interfaces to the operating system still happen in the
>>     traditional 512 byte blocks to not break any existing assumptions
>>   - to make sure modern operating systems can optimize for the larger
>>     physical sectors the disks expose this size, too.
>>   - even worse disks can also have alignment hacks for the traditional
>>     DOS partitions tables, so that the 512 byte block zero might even
>>     have an offset into the first larger physical block.  This is also
>>     exposed in the ATA identify information.
>>
>> All in all I don't think this mess is a good idea to replicate in
>> virtio.  Virtio by defintion requires virtualization aware guests, so we
>> should just follow the SCSI way of larger real block sizes here.
>>      
> Yes.  The current VIRTIO_BLK_F_BLK_SIZE says "please use this block size".
> We haven't actually specified what happens if the guest doesn't, but the
> spec says "must", and the Linux implementation does so AFAICT.
>
> If we want a "soft" size, we could add that as a separate feature.
>    

No - I agree with Christoph, there's no reason to use a 512/4096 
monstrosity with virtio.

-- 
error compiling committee.c: too many arguments to function