All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Smart <James.Smart@Emulex.Com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Simon Arlott <simon@fire.lp0.eu>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-scsi <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH] scsi/sd: Fix size output in MB
Date: Sun, 31 Aug 2008 08:27:43 -0400	[thread overview]
Message-ID: <48BA8E3F.9080205@emulex.com> (raw)
In-Reply-To: <20080830215714.GE1239@parisc-linux.org>

Matthew Wilcox wrote:
> Reasonable minds can certainly disagree on this one.  I respectfully
> submit that reporting a 97415MB capacity is less useful than reporting a
> 97GB capacity.  If you look at drive advertisements, they sell 1TB,
> 1.5TB, 80GB, 750GB, 360GB, ... we should be trying to match that.  I'm a
> little dubious about trying to match the 1.5TB; I think 1500GB is close
> enough, but a 50GB drive shouldn't be reported as 50000MB.  IMO, anyway.

Since when did techies start paying attention to marketing statements ?

We should be doing what's natural and *consistent*, which is typically 
dealing with power-of-2. Saying it's one thing at one level, and when 
the natural use (how many 512 byte sectors get added up later) changes 
that number in a different level, you've created even more confusion. 
There's no consistency.

As far as user concern - they've seen this discrepancy in the PC/Windows 
world for years now...  Why should we be taking on the task to solve or 
answer it now ?  Throw in different overheads for filesystem metadata 
loss, volume manager metadata, raid level loss, etc - you'll never be 
able to explain it all to the user.  And personally, I'd rather have 
natural numbers so that if I do understand the uses, I can do 
calculations without doing number-base conversions.

-- james s



      parent reply	other threads:[~2008-08-31 12:28 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-30 14:08 [PATCH] scsi/sd: Fix size output in MB Simon Arlott
2008-08-30 17:24 ` James Bottomley
2008-08-30 17:45   ` Matthew Wilcox
2008-08-30 20:59     ` Pierre Ossman
2008-08-30 21:45       ` James Bottomley
2008-08-30 22:13         ` Pierre Ossman
2008-08-30 22:24           ` Simon Arlott
2008-08-30 22:36           ` Matthew Wilcox
2008-08-30 21:02     ` Simon Arlott
2008-08-30 21:03       ` [PATCH] scsi/sd: Fix capacity output to show MB/GB/TB/ Simon Arlott
2008-08-31  1:59         ` James Bottomley
2008-08-31  2:54           ` Matthew Wilcox
2008-08-31 14:25             ` Ingo Oeser
2008-08-31 15:04               ` Simon Arlott
2008-08-31 15:08             ` James Bottomley
2008-08-31 15:13               ` [PATCH 1/2] lib: add generic helper to print sizes rounded to the correct SI range James Bottomley
2008-08-31 15:20                 ` Simon Arlott
2008-08-31 15:41                   ` James Bottomley
2008-08-31 15:51                 ` Matthew Wilcox
2008-08-31 18:54                 ` [PATCH] mmc_block: use generic helper to print capacities Pierre Ossman
2008-09-05 20:09                   ` James Bottomley
2008-09-05 20:52                     ` Pierre Ossman
2008-09-05 21:03                       ` James Bottomley
2008-09-06  8:57                         ` Pierre Ossman
2008-09-03  3:39                 ` [PATCH 1/2] lib: add generic helper to print sizes rounded to the correct SI range Andrew Morton
2008-09-03 14:32                   ` James Bottomley
2008-09-03 15:58                     ` Andrew Morton
2008-08-31 15:15               ` [PATCH 2/2] sd: use generic helper to print capacities in both binary and SI James Bottomley
2008-08-31 15:08           ` [PATCH] scsi/sd: Fix capacity output to show MB/GB/TB/ Simon Arlott
2008-08-30 21:57       ` [PATCH] scsi/sd: Fix size output in MB Matthew Wilcox
2008-08-30 22:22         ` Simon Arlott
2008-08-31 12:27         ` James Smart [this message]

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=48BA8E3F.9080205@emulex.com \
    --to=james.smart@emulex.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=simon@fire.lp0.eu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.