 | ||
| Storage Checkpoint space management considerations | ||
|---|---|---|
| Prev | Administering Storage Checkpoints | Next |
Several operations, such as removing or overwriting a file, can fail when a file system containing Storage Checkpoints runs out of space. If the system cannot allocate sufficient space, the operation will fail.
Database applications usually preallocate storage for their files and may not expect a write operation to fail. During user operations such as create or mkdir, if the file system runs out of space, removable Storage Checkpoints are deleted. This ensures that applications can continue without interruptions due to lack of disk space. Non-removable Storage Checkpoints are not automatically removed under such ENOSPC conditions. Symantec recommends that you create only removable Storage Checkpoints. However, during certain administrative operations, such as using the fsadm command and creating a Storage Checkpoint with the fsckptadm command, even if the file system runs out of space, removable Storage Checkpoints are not deleted.
When the kernel automatically removes the Storage Checkpoints, it applies the following policies:
Remove as few Storage Checkpoints as possible to complete the operation.
Never select a non-removable Storage Checkpoint.
Select a nodata Storage Checkpoint only when data Storage Checkpoints no longer exist.
Remove the oldest Storage Checkpoint first.
Remove a Storage Checkpoint even if it is mounted. New operations on such a removed Storage Checkpoint fail with the appropriate error codes.
If the oldest Storage Checkpoint is non-removable, then the oldest removable Storage Checkpoint is selected for removal. In such a case, data might be required to be pushed to a non-removable Storage Checkpoint, which might fail and result in the file system getting marked for a FULLFSCK. To prevent this occurrence, Symantec recommends that you only create removable Storage Checkpoints.