Not sure exactly what the compression factor really means

[David Crouch]

I have a 2 TB volume presented to vSphere and don't understand what the reported compression rate really means

According the the GUI, the compression factor is "This value is the compression factor of the volume (including snapshots).

Compression factor = Pre-compressed space / Post-compressed space."

So - the pre-compressed space is what vSphere reports as used ?

       post-compressed space is what the Nimble GUI shows as  primary used + snapshot used?

if so, then the compression rate should be 1.62 TB / 630 GB which yields ~ 2.7 but the Nimble GUI show 1.31 as the compression factor.

Obviously, I'm missing something here.

---------------------------------

I have a 2 TB volume presented to vSphere 5.1

Virtual Center shows

Capacity : 2 TB

Privisioned Space : 1.62 TB

Free Space : 384 Gb

Nimble GUI shows

Volume Space

Size    2.0 TB

Used 246 GB

Reserve 0

Quota 2.0 TB

Primary Compression 1.31 X

Primary Space Saved 76 Gb

Snapshot Sapce

Used 386 GB

Reserve 409 GB

Quota Unlimited

Backup Compression 1.29x

[wen35]

[EDIT] my previous response to David was incorrect - thanks to my colleagues @ Nimble for educating me on the math

calculation for space saving should be:

1.31X compression is  1 - (1/1.31) = .24 or 24% savings 

2.x compression = 1 - (1/2.0) = 0.5 or 50% savings

[jliu79]

What I found interesting is the GUI shows the primary compression and backup compression in different way: It shows me 23% for primary compression and 1.67X for backup compression.

[wen35]

Jason, i believe you meant 1.23 compression ratio for primary & 1.67 for snapshot -- very interesting.  May I ask what workload the volume is serving?  In my VMware environment, I'm seeing similar pattern but the delta is not as much as yours -- my backup saving is ~1.57x vs. 1.42x for primary.

[etang40]

Used space (space after compression) = 246GB

Primary Space Saved = 76GB

246+76GB = 322GB (pre-compression) / 246GB (post-compression) = 1.31X

The bigger question is why the discrepancy between vCenter 1.62TB vs. the reported 322GB of Nimble pre-compression capacity.  I believe much of this has to do with a little publicized feature on Nimble called zero-block unmap introduced in 1.4.  Essentially if the Nimble array detects zero filled blocks, the system will represent that within the filesystem index and not need to go through the process of compressing these blocks and writing that to disk.  Although this is represented as capacity consumed on the vCenter side, the Nimble array will not represent these zero filled blocks as used and is not calculated as part of space saved via compression.  In other words, customers going from 1.3 -> 1.4 may see a decrease in system compression (zero blocks compress really well) but the system capacity used will be the relatively similar with the advantage of being much more efficient about not having to compress\write and vice versa for these zero-filled blocks.

In short, the effective compression ratio i.e. what is reported as space used on the host/what is actually used post-compression on the Nimble array is typically far better than what is reported on primary compression ratio on the Nimble GUI.

Hope this helps.

[jliu79]

The GUI shows the primary compression in percentage:23%, not sure why it's not like 1.23.

The volumes on the array are for Hyper-V(2TB), SQL(3T), Exchange(700G), and File servers(4T).

[james_462]

So if vCenter is reporting the non-compressed size, will vCenter stop you from adding more to the VMFS datastore when it thinks the volume is full?  Are you left with a bunch of unused space on the Volume that vCenter can't/won't use?

[RandyStorage]

Hi Jason,

I believe it is more intuitive to use percentage savings where possible, particularly for modest space savings (e.g. 33% is more intuitive than 1.5x).

We are investigating making the changes on the GUI(switch compression ratios to percentages) to make it more consistent.

-Randy H

[mandersen81]

James,

Yes when VMware thinks the volume is full it will not be able to write any more.  However due to the way we thin provision on the Nimble that saved space is never actually used and therefore doesn't take up any extra space on the Nimble.   The one Exception to that is if you use Volume reserve space and have a 2TB volume with 1.2TB in use on the Nimble, 2.0TB actually used and a Volume Reserve of 2.0 TB on the Nimble you are holding extra space and not able to use that extra 800Gig of data on other volumes. 

Remember that our compression is done at the block level and therefore there is no way for the application layer to know that the data was compressed.  So the application layer only has a volume the size it was originally created.

Matthew