How to Test Whether NAS Space Is Used by Snapshots or Live Files

Yes, you can distinguish them by comparing dataset used, referenced or logical size, snapshot-held space, and pool free space from the same timestamp.

The decision matters when a NAS reports far less free space than the visible folders appear to contain. The two competing states are live dataset allocation and blocks retained only by snapshots. Begin with a saved configuration and disposable data, observe one branch at a time, and stop if the test expands data-loss, permission, or availability risk.

Define the Conditions Behind the Snapshot Versus Live-File Space Decision

Record the environment before changing anything: software and firmware versions, device identities, mount or network path, free space, permissions, and the observable symptom. The baseline must preserve enough detail to reproduce a NAS reports far less free space than the visible folders appear to contain.

The first candidate is live dataset allocation. The second is blocks retained only by snapshots. The current OpenZFS space properties defines the mechanism or command boundary used in the test; it does not replace observation from this specific home server.

Write the acceptance condition and stop condition before running the discriminator. A pass must change the evidence predicted by one branch while leaving unrelated services unchanged; a fail must return the system to the saved state rather than trigger a chain of speculative fixes.

Test the Claim Without Lowering the Original Requirement

Use this discriminator: record pool and dataset accounting, delete one disposable large file, then compare before and after without destroying snapshots. Keep workload, client, path, file set, and timing constant so the result is attributable to the changed variable.

Use ZFS allocation accounting to select the field that can actually separate the branches, then capture its timestamp, exit status, error text, device or snapshot identity, latency, transferred bytes, permissions, and recovery state. A clean command exit is not enough when identity, durability, or application state is the claim under test.

Repeat the test once after a restart, reconnect, remount, or cold cache when that event is part of the original condition. If the first run is destructive or the environment cannot be restored, stop and reproduce on a disposable copy instead.

zfs list -o name,used,refer,usedbysnapshots,usedbydataset,usedbychildren

Interpret Pass, Fail, and Exception Results

PASS: live referenced space falls while used space remains because a snapshot still references the blocks. Record the exact version, identity, and workload that passed so the conclusion stays conditional rather than becoming a universal claim.

FAIL: both referenced and used remain high, or another dataset, clone, reservation, or metadata allocation owns the space. A fail does not automatically prove the opposite branch when network, memory, permissions, or source consistency can influence both; isolate those shared dependencies before escalating.

EXCEPTION OR AMBIGUOUS RESULT: stop deletions and map every dataset, snapshot, clone, and reservation before cleanup. Preserve logs and do not run repair, prune, destroy, repartition, or recursive ownership commands until a recoverable copy exists.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Confirm the Decision Under the Original Workload

Apply the action matched to the observed branch, then repeat the original condition rather than a reduced substitute. The decision holds only when live referenced space falls while used space remains because a snapshot still references the blocks across two cycles or the relevant reboot, sleep, interruption, or load transition.

Use the immutable backup windows to check the nearest dependent workflow, but keep the original trigger unchanged. Unrelated datasets, shares, containers, users, and recovery points must retain their previous access and timing.

The stop boundary is explicit: if both referenced and used remain high, or another dataset, clone, reservation, or metadata allocation owns the space, return to the last verified configuration, retain the evidence, and escalate to a deeper platform or hardware test only when the branch is repeatable.

After the target result holds, compare it with the backup verification cadence so the fix does not move risk into a neighboring service. A successful target test with a new backup, identity, timeout, or availability failure is still a failed change.

FAQ

For snapshot versus live-file space, the remaining searches usually concern why does deleting a file not free pool space, is logicalused the same as physical space, and can snapshot space be predicted before deletion. The answers below keep those edge cases separate from the primary decision.

The acceptance boundary does not move: live referenced space falls while used space remains because a snapshot still references the blocks. If a follow-up condition changes the filesystem, identity, network path, or application version, repeat only the discriminator affected by that change.

Stop broadening the experiment when both referenced and used remain high, or another dataset, clone, reservation, or metadata allocation owns the space. At that point, stop deletions and map every dataset, snapshot, clone, and reservation before cleanup; preserve the evidence before escalating to the platform, storage, or hardware owner.

Why does deleting a file not free pool space?

A snapshot may still reference its blocks, or a clone, reservation, or other dataset may own the allocation.

Is logicalused the same as physical space?

No. Compression, copies, metadata, and sharing make logical and allocated values differ.

Can snapshot space be predicted before deletion?

Referenced and unique properties help, but shared blocks mean reclaimed space depends on the complete snapshot chain.

For snapshot versus live-file space, the practical answer remains conditional: live referenced space falls while used space remains because a snapshot still references the blocks. When both referenced and used remain high, or another dataset, clone, reservation, or metadata allocation owns the space, stop deletions and map every dataset, snapshot, clone, and reservation before cleanup; a partial success that cannot survive the original workload is not compatibility.