From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VozdC-0007vC-NM for qemu-devel@nongnu.org; Fri, 06 Dec 2013 12:56:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vozd6-00044J-FP for qemu-devel@nongnu.org; Fri, 06 Dec 2013 12:56:02 -0500 Received: from mx1.redhat.com ([209.132.183.28]:3321) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vozd6-00044C-13 for qemu-devel@nongnu.org; Fri, 06 Dec 2013 12:55:56 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rB6HtsAf013879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Dec 2013 12:55:55 -0500 Message-ID: <52A20FA7.6070705@redhat.com> Date: Fri, 06 Dec 2013 18:55:51 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1386350580-5666-1-git-send-email-kwolf@redhat.com> In-Reply-To: <1386350580-5666-1-git-send-email-kwolf@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 00/19] block: Support for 512b-on-4k emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, stefanha@redhat.com, armbru@redhat.com Il 06/12/2013 18:22, Kevin Wolf ha scritto: > This patch series adds code to the block layer that allows performing > I/O requests in smaller granularities than required by the host backend > (most importantly, O_DIRECT restrictions). It achieves this for reads > by rounding the request to host-side block boundary, and for writes by > performing a read-modify-write cycle (and serialising requests > touching the same block so that the RMW doesn't write back stale data). > > Originally I intended to reuse a lot of code from Paolo's previous > patch series, however as I tried to integrate pread/pwrite, which > already do a very similar thing (except for considering concurrency), > and because I wanted to implement zero-copy, most of this series ended > up being new code. Very nice! There's not much to comment on regarding the 512-on-4k part. Just one question. Do you think we could make our emulated disks 512b-logical/4k-physical (512E) by default? In other words, I don't remember the outcome of our discussion on whether the standard promises a 4k write granularity for this configuration. Paolo