hesela.devZFS deferred snapshot destruction
ZFS deferred snapshot destruction marks an ineligible snapshot for automatic deletion once its holds and clone dependencies no longer prevent removal.
Request versus waiting: zfs destroy -d can delete an eligible snapshot immediately; it is not a preview command. A pending snapshot remains visible and can acquire new holds or clones. [1]
Pending status: defer_destroy is read-only. Adding a hold does not cancel the pending request. Inspect userrefs, hold tags and clones together; visibility alone is not a retention guarantee. [2] [1]
Removal triggers: releasing the final hold can delete a pending snapshot with no remaining clones. Destroying the final dependent clone can delete its pending origin when no user holds remain. These paths are source-verified in OpenZFS 2.3.0; active internal long holds can make the release check return EBUSY. [3] [4]
Promotion is different: it reverses the origin/clone relationship and transfers snapshot ownership, rather than removing every dependency. Reinspect the snapshot under its new owner. A releasable hold is not administrator-resistant retention. [5] [6]
Relations
Citations
- OpenZFS v2.3: zfs-destroy(8), snapshot eligibility and -d versus -n
- OpenZFS v2.3: zfsprops(7), read-only defer_destroy, userrefs and clones
- OpenZFS zfs-2.3.0: dsl_userhold.c, release check and sync paths
- OpenZFS zfs-2.3.0: dsl_destroy.c, immediate snapshot and deferred origin destruction
- OpenZFS v2.3: zfs-promote(8), reversed dependency and transferred snapshots
- OpenZFS v2.3: zfs-allow(8), release permission may destroy a snapshot
Sources & caveats
- Documentation review of OpenZFS v2.3 and source inspection of tag zfs-2.3.0; no live pool, deletion or recovery experiment was performed.