Users of different storage arrays often wonder how much usable capacity they get out of purchased amount of disk shelfs. For sure this is a key metric in ROI and TCO calculations, this information is also essential to implement proper capacity planning. In an ideal world, we would probably purchase usable disk capacity directly from vendor, however we do not live in a ideal world so we need to think while making our storage purchases. In this article we will show, how much usable storage capacity we can get from physical disks with NetApp disk arrays, where are hiding overheads and how to influence these overheads.

As it is typical with a disk arrays, we do not use disks itself, but we create a RAID for data protection. RAID is typically made out of a raid group. Depending on used RAID type we get different level of data protection and different overhead. From theory of information, we imply that to protect data, we need to add some additional informations which can be used for recovery in case of drive failure or silent corruption. NetApp disk arrays offers two different RAID types, RAID4 and RAID-DP.

In both cases, some disk spindles within one raid group are dedicated as parity drives, RAID 4 uses one disk spindle for parity and RAID-DP uses two spindles as parity drives. RAID-DP just adds additional parity drive with differently calculated parity, this is a reason why we can easily change RAID type on NetApp disk arrays by adding or removing parity spindle in a raid group.

Aggregate snapshot reserve

NetApp disk arrays allow you to configure snapshot reserve on aggregate, or volume. Both of these settings are independent on each other and reserves are not shared. So, if you create an aggregate snapshot reserve of 5% and volume reserve of 5%, your overall reserves will be 10% under assumption that your volume is same size as aggregate size. In most cases, snapshot reserve for aggregate is worthless, there is very low probability that you would ever use aggregate snapshot to recover any data, because this snapshot restore operation would roll back in time all volumes on restored aggregate. Unless you are using NetApp Fabric MetroCluster, which uses aggregate level snapshots. I personally recommend to set aggregate snapshot reserve to 0% and also disable aggregate snapshots.

snap reserve -A <aggregate name> 0
aggr options <aggregate name> nosnap on

Volume snapshot reserve

Unlike aggregate level snapshots, volume level snapshots are more commonly used. Snapshots on primary storage are often used as primary way to backup files and to achieve near-zero Recovery Point Objective (RPO). Data from snapshots can be restored either as individual files, or as

However, there are two approaches toward snapshot space management. You can either set snapshot reserve and have some volume space reserved only for snapshots, and if our snapshots size exceeds this reserve, they start eating up our live volume space, or we can set snapshot reserve on volume to zero and eat usable volume space right from beginning.

On every volume there should be enough disk space for files growth. This is usually highly dependent on a volume size, 10% of free space on a volume with 8TB in size will be more than enough, however 30% on volume with size of 5GB might not be sufficient to satisfy unexpected writes to this volume. However in general, we can assume that approximately 10% of volume size should be unallocated for near-future growth.

WAFL checksums

WAFL file-system stores 8B of checksum for every 512B of data. This checksums create overhead of 8/512 = 0,0156 = 1,56%.

Checksums are created for protection against silent corruption, whenever data from disk are read, new checksum is calculated and compared with stored checksum, if two don’t match, RAID parity is used to reconstruct these data. After reconstruction, parity and data are written back to disk and reconstructed data are served to client.

GB to GiB

Disk spindles manufacturers use for quite a while now units, that does not fit well with computer world. As you might know, for man it is typical to work with numeric system of base 10, however computer in most cases use numeric system with base 2. For this reason, we need to recalculate from BASE10 units into BASE2 units to get usable disk space in units used by computers.

overhead = (1-(1000/1024))*100 = 2,35%

Unallocated disk-space within aggregate

To ensure good write performance and allow maintenance tasks, WAFL needs some free disk space. General best practice is to keep 10% of aggregate disk space as a free space to keep good write performance and have disk space for maintenance such as block relocation.

RAID protection

Ever RAID technology have some overhead, repair codes can not be stored in vacuum. In case of RAID 4, for every set of active spindles there is one parity drive. For RAID-DP, for every set of active data disks there are two parity spindles. Group of parity and data disks is called RAID group. In table below, we illustrate how does RAID efficiency/overhead develop with increasing RAID group size. Overhead can be calculated using formula overhead = (1 - ((total amount of spindles - amount of parity spindles)/total amount of spindles)))*100

Maximal size of RAID group depends on used spindle type and used RAID technology. RAID 4 limit can be easily by-passed, however I would recommend to stick with these limits in production environments.

Total overhead

All together overhead is about 36,41% – for a rough estimate how much are you going to get from ordered disk shelfs, recommend to count with 60% of ordered RAW capacity. These numbers can be influenced by other factors, especially if there is no planning in place, you might expand existing aggregates and their RAID groups with disks of different sizes, all additional capacity then goes to waste. Or due to aggregate size limit, you might not be able to create RAID group of enough disk spindles and loose some capacity due to unexpected RAID overhead as well as reduce overall IO performance of such aggregate.

Marek Stopka

Marek Stopka is a Senior Consultant at STOPKA Consulting s.r.o. and his specialities include Business Resilience, Business Continuity, Disaster Recovery and Data Storage.

More Posts - Website