From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSF5B-0006v6-2H for qemu-devel@nongnu.org; Tue, 05 Jan 2010 14:28:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSF56-0006qm-9s for qemu-devel@nongnu.org; Tue, 05 Jan 2010 14:28:44 -0500 Received: from [199.232.76.173] (port=34035 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSF55-0006qW-Vk for qemu-devel@nongnu.org; Tue, 05 Jan 2010 14:28:40 -0500 Received: from mx20.gnu.org ([199.232.41.8]:35457) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSF54-0002qi-T5 for qemu-devel@nongnu.org; Tue, 05 Jan 2010 14:28:39 -0500 Received: from mx1.redhat.com ([209.132.183.28]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NS907-00040a-3H for qemu-devel@nongnu.org; Tue, 05 Jan 2010 07:59:07 -0500 Message-ID: <4B433783.6090400@redhat.com> Date: Tue, 05 Jan 2010 14:58:43 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v2] virtio-blk physical block size 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> In-Reply-To: <201001052326.33216.rusty@rustcorp.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Rusty Russell Cc: virtualization@lists.linux-foundation.org, Christoph Hellwig , kvm@vger.kernel.org, qemu-devel@nongnu.org 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