Discard, thin provisioning, and space reclamation
Understand why guest deletions, snapshots, and physical pool usage change independently.
Discard tells a storage path that selected logical blocks no longer contain required guest data. It can release physical allocation when the volume policy, guest filesystem, and retained snapshots permit it.
Guest deletion is not pool reclamation
Removing a file updates guest filesystem metadata. The block device can still retain those allocated blocks until the filesystem issues discard and the storage service processes it. Infra does not inspect guest directory contents to infer which blocks are unused.
A thin volume reserves logical address space while physical usage grows with written blocks and metadata. Its quota remains based on provisioned capacity. Returning physical blocks does not shrink the volume or lower its logical quota.
Enable discard deliberately
The storage policy declares whether discard is supported and exposed to guests. Inspect Volume → Performance → Discard before enabling a guest trim schedule. An unsupported policy reports the capability as unavailable rather than treating a submitted trim as a successful reclamation.
For a supported Linux filesystem, the guest administrator can inspect discard capabilities and run filesystem-aware trim through its operating system tools. Do not submit raw block ranges inferred from filenames or filesystem free-space estimates.
Snapshot dependencies
A snapshot can retain blocks the live guest no longer needs. Trimming the live volume does not invalidate those recovery points. Pool usage falls only when no live volume, snapshot, clone, or pending copy requires the underlying blocks.
Deleting a snapshot can therefore reclaim less space than its displayed logical size. A clone sharing its backing data can keep those blocks referenced after the original guest and snapshot are gone.
Repair and cleanup
Reclamation can wait behind reference cleanup, replication work, or a device maintenance condition. Inspect retained-byte reasons and cleanup operations before classifying the difference as a leak.
A full pool can block both new writes and some recovery work. Retain repair reserve instead of planning to delete files after the pool reaches its last available block. Snapshot expiration is not an immediate-space guarantee.
Encryption and erasure
Discard is not a hardware sanitation procedure. Storage devices, snapshots, backups, and provider copies have their own data lifecycle. Encryption-key retirement is also separate from an assertion that physical media was wiped.
Use backup retention to remove independent recovery copies, volume encryption to preserve required decryption keys, and Storage pool API to inspect physical accounting.