You have a ZFS pool that contains a hierarchy of data file systems. You create snapshots of the file systems and you created a clone (dpool/export/CID) of the dpool/export/home/CID file systems. The…

Question

Options

• AThe USED value will increase and the REFER value will decrease;
• BThe USED value will decrease and the REFER value will increase;
• CThe USED value will decrease, the REFER value will decrease;
• DUSED, REFER and the AVAIL value will be unchanged.

• A
  60% (21)
• B
  23% (8)
• C
  6% (2)
• D
  11% (4)

Explanation

Option A is correct because in ZFS, a clone initially shares all blocks with its source snapshot, so its USED starts near zero. When you delete a file from the clone, ZFS (being copy-on-write) must write new metadata blocks (updated directory entries, inode tables) unique to the clone to record the deletion - these unique blocks increase the clone's USED. Simultaneously, REFER decreases because the clone no longer references the deleted file's data blocks, even though the snapshot still holds them.

Why the distractors fail:

• B has both values backwards - deletion creates metadata overhead (USED goes up, not down) and removes referenced data (REFER goes down, not up).
• C gets REFER right but USED wrong - deleting from a clone generates new unique CoW metadata, so USED rises rather than falling.
• D is wrong because a deletion fundamentally changes what the clone references and what unique blocks it owns; something always changes.

Memory tip: Think "deleting from a clone is secretly writing." ZFS never truly deletes in-place - it writes new metadata to record the change (USED goes up), while the old file data is no longer visible to the clone (REFER goes down). The snapshot quietly retains the original blocks, so no space is actually freed until the snapshot is destroyed.

No community discussion yet for this question.