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

Re: [libvirt] [PATCH] Allow blkdeviotune to take human readable values



On Tue, May 3, 2016 at 8:00 PM, Peter Krempa <pkrempa redhat com> wrote:
On Tue, May 03, 2016 at 14:09:42 +0000, Nishith Shah wrote:
> Use vshCommandOptScaledInt instead of vshCommandOptULongLong so there is
> no need to pass values in raw bytes, which is seldom the case.

A change like this is incomplete without adding documentation to the
virsh man page (tools/virsh.pod) and in the help strings that document
the individual arguments in the source file.
Sorry about that, this is my first patch and so I am still figuring things out. I will add the details in virsh.pod. Can you elaborate a bit on the help strings in this context?


> ---
>  tools/virsh-domain.c | 26 +++++++++++++-------------
>  1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
> index 0a6caae..3843675 100644
> --- a/tools/virsh-domain.c
> +++ b/tools/virsh-domain.c

[...]

> @@ -1353,7 +1353,7 @@ cmdBlkdeviotune(vshControl *ctl, const vshCmd *cmd)
>              goto save_error;
>      }
>
> -    if ((rv = vshCommandOptULongLong(ctl, cmd, "total-iops-sec", &value)) < 0) {
> +    if ((rv = vshCommandOptScaledInt(ctl, cmd, "total-iops-sec", &value, 1, ULLONG_MAX)) < 0) {

iops is a count rather than a byte size so i don't think the default
scaling function is a good fit since:

kiB -> 1024
KB -> 1000
k -> 1024
True, I hadn't thought of that. Should we use a scaling function at all here, since the usual values of iops[1] dont really need to be given in a short format like 1K or 1M?

[1]: https://en.wikipedia.org/wiki/IOPS#Examples

Regards,
Nishith

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