qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] qemu-img: Allow source cache mode specifica


From: Max Reitz
Subject: Re: [Qemu-devel] [PATCH 1/2] qemu-img: Allow source cache mode specification
Date: Fri, 25 Jul 2014 01:44:20 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

On 23.07.2014 10:10, Kevin Wolf wrote:
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).

Right, but we don't really have the choice to suddenly make -t an upper-case option.

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.

Well, it's not completely random; -t is a cache mode and -T will be, too (and I don't think -T should be used for anything but another cache mode). I guess I'd generally vote for introducing long options for everything after this series, but then some people might use -T and confuse others (hence not introducing -T at all might actually make sense). I'd be fine with -t and -T and introducing long options later on, so I leave it up to you. ;-)

Max



reply via email to

[Prev in Thread] Current Thread [Next in Thread]