From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49875) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9rd0-000858-MV for qemu-devel@nongnu.org; Wed, 23 Jul 2014 04:10:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X9rcu-0002Ti-Hv for qemu-devel@nongnu.org; Wed, 23 Jul 2014 04:10:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X9rcu-0002T7-AJ for qemu-devel@nongnu.org; Wed, 23 Jul 2014 04:10:16 -0400 Date: Wed, 23 Jul 2014 10:10:05 +0200 From: Kevin Wolf Message-ID: <20140723081005.GA3666@noname.str.redhat.com> References: <1405802159-2355-1-git-send-email-mreitz@redhat.com> <1405802159-2355-2-git-send-email-mreitz@redhat.com> <53CD3728.1040904@redhat.com> <53CEC441.5020801@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53CEC441.5020801@redhat.com> Subject: Re: [Qemu-devel] [PATCH 1/2] qemu-img: Allow source cache mode specification List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Peter Lieven , qemu-devel@nongnu.org, Stefan Hajnoczi Am 22.07.2014 um 22:06 hat Max Reitz geschrieben: > On 21.07.2014 17:52, Eric Blake wrote: > >On 07/19/2014 02:35 PM, Max Reitz wrote: > >>Many qemu-img subcommands only read the source file(s) once. For these > >>use cases, a full write-back cache is unnecessary and mainly clutters > >>host cache memory. Though this is generally no concern as cache memory > >>is freely available and can be scaled by the host OS, it may become a > >>concern with thin provisioning. > >> > >>For these cases, it makes sense to allow users to freely specify the > >>source cache mode (e.g. use no cache at all). > >> > >>This commit adds a new switch (-T) for the qemu-img subcommands check, > >>compare, convert and rebase to specify the cache to be used for source > >>images (the backing file in case of rebase). > >What mnemonic did you have in mind when choosing -T? Or was it just a > >universally available letter for the subcommands you were touching? > > To be honest, I just didn't know what -t stands for. Therefore I > just thought it might be remotely logical if the lower-cased letter > is used for destination and the upper-cased letter for source > caching. Things might get a bit confusing there, though, because upper-case often means the "other image", i.e. destination or backing file, in other commands (create -F, compare -F, convert -O and -B, rebase -F). Of course, most of them are deprecated, so I wouldn't make that a reason to block this series, but perhaps we should consider using more long options instead of randomly assigning the letters that are still free. Kevin