From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60598 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OvY51-0005ID-KT for qemu-devel@nongnu.org; Tue, 14 Sep 2010 12:10:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OvY50-0008QE-1W for qemu-devel@nongnu.org; Tue, 14 Sep 2010 12:09:59 -0400 Received: from verein.lst.de ([213.95.11.210]:37892) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OvY4z-0008P3-KV for qemu-devel@nongnu.org; Tue, 14 Sep 2010 12:09:58 -0400 Date: Tue, 14 Sep 2010 18:09:38 +0200 From: Christoph Hellwig Subject: Re: [Qemu-devel] [PATCH 1/5] use qemu_blockalign consistently Message-ID: <20100914160938.GA28027@lst.de> References: <20100912214256.GA4854@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Christoph Hellwig , qemu-devel@nongnu.org On Mon, Sep 13, 2010 at 08:02:28PM +0100, Stefan Hajnoczi wrote: > On Sun, Sep 12, 2010 at 10:42 PM, Christoph Hellwig wrote: > > Use qemu_blockalign for all allocations in the block layer. ?This allows > > increasing the required alignment, which is need to support O_DIRECT on > > devices with large block sizes. > > > > Signed-off-by: Christoph Hellwig > > I noticed that the backing file may have different alignment > requirements than the image file but qemu_blockalign() currently only > takes into account the image file's requirements. Not necessarily > something for this patch, but since you're in the area I wanted to > mention it. > > It seems safe to take the max alignment (they should both be powers of > two I think) of the image and backing files. Currently we check the required alignment based on the blocksize we present to the guest, which is set by the driver. That's a bit upside down, but the best we can do. The problem is that the blocksize of the device the image (and it's backing file reside on) are the lower bound of what we can support in the guest without massive read/modify/write cycles. If we use the page cache the kernel does the cycles for us, but for cache=none we would have to do it ourselves in a rather inefficient way.