Why don't I have more free space available

SUMMARY

Using smgr_display to investigate disk utilization concerns.

ISSUE

Why don't I have more free space?

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?

For more information on "Out of Space" conditions see Unitrends KB 5046 - Error: No more space on device

RESOLUTION

Run smgr_display, which will display output similar to the following. To return to the command prompt, press "ESC":

  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     342438.503906       166348.799999         0                Yes                      No

In this example, the DPU currently has 342438.503906 of real time free space, and the landing zone is only at 166348.799999.

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.

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).

Immediately the following took place:

root 24408 2.0 0.0 185964 4240 ? SN 07:23 0:00 /usr/bp/bin/space_reclaimer D2DBackups 211200.000000

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.

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.

Your DPU is now showing free space of 1304682.217773 MB. It is operating normal and its behavior is what you should expect.

CAUSE

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.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Contact us