Tricky- 3PAR Disk usable capacity formula

[deepak.3a]

Hi Team
As its all aware that 3PAR is showing space in GiB not in GB, but still not able to get the information that how the total capacity of a physical drive is calculated?
When look at 900GB drive then total capacity shown in 3PAR GUI is 819GiB.
But if I calculate the same from below portal then it shows space as 838GiB against a disk of 900GB. Any correction from which is needed or any clues please?

http://wintelguy.com/gb2gib.html

[RitonLaBevue]

Well...
Did you ever have a look to the hard disk in your laptop or desktop ? The same...
The market name for those SAS drive is 900GB.
The only thing you must know is that 900GB drive got 819 chunklets.

[Richard Siemers]

System Reporter gives you the option to report either GB or GiB. However, your question is about why do we only get 819 GiB usable from a 838 GiB drive.

My best guess is that 838 GiB is the RAW capacity of the drive that is available to the Inserv OS, and that 819 GiB is what is available to you after Inserv has initialized(formatted) the drive. You should be able to see that 819 GiB yields 819 chunklets with "showpd -c".

I *know* that each PD has 5 hidden chunklets of its very own spare space for media errors. A PD will not fail until all 5 of these hidden spares are consumed, at which time it will kick over to using system spare space on other PDs that can be viewed with the showspare, or showpdch commands. I used to have a undocumented option for a show command that would show these, but I have lost my notes!

5 spares only accounts for 5 of the 19 missing GiB. Perhaps one of our residents HP gurus can help shed some light on the overhead and missing command =)

[deepak.3a]

Hi Richard, thanks for the reply and clarifying the things. Still if we look at space that 19 GiB is missed from the 900GB drive. Because we are getting 819GiB instead of 838GiB, so loosing 19GiB each drive is a huge space when the no. of drive increase.
I hope this should be applicable for all the disk type. But issue comes more complex when I look at all drive type in my system :

900GB SAS drive gives 819 Chunklets (While it should give 838 chunklets)
200GB SSD drive gives 185 chunklets (It should give 186 chunklets)
3TB NL disk gives 2708 chunklets (It should give 2793 chunklets)

So on SAS I am missing 19 chunklets, On SSD only 1 is missing, and on NL drive it is missing 85 chunklets.

Id CagePos Type State Total OK Fail Free Uninit Unavail Fail OK Fail Free Uninit Fail
0 0:0:0 SSD normal 185 68 0 107 0 0 0 0 0 10 0 0
4 0:4:0 FC normal 819 468 0 314 0 0 0 0 0 37 0 0
16 2:0:0 NL normal 2708 2203 0 505 0 0 0 0 0 0 0 0

[Cleanur]

Try (900GB /1024/1024/1024/1024) * 1000,000,000,000 = 818GB

Even then the system reserves a small amount of space per drive for internal metadata such as the TOC and low level protection such as logging space etc which you won't typically be able to see, so don't worry about what amounts to a rounding error. It's being put to good use to protect the system and maintain performance during failures.

[Richard Siemers]

Try (900GB /1024/1024/1024/1024) * 1000,000,000,000 = 818GB

What math sorcery is this?

900 GB * 1,000,000,000 = 900,000,000,000 bytes.
900,000,000,000 bytes / 1024 = 878,906,250 KiB
878,906,250 KiB / 1024 = 858,306 MiB
858,306 MiB / 1024 = 838 GiB
838 GiB / 1024 = 0.818 TiB

[Richard Siemers]

At first glance I thought Cleanur had the math, and we blatantly miscalculated... however, Cleanur's explanation goes one level too deep, to reach that 818/819 number.

I have been hunting on my systems for drives with 1 or 2 failed chunk lets, and it appears things have changed somewhere between 3.12 and 2.40. I can no longer "see" moved or relocated chunklet information for media failures. I can still see failed chunks on a disk, no more than 5, and the # of failed chunks has no impact on the # of free spare chunks... it appears that instead of reserving 5 chunks for media failures, they just put those in the free pool now, and use chunks out of the free pool for media failures.