- Reference: NetApp Forum
- Reference: Storage Gaga
NetApp, ever since the beginning, has been subjected to the scrutiny of the customers and competitors alike about their usable capacity and I intend to correct this misconception. And the key of this misconception is to understand what is the capacity before rightsizing (BR) and after rightsizing (AR).
(Note: Rightsizing in the NetApp world is well documented and widely accepted with different views. It is part of how WAFL uses the disks but one has to be aware that not many other storage vendors publish their rightsizing process, if any)
Before Rightsizing (BR)First of all, we have to know that there are 2 systems when it comes to system of unit prefixes. These 2 systems can be easily said as
- Base-10 (decimal) – fit for human understanding
- Base-2 (binary) – fit for computer understanding
In computer context, where the binary, Base-2 system is relevant, that SI prefixes for Base-2 are
And we must know that the storage capacity is in Base-2 rather than in Base-10. Computers are not humans.
With that in mind, the next issue are the disk manufacturers. We should have an axe to grind with them for misrepresenting the actual capacity. When they say their HDD is 1TB, they are using the Base-10 system i.e. 1TB = 1,000,000,000,000 bytes. THIS IS WRONG!
Let’s see how that 1TB works out to be in Gigabytes in the Base-2 system:
1,000,000,000/1,073,741,824 = 931.3225746154785 Gigabytes
Note: 2^30 = 1,073,741,824
That result of 1TB, when rounded, is only about 931GB! So, the disk manufacturers aren’t exactly giving you what they have advertised.
Thirdly, and also the most important factor in the BR (Before Rightsizing) phase is how WAFL handles the actual capacity before the disk is produced to WAFL/ONTAP operations. Note that this is all done before all the logical structures of aggregates, volumes and LUNs are created.
In this third point, WAFL formats the actual disks (just like NTFS formats new disks) and this reduces the usable capacity even further. As a starting point, WAFL uses 4K (4,096 bytes) per block.
Note: It appears that the 4K block size is not the issue, it's the checksum that is the problem.
For Fibre Channel disks, WAFL then formats these blocks as 520 bytes per sector. Therefore, for each block, 8 sectors (520 x 8 = 4160 bytes) fill 1 x 4K block, leaving a remainder of 64 bytes (4,160 – 4,096 = 64 bytes). This additional 64 bytes per block is used as a checksum and is not displayed by WAFL or ONTAP and not accounted for in its usable capacity, therefore the capacity seen by users is further reduced.
512 bytes per sector are used for formatting SATA/SAS disks and it consumes 9 sectors (9 x 512 = 4,608 bytes). 8 sectors will be used for WAFL’s 4K per block (4,096/512 = 8 sectors), while the 9th sector (512 bytes) is used partially for its 64 bytes checksum. As with the Fibre Channel disks, the unused 448 bytes (512 – 64 = 448 bytes) in the 9th sector is not displayed and not part of the usable capacity of WAFL and ONTAP.
And WAFL also compensates for the ever-so-slightly irregularities of the hard disk drives even though they are labelled with similar marketing capacities. That is to say that 1TB from Seagate and 1TB from Hitachi will be different in terms actual capacity. In fact, 1TB Seagate HDD with firmware 1.0a (for ease of clarification) and 1TB Seagate HDD with firmware 1.0b (note ‘a’ and ‘b’) could be different in actual capacity even when both are shipped with a 1.0TB marketing capacity label.
So, with all these things in mind, WAFL does what it needs to do – Right Size – to ensure that nothing get screwed up when WAFL uses the HDDs in its aggregates and volumes. All for the right reason – Data Integrity – but often criticized for their “wrongdoing”. Think of WAFL as your vigilante superhero, wanted by the law for doing good for the people.
In the end, what you are likely to get Before Rightsizing (BR) from NetApp for each particular disk capacity would be:
* The size of 34.5GB was for the Fibre Channel Zone Checksum mechanism employed prior to ONTAP version 6.5 of 512 bytes per sector. After ONTAP 6.5, block checksum of 520 bytes per sector was employed for greater data integrity protection and resiliency.
From the table, the percentage of “lost” capacity is shown and to the uninformed, this could look significant. But since the percentage value is relative to the Manufacturer’s Marketing Capacity, this is highly inaccurate. Therefore, competitors should not use these figures as FUD and NetApp should use these as a way to properly inform their customers.
- Reference: NetApp
RAID & Right Sizing
See Part 3 for information on RAID & Right Sizing.
Other Posts in this Series:
- NetApp From the Ground Up - Part 1
- NetApp From the Ground Up - Part 2
- NetApp From the Ground Up - Part 3
- NetApp From the Ground Up - Part 4
- NetApp From the Ground Up - Part 5
- NetApp From the Ground Up - Part 6
- NetApp From the Ground Up - Part 7
- NetApp From the Ground Up - Part 8
- NetApp From the Ground Up - Part 9
- NetApp From the Ground Up - Part 10
- NetApp From the Ground Up - Part 11
- NetApp From the Ground Up - Part 12
Note: This website is my personal blog. The opinions expressed in this blog are my own and not those of my employer.