Deleting files inside a virtual machine frees space for that guest filesystem to reuse. It does not prove that the virtual disk, datastore and storage array have released the corresponding allocation. Reclamation depends on the discard path and the provisioning rules at each layer.1, 3
Start by naming the measurement that has not changed. Guest free space, allocated VMDK space, datastore free space and array physical consumption are different observations. A successful operation at one layer is not a receipt from every layer below it.
This guide traces the reclamation boundary; it contains no trim, zero-fill, disk-conversion or datastore-UNMAP procedure.
Follow the allocation chain
For a Linux guest on VMFS, draw the actual path: application files, guest filesystem, any guest volume-management layer, virtual disk, VMFS datastore and backing storage. Record the provisioning type and exact versions beside the relevant components.
Then distinguish two questions. Can the guest communicate that blocks are no longer needed? Can each lower layer release or pass on the allocation represented by those blocks? The first does not automatically answer the second.
Broadcom's scoped VMFS article explains that thick virtual disks remain preallocated at the VMFS layer, whereas thin provisioning supports the reclamation path described there. It also distinguishes VMFS5 from VMFS6, where reclamation can be automatic and asynchronous.3
This is not a universal statement about vSAN, NFS, vVols or every array implementation. Those storage types require their own vendor documentation. Do not transplant a VMFS command or expectation into a different datastore architecture.
Establish whether the guest really released space
Before investigating the hypervisor, confirm the guest filesystem's free-space change on the correct mount. A deleted pathname is not necessarily a completed release of all references to its data. If guest free space has not increased, start with that guest-side accounting problem rather than assuming a lower-layer discard defect.5
Application-managed files introduce another boundary. For example, PostgreSQL documents that ordinary vacuum generally makes table space reusable without returning it to the operating system.6 Establish whether the application actually releases filesystem blocks before expecting guest discard to solve the remaining allocation.
These are diagnostic branches, not instructions to shrink databases or delete snapshots. Such changes have separate performance, retention and recovery consequences.
If a guest uses an LVM thin pool, snapshots can retain shared blocks while other blocks change. The LVM manual documents this sharing model.4 Treat it as an additional layer to assess, not proof of how VMware snapshots or a particular array implement retention.
What the Linux trim result actually says
The fstrim manual describes discarding filesystem blocks that are no longer in use. Its verbose count is the number of bytes passed down the block stack for potential discard. It is a maximum from the storage device's perspective, not a measurement of newly released physical capacity.1
Repeated invocations can report the same potential range. Lower layers may adjust ranges to their own constraints, and those reductions are not necessarily reflected in the reported length. Adding together successive verbose counts therefore does not produce an accurate reclaimed-capacity total.1
A hypothetical report of a large potential discard amount followed by little array change is not enough to establish failure. The investigation still needs provisioning details, lower-layer support and an observation period appropriate to asynchronous processing.
Likewise, a dry-run mode does not prove that the real discard request will succeed. The documented mode skips the filesystem discard ioctl. It is useful for understanding selected work, but it cannot validate the end-to-end storage path.1
Check advertised support without treating it as a guarantee
Broadcom KB 396655 describes Linux trim failures associated with virtual hardware below version 13 and lack of the specific WRITE SAME with UNMAP capability. The article includes a vSAN example and labels its ESXi environment broadly.2
Use that as a documented failure pattern to compare with matching evidence. It does not prove that every Linux discard issue is fixed by a hardware upgrade, or that version 13 alone guarantees reclamation across all controllers, disks and datastores.
Record the exact unsupported-operation or I/O error and the virtual disk that produced it. Confirm the guest, virtual controller, virtual hardware and storage combination against documentation applicable to that combination. An unrelated disk advertising discard support says little about the failing mount.
A virtual hardware upgrade is a lifecycle change with its own compatibility and downtime requirements. This article does not prescribe one as a diagnostic shortcut. The output of this investigation should be a supported compatibility finding for the owning team.
Separate datastore recovery from array recovery
A datastore can make capacity available for new files before the backing array reports a corresponding physical reduction. Broadcom documents VMFS6's asynchronous UNMAP and the need to check that reclamation is not disabled, along with support at the storage device.3
Record the time and units of each measurement. Include ongoing writes and other consumers of the same datastore or array pool. A net usage chart can remain flat because new allocation offsets released capacity; it is not a direct counter of the guest's operation.
Ask the storage owner how its reported value accounts for snapshots, replication and data reduction. Those are questions for the actual platform, not assumptions that can be resolved from the guest's filesystem report.
If the observation window is too short or the metric definition is unclear, record the result as inconclusive. Do not repeatedly issue reclamation operations merely to make a graph change.
Avoid turning capacity diagnosis into a write storm
Zero-filling free space writes data and can consume thinly provisioned capacity before a later reclamation step. It is not a passive test. Storage migration, format conversion, snapshot deletion and manual datastore UNMAP are also operational changes, not ordinary evidence collection.
The Broadcom VMFS source includes corrective recipes, but this article does not adopt them. Selecting a safe operation requires verified topology, current capacity, vendor constraints and an approved rollback or recovery plan. A short knowledge-base example is not sufficient validation for a production change.
The Linux manual also notes that trim can affect concurrent I/O performance. More frequent execution is not automatically a better response to an unexplained result.1
Define the evidence needed to close the case
A useful conclusion names the blocked boundary. Examples include guest blocks not actually released, a documented missing virtual-device capability, a provisioned disk format that retains allocation, or pending downstream reclamation. Each should be tied to observed evidence rather than inferred solely from one capacity chart.
After an independently approved change, compare the same metrics over a suitable interval and account for competing writes. Record separately what the guest submitted, what the datastore released and what the storage platform reports.
If only the guest result is available, say that downstream reclamation remains unverified. That distinction prevents a successful trim message from becoming an unsupported storage-capacity promise.
Learning notes
- Guest deletion, virtual-disk release and array reclamation are separate events.
- A trim byte count describes potential discard, not guaranteed physical savings.
- Compatibility must be checked for the exact storage path.
- Reclamation procedures need operational review; repeated execution is not a substitute for evidence.
Acceptance checklist
- [ ] Guest, virtual-disk, datastore and array measurements refer to the same storage path.
- [ ] Exact discard capabilities and provisioning constraints are documented.
- [ ] Any approved reclamation result is measured at the intended downstream layer.
- [ ] Reported trim bytes are not substituted for physical savings or application verification.
References
- fstrim(8) - Linux manual page. Accessed 2026-11-01.
- Unmap/trim operation doesn't reclaim the space on linux vms. Accessed 2026-11-01.
- Storage array space not reclaimed after Guest OS cleanup on VMFS (Broadcom KB 323112; legacy 2057513). Accessed 2026-11-01.
- lvmthin(7) - Linux manual page. Accessed 2026-11-01.
- unlink(2) - Linux manual page. Accessed 2026-11-01.
- PostgreSQL: Documentation: 18: 24.1. Routine Vacuuming. Accessed 2026-11-01.