Primary Storage

 View Only
  • 1.  Volume size on a DRP pool

    Posted Fri April 15, 2022 09:37 AM
    Hi,

      On a DRP pool I have a thin volume created with a max size of 500GB.  In order to check its current usage, I'm using the Analyze tool and then I'm downloading the comprestimator report csv file. For this volume , the report shows a thin size of 290GB and a much lower compressed size (160GB).  I first thought that the host didn't sent any unmap requests and the volume was only growing in size so I run a retrim on that host (it's a Windows host so I run 'Optimize-Volume -Retrim').  I then waited for a few days just to be sure that the garbage collector had enough time to run in the background and I checked again the volume actual size from a new comprestimator report.  To my surprise there is the same difference between the thin_size and the compressed_size.  My logic is telling me that the thin_size should be very close to the compressed_size because the volume should grow or shrink depending on the actual data usage. 

      Am I right or am I missing something regarding the DRP behaviour ?

     Thanks.

    ------------------------------
    Adrian Nicolae
    ------------------------------


  • 2.  RE: Volume size on a DRP pool

    Posted Mon April 18, 2022 05:44 AM
    Edited by T Masteen Mon April 18, 2022 05:44 AM
    One of the behaviours of Garbage Collection: 
    The garbage collection process is designed to defer the work as much as possible because the more it is deferred, the higher the chance of only having to move a little valid data from the block to make that block available it to the free pool.

    So maybe in the two days you waited the Garbage Collector did not do that much.

    Keep an eye on the used_capacity_before_reduction value on vdisk level, and reclaimable_space value on mdiskgrp level.

    ------------------------------
    T Masteen
    ------------------------------



  • 3.  RE: Volume size on a DRP pool

    Posted Mon April 18, 2022 09:38 AM
    So I think there may be some confusion between thin and compressed.  Compressed ACTUALLY = thin + compressed.  So if you were to only have a thin (and not compressed) your thin size would be 290GB.  A compressed volume is also thin, so by compressing the data that takes 290GB, you shrink the usage to 160GB.  And you are correct, the usage will go up and down because of host unmap.  Just make sure you have host unmap turned on.  It is off by default.  lssystem |grep unmap will let you see if it is turned on or off.  I hope that helps.

    ------------------------------
    BYRON GROSSNICKLE
    ------------------------------



  • 4.  RE: Volume size on a DRP pool

    Posted Mon April 18, 2022 10:24 AM
    Host unmap is on, the controller in question is part of an older cluster running 8.2.1.11 and on the older sw versions the host_unmap was on by default.  The volume thin size is pretty much the same as last week but the pool usage (the only pool for that controller) is only 34% full so I guess the host unmap requests can still be pending in the gc queue.  On another system running at 80%  I noticed the gc is much faster , it's probably processing  any entry in the gc queue very fast but the CPU usage is also very high.

    ------------------------------
    Adrian Nicolae
    ------------------------------



  • 5.  RE: Volume size on a DRP pool

    Posted Mon April 18, 2022 10:40 AM
    Yes, garbage collection is a very lazy protocol.  And the reason for that is that if it waits longer, it is likely to have less work to do (more extents totally invalid) because it doesn't have to move as much stuff around.  So if your pool is not very full, the garbage collection routines will work very little.  As the pool fills up the garbage collection routines will work harder. At the point that the pool is 85% full (or more) the garbage collection routines will be working at their maximum speed to try to keep new space available for writes to occur.

    ------------------------------
    BYRON GROSSNICKLE
    ------------------------------