Disk Enclosures
1748140 Members
3468 Online
108758 Solutions
New Discussion юеВ

EVA4/6/8 SUM of vdisks does not match occupancy

 
SOLVED
Go to solution
Rick vonR
Advisor

EVA4/6/8 SUM of vdisks does not match occupancy

I have several EVAs and the result is the same on all but I will use the 4000 for simplicity.
CVEVA=v8.02, XCS=6.200, SSSU=8.0
We have one disk group of 56*300G drives (i.e. a full EVA4000). CVEVA states that the Total is 15083GB and the Occupancy is 10749GB.
I have been using SSSU to pull information on the vdisks for utilization purposes so that I can graph and keep history on how much space is assigned to each server. I summed the sizes of all of the vdisks and came up with 8551GB. Why does this number not match the occupancy?
All of the vdisks assigned are using RAID5 and the disk group is set for single redundancy.
3 REPLIES 3
Uwe Zessin
Honored Contributor
Solution

Re: EVA4/6/8 SUM of vdisks does not match occupancy

> Occupancy is 10749GB

This is RAW space used.

> all of the vdisks and came up with 8551GB

My guess is that you just added the host-visible space without taking VRAID-5 redundancy into account:

8551*1.25 = 10688.75

Not exactly, as some additional space is used by the EVA internally, but it looks much more realistic, doesn't it?

--

Can you run

ls disk full XML
ls disk_group full XML
ls vdisk full
ls container full XML
ls snapshot full XML
ls dr_group full XML

put it in a .ZIP file and post as an attachment so we can get a better picture?
.
Rick vonR
Advisor

Re: EVA4/6/8 SUM of vdisks does not match occupancy

Thanks Uwe.
You are right. I verified that there is a 0.8 factor for RAID5. The factor for RAID0 is 0.0 and the factor for RAID1 is 0.5.
There is also space reserved for the protection level. "The software algorithm for reserving reconstruction space finds the largest disk in the disk group; doubles its capacity; multiplies the result by 0, 1, or 2 (the selected protection level); and then removes that capacity from free space."
S. Boetticher
Regular Advisor

Re: EVA4/6/8 SUM of vdisks does not match occupancy

just to explain these numbers:
VR0 is of curse 100% capacity
VR1 is 50%, because it's mirrored
VR5 is 80%, because internally the EVA uses 4D1P (4 data "chunks?" plus 1 parity), however different from "classical" arrays these 4D1P are striped accross all HDDs in a Diskgroup (there's more to that, RSS-sets, but to explain the 20%-penalty regardless of the number of Disks used for VR5 the 4D1P is enough ;-)

also there is a 7% "penalty" for the drives smaller than 1TB and around 10% for the 1TB drives, when you compare the Disk-sizes reported from (Windows) Hosts with the VDisk-Sizes in CommandView: reason is that one counts "GB" as 1000*1000*1000 and the other as 1024*1024*1024...