From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56166) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzMUI-0002C1-2W for qemu-devel@nongnu.org; Tue, 24 Jun 2014 04:54:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzMUC-0002dE-Jl for qemu-devel@nongnu.org; Tue, 24 Jun 2014 04:53:58 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:53510 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzMUC-0002d2-8I for qemu-devel@nongnu.org; Tue, 24 Jun 2014 04:53:52 -0400 Message-ID: <53A93C95.9040104@kamp.de> Date: Tue, 24 Jun 2014 10:53:41 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1403533836-28589-1-git-send-email-pl@kamp.de> <53A84391.7040904@redhat.com> <439D6F63-2D86-4ABC-9796-4298179201AB@kamp.de> <53A89683.4030707@redhat.com> In-Reply-To: <53A89683.4030707@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] block/nfs: add knob to set readahead List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, pbonzini@redhat.com, stefanha@redhat.com, qemu-devel@nongnu.org, ronniesahlberg@gmail.com On 23.06.2014 23:05, Eric Blake wrote: > On 06/23/2014 02:47 PM, Peter Lieven wrote: > >>>> +#ifdef LIBNFS_FEATURE_READAHEAD >>>> + } else if (!strcmp(qp->p[i].name, "readahead")) { >>>> + nfs_set_readahead(client->context, atoi(qp->p[i].value)); >>>> +#endif >>> I'm not a fan of adding even more special-casing to the file-name URI >>> without also adding it to the QAPI schema for use in the blockdev-add >>> command. Of course, we don't have structured nfs options for >>> blockdev-add yet, but maybe it's time to start thinking about that >>> addition before we do this addition. >> I would like to leave this for a follow-up and I promise to take care of this. >> If you could give me a pointer of an existing driver that does this as a reference >> I would be grateful. > A good example of a recent conversion to structured options would be the > blkdebug and blkverify backends (look around commit 1bf20b82), or > proposed addition of new backends (such as archipelego, > https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg05309.html). > It may be a bigger task than you anticipate, and certainly won't make > the 2.1 timeframe, but it's worth doing so if you're up to the task, > more power to you :) > >> For the read ahead parameter its likely not needed as (at least in my use case) >> the read ahead makes only sense when converting a compressed QCOW2 Template File >> which lives on an NFS Share to a RAW Device. So I use it with qemu-img. >> For a Container File that is used as a VM hard drive I would likely not use read ahead >> as the operating system itself will implement some sort of read ahead already. > Even if qemu-img is likely to be the only one ever specifying the > option, it still makes sense to expose it via QMP, as we are gradually > trying to move qemu-img over to more exclusive use of QMP (or at least > the underlying functions reached by QMP) rather than ad-hoc code. For > example, > https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01822.html). > Ok, it looks like a bit of work. I will put it on my list for 2.2. Thanks for the pointers, Peter