qemu-devel
[Top][All Lists]
Advanced

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

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


From: Avi Kivity
Subject: Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size
Date: Tue, 05 Jan 2010 14:58:43 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0

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





reply via email to

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