linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH] Consistent use of IEC 80000-13 prefix in manpage
Date: Thu, 31 Mar 2016 15:09:11 -0400	[thread overview]
Message-ID: <wrfjio028nxk.fsf@redhat.com> (raw)
In-Reply-To: <56FC2DAA.2020605@googlemail.com> (Marko Hauptvogel's message of "Wed, 30 Mar 2016 21:48:58 +0200")

Marko Hauptvogel <marko.hauptvogel@googlemail.com> writes:
> From: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
>
> Added the optional K suffix for completeness, as it
> is allowed by util.c's parse_size(char*).
>
> Signed-off-by: Marko Hauptvogel <marko.hauptvogel@googlemail.com>

I am not very much in favor of this patch. Any normal sane person still
refers to megabytes and kilobytes as referring to 1024 base sizes,
despite the pointless standard trying to mess them up to accommodate the
harddrive vendors. Nobody normal knows what a kibibyte is.

Jes

> ---
>  mdadm.8.in | 21 +++++++++++----------
>  1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/mdadm.8.in b/mdadm.8.in
> index 50be1aa..80b0826 100644
> --- a/mdadm.8.in
> +++ b/mdadm.8.in
> @@ -467,8 +467,8 @@ If this is not specified
>  size, though if there is a variance among the drives of greater than
> 1%, a warning is
>  issued.
>
> -A suffix of 'M' or 'G' can be given to indicate Megabytes or
> -Gigabytes respectively.
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kibibytes,
> Mebibytes or
> +Gibibytes respectively.
>
>  Sometimes a replacement drive can be a little smaller than the
>  original drives though this should be minimised by IDEMA standards.
> @@ -534,8 +534,8 @@ problems the array can be made bigger again with no
> loss with another
>  .B "\-\-grow \-\-array\-size="
>  command.
>
> -A suffix of 'M' or 'G' can be given to indicate Megabytes or
> -Gigabytes respectively.
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kibibytes,
> Mebibytes or
> +Gibibytes respectively.
>  A value of
>  .B max
>  restores the apparent size of the array to be whatever the real
> @@ -551,8 +551,8 @@ This is only meaningful for RAID0, RAID4, RAID5,
> RAID6, and RAID10.
>  RAID4, RAID5, RAID6, and RAID10 require the chunk size to be a power
>  of 2.  In any case it must be a multiple of 4KB.
>
> -A suffix of 'M' or 'G' can be given to indicate Megabytes or
> -Gigabytes respectively.
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kibibytes,
> Mebibytes or
> +Gibibytes respectively.
>
>  .TP
>  .BR \-\-rounding=
> @@ -729,7 +729,7 @@ beneficial.  This can be suppressed with
>  .TP
>  .BR \-\-bitmap\-chunk=
>  Set the chunksize of the bitmap.  Each bit corresponds to that many
> -Kilobytes of storage.
> +Kibibytes of storage.
>  When using a file based bitmap, the default is to use the smallest
>  size that is at-least 4 and requires no more than 2^21 chunks.
>  When using an
> @@ -737,8 +737,8 @@ When using an
>  bitmap, the chunksize defaults to 64Meg, or larger if necessary to
>  fit the bitmap into the available space.
>
> -A suffix of 'M' or 'G' can be given to indicate Megabytes or
> -Gigabytes respectively.
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kibibytes,
> Mebibytes or
> +Gibibytes respectively.
>
>  .TP
>  .BR \-W ", " \-\-write\-mostly
> @@ -808,7 +808,8 @@ an array which was originally created using a
> different version of
>  which computed a different offset.
>
>  Setting the offset explicitly over-rides the default.  The value given
> -is in Kilobytes unless an 'M' or 'G' suffix is given.
> +is in Kibibytes unless a suffix of 'K', 'M' or 'G' is given to indicate
> +Kibibytes, Mebibytes or Gibibytes respectively.
>
>  Since Linux 3.4,
>  .B \-\-data\-offset

  reply	other threads:[~2016-03-31 19:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-30 19:48 [PATCH] Consistent use of IEC 80000-13 prefix in manpage Marko Hauptvogel
2016-03-31 19:09 ` Jes Sorensen [this message]
2016-03-31 22:21   ` [PATCH v2] Consistent use of metric " Marko Hauptvogel
2016-04-01 20:11     ` Jes Sorensen
2016-04-03 19:19   ` [PATCH] Consistent use of IEC 80000-13 " Anthonys Lists

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=wrfjio028nxk.fsf@redhat.com \
    --to=jes.sorensen@redhat.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=marko.hauptvogel@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).