Ask the Community
Groups
Why don't I have more free space available - Connect IT Community | Kaseya
<main> <article class="userContent"> <h2 data-id="summary"><strong>SUMMARY</strong></h2> <p>Using smgr_display to investigate disk utilization concerns.</p> <h2 data-id="issue"><strong>ISSUE</strong></h2> <p>Why don't I have more free space?<br><br>I'm only using 1.8TB of licensed space, so how is the other 1.5TB getting used? Now that replications have occurred and new backups have been grabbed, shouldn't that overhead space be getting freed up?<br><br>For more information on "Out of Space" conditions see <a rel="nofollow" href="/home/leaving?allowTrusted=1&target=https%3A%2F%2Funitrends-support.zendesk.com%2Fhc%2Fen-us%2Farticles%2F360013172657">Unitrends KB 5046 - Error: No more space on device</a></p> <h2 data-id="resolution"><strong>RESOLUTION</strong></h2> <p>Run smgr_display, which will display output similar to the following. To return to the command prompt, press "ESC": </p> <pre class="code codeBlock" spellcheck="false" tabindex="0"> SMGR: RESERVATION(s) Press [Esc] TO EXIT ------------------------------------------------------------------------------------------------------------- INDEX KEY D2D DEVICE RESERVATION(Bytes) AVAIL(Bytes) TIME ------------------------------------------------------------------------------------------------------------- 3 5475910 D2DBackups/1 68719476736 0 Tue Apr 26 16:44:21 2016 SMGR: LANDING ZONE(s) ---------------------------------------------------------------------------------------------------------------------------- INDEX D2D DEVICE FREE-SPACE(Mbs) LANDING ZONE(Mbs) AVAIL(Bytes) Device Purge Enabled Purger Active ---------------------------------------------------------------------------------------------------------------------------- 0 D2DBackups <b>342438.503906</b> <b>166348.799999</b> 0 Yes No</pre> <p>In this example, the DPU currently has <b>342438.503906</b> of real time free space, and the landing zone is only at <b>166348.799999</b>.<br><br>The DPU does not see a need to clear up free space at this time. We can test this theory by first looking at what services were running. If space_reclaimer is not running, the system believes there is no need to free up space.<br><br>Changing the Storage Allocation setting for Instant Recovery from 2GB to 305GB will cause free space to drop to less than the landing zone, but will leave a value greater than 32GB (minimum value needed to allow space reclaimer to work. If using Inline Deduplication, the minimum is 64GB).<br><br>Immediately the following took place:</p> <pre class="code codeBlock" spellcheck="false" tabindex="0"> root 24408 2.0 0.0 185964 4240 ? SN 07:23 0:00 /usr/bp/bin/space_reclaimer D2DBackups 211200.000000</pre> <p>Additional events may take place as the space_reclaimer job runs. The results of the space_reclaimer job is new free space of 994410.218750 MB.<br><br>Change the Storage Allocation setting for Instant Recovery back to the default 2GB, which will return 303GB back to Backups/Replication. This produces a total free space of 1304682.217773 MB.<br><br>Your DPU is now showing free space of 1304682.217773 MB. It is operating normal and its behavior is what you should expect.</p> <h2 data-id="cause"><strong>CAUSE</strong></h2> <p></p> <p>This is normal activity for the purging process. The RecoveryOS predicts normal activity for the next 24 hours. If you run a job that was not expected, the system will have to make up the difference by deleting the space required. As long as the system has data already marked and prepared for the deletion in advance, the process if fairly fast. But if it has to delete items that are not marked for deletion (such as items that are in purgeable status but not normally purged based on your Min - Max settings), then the deletion process is slower. Ingesting new data under this condition could lead to an out of space condition.</p> </article> </main>