From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq14e-0003MZ-TV for qemu-devel@nongnu.org; Mon, 09 Dec 2013 08:40:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vq14Y-0002o1-Rn for qemu-devel@nongnu.org; Mon, 09 Dec 2013 08:40:36 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq14Y-0002nr-JU for qemu-devel@nongnu.org; Mon, 09 Dec 2013 08:40:30 -0500 Message-ID: <52A5C840.5080707@redhat.com> Date: Mon, 09 Dec 2013 14:40:16 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1386350580-5666-1-git-send-email-kwolf@redhat.com> <1386350580-5666-6-git-send-email-kwolf@redhat.com> <52A20F0E.8070001@redhat.com> <20131209125806.GC3549@dhcp-200-207.str.redhat.com> In-Reply-To: <20131209125806.GC3549@dhcp-200-207.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 05/19] raw: Probe required direct I/O alignment List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: pl@kamp.de, qemu-devel@nongnu.org, stefanha@redhat.com, armbru@redhat.com Il 09/12/2013 13:58, Kevin Wolf ha scritto: > How is BlockLimits supposed with respect to inheritance of values > through the BDS tree? I think right now the accessor wrappers for the various BlockLimits field sort that out. Of course this could be slow if the accessors end up in the fast path (but that's not different from what your series does already). > I tried looking at the code, but for example > bl.opt_transfer_length is only forwarded in raw, so for any other format > (or if you ever put a filter there) it simply doesn't work. That's correct. For example, for qcow2 the optimal transfer length could be the cluster size. Without benchmarking, I didn't complain about Peter's choice of leaving it zero. > I could initialise a new BlockLimits.opt_mem_align field in > bdrv_open_common() with the value of bs->file->bl.opt_mem_align, and in > bdrv_open_backing_file() change it to MAX(bs->bl.opt_mem_align, > bs->backing_hd->bl.opt_mem_align). The block driver could then in > bdrv_open() override the former, but never the latter. > > What would happen on bdrv_reopen(), specifically toggling O_DIRECT? The > values would have to change then. Yes. This also goes in favor of making wrappers handle the stacking of limits, at least for now. Paolo