Will Kibibytes catch-on or can we turn things back to the JEDEC standard?

[hamster_nz]

Just to share my pain - customer asks for 250GB disk. I provision 258 GB within the SAN. VMware sees it as 240 GB. I then go back and provision 268 GB.

Then the problem is what do we bill the customer.. sigh!

[Monkeh]

Just to share my pain - customer asks for 250GB disk. I provision 258 GB within the SAN. VMware sees it as 240 GB. I then go back and provision 268 GB.

Then the problem is what do we bill the customer.. sigh!

You bill them for 250GiB and tell VMWare to fix their crap.

[SirNick]

Yeah, something's not adding up.  258 * 1,000,000 = 246 * 1024 * 1024.  So either some of the volume size is being reserved elsewhere (by the SAN?) or VMware is screwing up the calculation.  How big does the OS say that LUN is?

(Also, what SAN do you use?  Just curious.)

[Monkeh]

Yeah, something's not adding up.  258 * 1,000,000 = 246 * 1024 * 1024.  So either some of the volume size is being reserved elsewhere (by the SAN?) or VMware is screwing up the calculation.

VMWare's not the one screwing up the calculation. It's just using the wrong prefix. 258GB is 240GiB, give or take.

[SirNick]

Doh.   I seemed to have misplaced a few zeroes.

[hamster_nz]

(Also, what SAN do you use?  Just curious.)

This SAN is based on Cisco MDS switching (I've got a few I look after), and has storage from a few different vendors on it - in this case the storage is an IBM XIV Gen2 (http://en.wikipedia.org/wiki/IBM_XIV_Storage_System).

[timb]

You know, I always thought hard drive sizes being in b10 made sense, as there's nothing inherent to a mechanical disk which makes it have to store data the way memory does.

So, I think it makes a lot of sense to have the *ibi prefix to denote b2 measurements. It makes things a lot clearer. What's the harm?

Quit being so adverse to change, you old codgers.


Sent from my Smartphone

[hamster_nz]

You know, I always thought hard drive sizes being in b10 made sense, as there's nothing inherent to a mechanical disk which makes it have to store data the way memory does.

Except 512 byte or 4096 byte sectors - which is important for memory-mapped I/O and virtual memory. 

However, at a basic level even that is flexible. On IBM AIX systems you have to reformat disks from 512 bytes/sector to 522 bytes per sector before you can use them with some hardware RAID controllers.

And in the distant past there were 80 column and 96 column punch cards...

[miguelvp]

And in the distant past there were 80 column and 96 column punch cards...

I still have around 3 unused 80 column ones that I used as book place holders

[rs20]

yes because it defies logic;  so what are the benefits of adding a new set of SI units as opposed to making the hard disk manufacturers simply print a correct label?  Which in my case for the drive sat on my desk should just read 465.7 GB and not 500 GB.

The status quo is that whenever you see MB, you have to infer from context what that actually means. With the introduction of this new set of prefixes, writers have the new option of MiB to unambiguously state a power-of-two size, if that makes sense. In many cases (not just HDD manufacturers, but data bandwidths, 100Mbps ethernet, 1 Gbps ethernet, all of the posts in this thread demonstrating miscommunications with customers, I mean come on you're not so naive to think it's only HDD manufacturers using the SI unit correctly), the MB unit will still be used, and this is just fine, because often the decimal prefix makes more sense. Just like before, you have to infer from context what MB means. Let me put it this way:

Before IEC: See MB, infer meaning from context.
After IEC: See MB less often, infer meaning from context. Sometimes, you'l see MiB, and you'll instantly unambiguously understand what's meant.

As a reader, you go through the same process as before, except you can short-circuit your judgement if you see MiB. This is faster, unambiguous, less error-prone. Perfectly logical. Oh no, MB still requires knowledge of context to understand. Guess what? Unless someone's going to go through every PDF on the internet, and check and modify it, that's never going to change. MB is broken forever. Saying that MiB doesn't fix MB is a strawman argument, because no-one is saying that it does. All we're saying is that now that MiB is available, things are better. Understand it when you read it, feel free to use it as appropriate when writing unless you want to be deliberately perverse.

The difference is, an inch would still be an inch, not "supposedly an inch but maybe a cm".

A MB is already "maybe 1000000 bytes, maybe 1048576 bytes". MiB doesn't fix that, sure, but it isn't the cause of the problem. Focus on what's new, rather than saying the status quo is broken (Which I agree with).

That's why, when I need a precise number, I leave off the postfix, and state the real number.  The only time the value is still precise with a SI postfix is when it's a perfect multiple (1.0M), or you specify the value out to the required number of decimal places (32.768k).  If you have to specify more than two or three decimals, you probably shouldn't be shifting scales that lose precision.

But, there are ample times when I need to convey the general quantity of something -- like a 10k resistor, for example.  We understand it may not (and probably won't be) 10,000.000 ohms.  It has a tolerance, also specified if it matters, and we all agree to accept any error one way or the other.  And, we also understand that a 5% error on a 100R resistor is closer to the actual value than 5% on a 1M resistor.  Yet, no one is proposing new units for resistors...

I don't get why you're talking about decimal places and significant figures. Tolerances are completely irrelevant here because hard drives have a precise number of bits. Why would the fact that resistors have a tolerance of 5% suggest the need for different units? I just can't make any sense of what you're saying here. Shifting scales do not lose precision, 12.7642pF is precisely 0.0000000000127642 farads. Leaving off the postfix does not help with gaining precision. 32KiB = 32.768kB = 32768B. I'm not going to write 2000000000 bytes instead of 2GB if I meant precisely 2GB.

I'm not terribly upset about it being "wrong" now, I just find it unhelpful to say there's now an unambiguous unit for 2^x, but the 10^x unit is still just as ambiguous as ever -- except now, it's "supposed to be" accurate too.  The only way you'd know for sure is if someone left a footnote saying "actual MB, not MiB" -- and if it mattered either way, why not footnote with "MB = 1,000,000" as we're doing now?  In most scenarios, "MB = ~1 million" is good enough, so... as I said... it's a non-fix for a non-problem.

As I mentioned above, you're right that expecting MB to mean 1000000 bytes is unreasonable. A simple footnote or note in the introduction will make it so, but as you say, for all historical documents, you need to use your judgement and infer what's meant from context. This is the same, before and after the introduction of MiB. But the introduction of MiB as another option is a great tool for clarity for writers, a boon to readers when they encounter it, and a definite step in the right direction. That's all I'm saying.

[SirNick]

I don't get why you're talking about decimal places and significant figures. Tolerances are completely irrelevant here because hard drives have a precise number of bits. Why would the fact that resistors have a tolerance of 5% suggest the need for different units? I just can't make any sense of what you're saying here. Shifting scales do not lose precision, 12.7642pF is precisely 0.0000000000127642 farads. Leaving off the postfix does not help with gaining precision. 32KiB = 32.768kB = 32768B. I'm not going to write 2000000000 bytes instead of 2GB if I meant precisely 2GB.

I'm talking about it because most (but yes, not all) of the time, when a postfix is warranted, the "tolerance" of the number you're trying to express makes the difference unimportant.  When you have to go out several decimal places to convey the significant value, you're defeating the point of using a postfix with high magnitude.  0.001M = 1k.  Why not just write 1k then?  If you need to know if that's 1.001k or 1.000k, why not just say 1000?  That way, there's no assumption required.  Is 1k a precise figure, or a ballpark figure?  Well, 1000 leaves no question.  (Unless of course 0.001 matters, in which case you might need to say 1000.000.)

The gist is this:  I just bought a few 3TB HDDs for my NAS.  It doesn't matter at all if that's 3,000,000,000,000 bytes even, or not.  (Hope I counted zeroes correctly this time.)  3TB == in the rough neighborhood of 1 buttload of data.  They're replacing a batch of 2TB HDDs, which were also roughly 1 buttload of data, but 3TB is something near 50% more of a partial buttload, and that's all I need to know.

Another example:  I often have device firmware images on Compact Flash cards.  If I made an image of one... say, 1GB card... I would not expect it to fit precisely on another 1GB card, unless they were the same part number from the same manufacturer.  This has turned out to be the case as often as not.  I honestly don't know if it was 1GiB vs. 1GB, or if it was just a difference in spare sectors, or what.  Doesn't matter.  The takeaway is that I have to check, and when they don't match, I have to either ensure the target is larger, or resize the filesystem to fit.  Either way, I check the real size in number of 512 byte sectors, or Bytes.  That has never left me confused.

In the case of the SAN guy carving out storage for a customer, there you probably need to say "we sell in increments of 1GB, where GB = 1 billion bytes".  The customer can decide if the accuracy is relevant to their needs, but most people won't care either way.  They'll ask for some arbitrary round number of GB and call it a day.  When I managed SANs, and needed to know precisely how much space was allocated, I would change the unit-of-measure to bytes, or at least kB.  Only time that really made a difference was to clone a disk of a certain size.  Having exactly equal byte counts made it possible to image the volume rather than do filesystem-level copies.  Every other time, nobody cares.

As I mentioned above, you're right that expecting MB to mean 1000000 bytes is unreasonable. A simple footnote or note in the introduction will make it so, but as you say, for all historical documents, you need to use your judgement and infer what's meant from context. This is the same, before and after the introduction of MiB. But the introduction of MiB as another option is a great tool for clarity for writers, a boon to readers when they encounter it, and a definite step in the right direction. That's all I'm saying.

I do see what you're saying, and I get it.  I just don't agree on the importance.  Having two slightly different units of measure only helps in relatively rare cases.  The rest of the time it's pedantic and doesn't convey information that's useful to the reader.  I assume you disagree with that, and that's fine.  *iB is here now.  Some will use it, some won't.  I'll probably continue to specify in (e.g.) MB when the exact figure is unimportant, and specify either "MB=1,000,000" or in Bytes when it is.  Either way, the point comes across clearly, which is all that matters.

[David Hess]

You know, I always thought hard drive sizes being in b10 made sense, as there's nothing inherent to a mechanical disk which makes it have to store data the way memory does.

Except 512 byte or 4096 byte sectors - which is important for memory-mapped I/O and virtual memory. 

Or 2048 byte sectors for some optical media.

However, at a basic level even that is flexible. On IBM AIX systems you have to reformat disks from 512 bytes/sector to 522 bytes per sector before you can use them with some hardware RAID controllers.

I forget exactly what the extra bytes were used for but wasn't the data size as far as the application was concerned still some multiple of 2?

NAND Flash memory uses writable sector sizes slightly larger than the power of 2 number to store ECC and meta information like for remapping.

[David Hess]

Well, that's interesting. When did HDDs transition from MB² to MB¹⁰?

Connor Peripherals and Micropolis were still around.  When the change started happening it was discussed in various computer magazines like Byte.