From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size Date: Tue, 05 Jan 2010 14:58:43 +0200 Message-ID: <4B433783.6090400@redhat.com> References: <1262018363-15871-1-git-send-email-avi@redhat.com> <201001041338.52621.rusty@rustcorp.com.au> <20100104083035.GA7461@lst.de> <201001052326.33216.rusty@rustcorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org To: Rusty Russell Return-path: Received: from mx1.redhat.com ([209.132.183.28]:9338 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752631Ab0AEM7L (ORCPT ); Tue, 5 Jan 2010 07:59:11 -0500 In-Reply-To: <201001052326.33216.rusty@rustcorp.com.au> Sender: kvm-owner@vger.kernel.org List-ID: 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