From: Jes Sorensen <Jes.Sorensen@redhat.com>
To: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: [PATCH v2] Consistent use of metric prefix in manpage
Date: Fri, 01 Apr 2016 16:11:07 -0400 [thread overview]
Message-ID: <wrfjfuv53x9g.fsf@redhat.com> (raw)
In-Reply-To: <56FDA301.1080304@googlemail.com> (Marko Hauptvogel's message of "Fri, 1 Apr 2016 00:21:53 +0200")
Marko Hauptvogel <marko.hauptvogel@googlemail.com> writes:
> On 31.03.2016 21:09, Jes Sorensen wrote:
>> 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
>>
>
> I am fine either way, but it should be used consistently throughout
> the man page. The mix up was what made me cringe.
Works for me!
Cheers,
Jes
>
> Greetings
>
> --------
>
> From eaad00be960ff1d60861cba75cc7e5eb07f7e330 Mon Sep 17 00:00:00 2001
> From: Marko Hauptvogel <marko.hauptvogel@googlemail.com>
> Date: Fri, 1 Apr 2016 00:13:44 +0200
> Subject: [PATCH] Consistent use of metric prefix in manpage
>
> 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>
> ---
> mdadm.8.in | 15 ++++++++-------
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/mdadm.8.in b/mdadm.8.in
> index 50be1aa..1a04bd1 100644
> --- a/mdadm.8.in
> +++ b/mdadm.8.in
> @@ -459,7 +459,7 @@ number of spare devices.
>
> .TP
> .BR \-z ", " \-\-size=
> -Amount (in Kibibytes) of space to use from each drive in RAID levels 1/4/5/6.
> +Amount (in Kilobytes) of space to use from each drive in RAID levels 1/4/5/6.
> This must be a multiple of the chunk size, and must leave about 128Kb
> of space at the end of the drive for the RAID superblock.
> If this is not specified
> @@ -467,7 +467,7 @@ 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
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kilobytes, Megabytes or
> Gigabytes respectively.
>
> Sometimes a replacement drive can be a little smaller than the
> @@ -534,7 +534,7 @@ 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
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kilobytes, Megabytes or
> Gigabytes respectively.
> A value of
> .B max
> @@ -543,7 +543,7 @@ amount of available space is.
>
> .TP
> .BR \-c ", " \-\-chunk=
> -Specify chunk size of kibibytes. The default when creating an
> +Specify chunk size of kilobytes. The default when creating an
> array is 512KB. To ensure compatibility with earlier versions, the
> default when building an array with no persistent metadata is 64KB.
> This is only meaningful for RAID0, RAID4, RAID5, RAID6, and RAID10.
> @@ -551,7 +551,7 @@ 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
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kilobytes, Megabytes or
> Gigabytes respectively.
>
> .TP
> @@ -737,7 +737,7 @@ 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
> +A suffix of 'K', 'M' or 'G' can be given to indicate Kilobytes, Megabytes or
> Gigabytes respectively.
>
> .TP
> @@ -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 Kilobytes unless a suffix of 'K', 'M' or 'G' is used to explicitly
> +indicate Kilobytes, Megabytes or Gigabytes respectively.
>
> Since Linux 3.4,
> .B \-\-data\-offset
next prev parent reply other threads:[~2016-04-01 20:11 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
2016-03-31 22:21 ` [PATCH v2] Consistent use of metric " Marko Hauptvogel
2016-04-01 20:11 ` Jes Sorensen [this message]
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=wrfjfuv53x9g.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).