When dealing in storage space/capacity numbers, there are generally two ways of representing the numbers – base 2 (binary) and base 10 (decimal/metric). Originally, space was all done in base 2. But, over the years, decimal has crept in to the storage representation – probably due to easier math. After all, it’s easier/quicker to multiply by 1000 than by 1024.
What that has done, however, is introduce some confusion, as not all storage vendors follow the same standards when reporting capacity. Seagate has an excellent knowledge base article on this here:
Gebi, Tebi, Pebi
In an attempt to alleviate the confusion, a new measurement name was created that isn’t widely adopted. Most people still refer to everything as MB, GB, TB, etc. But that’s all base 10. Base 2 uses a little “i” in the abbreviation, so we get MiB, GiB, TiB, etc. That is intended to represent a capacity measured in 1024 vs. 1000. It gets even more fun when you consider the “b” vs. “B” to mean byte versus bit, but I digress.
This handy table on the wiki entry for Tebibyte shows how the math works for decimal vs. binary in storage terms.
What happens when you use decimal vs. binary to measure storage? Well, it can mean that what you thought was 316GB of storage is really only 288GiB – depending on how the vendor has decided to display it.
What does this mean for ONTAP?
So, some vendors use decimal because it reports more space available. Microsoft actually has a statement on this here:
Although the International Electronic Commission established the term kibibyte for 1024 bytes, with the abbreviation KiB, Windows Explorer continues to use the abbreviation KB. Why doesn’t Explorer get with the program?
Because nobody else is on the program either.
If you look around you, you’ll find that nobody (to within experimental error) uses the terms kibibyte and KiB. When you buy computer memory, the amount is specified in megabytes and gigabytes, not mebibytes and gibibytes. The storage capacity printed on your blank CD is indicated in megabytes. Every document on the Internet (to within experimental error) which talks about memory and storage uses the terms kilobyte/KB, megabyte/MB, gigabyte/GB, etc. You have to go out of your way to find people who use the terms kibibyte/KiB, mebibyte/MiB, gibibyte/GiB, etc.
In other words, the entire computing industry has ignored the guidance of the IEC.
NetApp ONTAP uses binary because it’s closer to what is accurate with regards to how computers operate. However, ONTAP, while showing the correct *numbers* (in decimal) doesn’t show the correct *units*. ONTAP shows, by default, GB, TB, etc. Bug 1078123 covers this.
For example, my Tech ONTAP Podcast FlexGroup volume is 10TB:
cluster::*> vol show -fields size -vserver DEMO -volume Tech_ONTAP vserver volume size ------- ---------- ---- DEMO Tech_ONTAP 10TB
OR IS IT???
cluster::*> df /vol/Tech_ONTAP Filesystem kbytes used avail capacity Mounted on Vserver /vol/Tech_ONTAP/ 10200547328 58865160 10141682168 0% /techontap DEMO /vol/Tech_ONTAP/.snapshot 536870912 466168 536404744 0% /techontap/.snapshot DEMO
If we use TB to mean base 10, then 10200547328 + 536870912 (10737418240) kbytes is actually 10.737TB! If we use base 2, then yes, it’s 10TB.
There is a way to change the unit displayed to “raw,” but that basically just shows the giant number you’d see with “df.” If you’re interested:
cluster::> set -units auto raw B KB MB GB TB PB
Why should you care?
Ultimately, you probably don’t care. But it’s good to know when you’re trying to figure out where that extra X number of GB went, as well as how much capacity you’re buying up front. And it’s a good idea to make it a best practice to ask *every* vendor how they measure capacity, so they don’t try to shortchange you.