On 2013-1-11 23:56 , Fletcher Cocquyt wrote: [...]

But the numbers on the vendors dashboard were different. I asked vendor support and the next day they confirmed (as I suspected) they were converting using powers of 10 But what I did not know, was this was on purpose due to the disk manufacturer's convention: http://en.wikipedia.org/wiki/Hard_disk_drive#Units

It's worse than that. First, see http://xkcd.com/394/ for more confusion.

And currently, drive manufacturers allow themselves to be about 10% to 20% off in the number of bytes. (so the xkcd comic is probably right about the size of a "marketing KB"). The error, I might add, is never in your advantage. A "1 TByte" drive won't fit 1000^4 bytes. It is actually about 888 * 1000^3 bytes. Or slightly less than 850 GByte (real 1024^3 Byte = 1 Gbytes).

In sizing calculations, I estimate "df" will give me a number that's 46% of the size that the marketing department puts on the bill (including spares, raid overhead, OS overhead and snapshot overhead). In mirrored configurations, it's half that amount (23%).

For someone with a computer science background this was surprising to not have uniform definitions of units across media

I think this old usenet signature describes the IT landscape pretty well: "You're in a twisty maze of standards, all conflicting".

Ram manufacturers don't do this according to the article they use (do Flash or SSD makers?)

Yes, flash sizing has the same "feature". On the other hand, flash drives are really always bigger than advertised because of bad blocks and wear leveling and write (or erase) buffering. But you can't really use that because of the smart controller.

Made me wonder what the Netapp reporting tools, OpsMgr, System Manager, DFM etc do when reporting the #bytes available on a HDD as Tb do they do binary or decimal conversions?

I don't know about those, but I do know all command-line tools, SNMP queries and API calls report "real" power-of-1024 units. So I suspect DFM et al will, too.

What are some other implications of the unit definition difference?

That the 'aggr create' and 'aggr add' commands are irritating when you have a number of different-sized disks available.

"so sysconfig -r says these spares are 418000MB... should I use them as 'aggr create newaggr 16@400g' or '16@450g' or '16@500g' ?"

You have to know what label the marketing department has put on the drives that are in your system, or you have to guess. (The answer: these disks are 450g. 500g would have 423111MB available. Duh!)

And there's more confusion ahead, as the current 3TB drives are really only 2.5TB, but there's a new batch of 3TB drives coming that are supposed to be really 2.9TB (which is revolutionary, because even if that's 2900000 real Mbytes, that would still be 3040870400000 bytes, which is more than advertised!) (but I haven't seen those drives yet).

First...avoid to perform formal error using "b" instead of "B"

You speak about T(era)Byte or T(ibi)Byte and the B must be uppercase. Lorwercase b stands for bit...and this is a really huge difference :)

Last I don't think that, till we'll speak about PB amounts of data, the difference could have a sense: the difference between using base 2 (2^10=1024) coming from the only 2 computer "fingers" (0 and 1) or base 10 (10^3=1000) coming from human being 10 fingers hands.

It's already hard enough to let accounts and customers to understand the difference among raw and usable...

With a smile

;-)

Regards

Da: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] Per conto di Fletcher Cocquyt Inviato: venerdì 11 gennaio 2013 23.56 A: toasters@teaparty.net Lists Oggetto: When is 1Tb == 1000Gb == 1000^2Mb == 1000^3Kb == 1000^4bytes ?

This came up when I was doing some work with our new backup vendor's API, pulling out their backup numbers all reported in bytes and converting to Gb or Tb for our cacti graphs.

set bytes=7696581394432 echo $bytes bytes = `echo $bytes"/1024/1024/1024/1024" | bc` Tb 7696581394432 bytes = 7 Tb

But the numbers on the vendors dashboard were different. I asked vendor support and the next day they confirmed (as I suspected) they were converting using powers of 10 But what I did not know, was this was on purpose due to the disk manufacturer's convention: http://en.wikipedia.org/wiki/Hard_disk_drive#Units

For someone with a computer science background this was surprising to not have uniform definitions of units across media

Ram manufacturers don't do this according to the article they use (do Flash or SSD makers?)

So if I have full 1Tb RAM drive and try to copy it to a 1Tb HDD, it won't fit - I'll need 9.95% more space due to the different definitions of Tb

Made me wonder what the Netapp reporting tools, OpsMgr, System Manager, DFM etc do when reporting the #bytes available on a HDD as Tb do they do binary or decimal conversions?

What are some other implications of the unit definition difference?

thanks