Why does NetApp utilize 1.62 TB from a 2.0 TB disk?

[STEPHENRAIF]

I have 2 NetApp controllers (FAS2040) using NetApp release 8.0.2. We purchased our controllers from NetApp with 2.0 TB disks, but they show up in "Storage->Disks->Manage" as 1.62 TB disks. I pulled a spare and verified that it indeed is a 2.0 TB disk.

I questioned the NetApp contracter who installed our system. He told me that the under-utilization of disk space is intentional and non-configurable, and he said that this feature allows NetApp to work with a variety of disk vendors, whose disk sizes may vary.

Is this true? Does NetApp intentionally under-utilize physical disk space, and is this under-utilization amount non-configurable?

I searched the Internet and could find only this reference: "http://www.vperformance.org/2011/04/netapp-capacity-calculator/" where the author states "Note: 2TB disks will show as 1.62TB disks in Ontap 7.x"

Thanks!

[scottgelb]

Right sizing... ~1655GB is the right size on a 2TB.  This is used for WAFL then also some use for checksum with 512 bytes per sector (For every 9 sectors, 1 sector is used for the checksum, and 8 sectors are available for data)..so every 9th sector is the checksum (doesn't apply to SAS/FC, but SATA only).  FC/SAS write 512 then add 8 byte checksum to each sector since they are 520 bytes per sector...but SATA are 512 so NetApp handles them differently with checksums.

[STEPHENRAIF]

Thanks Scott.

I may need to clarify further: The 1.62 TB that I mentioned is the "Physical" size claimed for the disk at the Storage level, prior to Aggregation in which WAFL and snapshots  further reduce the size ~15%. After aggregation, I get about 1.38 TB of aggregate usable space per 2.0 TB disk. (Ignoring spares and parity disks from the calculation.)

[pascalduk · Accepted solution]

Don't forget that a 2 TB disk is actually around 2.000.000.000.000 bytes, because hdd manufacturers use SI prefixes instead of binary. Ontap uses binary prefixes to display drive capacity, so a 2 TB disk is actually 1862 GiB. That is huge difference!

When you take the already mentioned loss of space for checksums into account (1862 * 8/9 ) the 1655 GB is already fully explained.

[STEPHENRAIF]

Thanks for the unequivocal equations Pascal. As you demonstrated, base-10-to-base-2 conversion followed by checksums explains the storage capacity reduction

2.0e12 B -> 1.82 TB -> 1.62 TB

[scottgelb]

Also for usable take the total data drives then *.995 for aggregate accounting, then if you use the default aggr and volume snap reserve multiply *.95 and *.8 again.

[paulstringfellow]

Scott’s reply is right…. This is a pretty standard “right sizing” for disk vendors…there is also an element of the way the disks are marketed…let’s face it 2Tb rolls of the tongue better than 1.62Tb!

As far as I know all disk vendors do pretty much the same thing…

I learned that pretty early on so I’m always sure that I size my arrays very carefully and that customers are very aware of the right sizing of their storage and have that explained early on, so that you don’t ask questions once you’ve bought and installed!!!

Hope that helps..