8 Replies Latest reply: Dec 5, 2013 7:35 PM by Matthew Andersen RSS

    Not sure exactly what the compression factor really means

    David Crouch Newbie

      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





        • Re: Not sure exactly what the compression factor really means

          [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

          • Re: Not sure exactly what the compression factor really means
            Eddie Tang Adventurer

            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.

            • Re: Not sure exactly what the compression factor really means
              James Owens Newbie

              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?

                • Re: Not sure exactly what the compression factor really means
                  Matthew Andersen Adventurer


                  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.