Technically, how does ZFS determine which snapshots are "children" for commands like "zfs send -R" and "zfs destroy -r"?

[Stilez]

Does it use matching txg ID reference? What if a dataset wasn't a descendant at the time but is renamed and became a descendant later?

Technically and precisely, how do recursive commands like "zfs send" and "zfs destroy" identify what is, and what isn't, a child, for this command?

I'm specifically interested in zfs send -R right now.

 

[Arwen]

The answer to the "zfs destroy -r" question is simple. You used a name to create the recursive snapshots, so the destroy only destroys the snapshots with the same name. For example;

Code:

zfs snapshot -r my_pool/my_parent_dataset@my_snapshot
{misc. work}
zfs destroy -r my_pool/my_parent_dataset@my_snapshot

Similar answer to the "zfs send -R", it is based on snaphot's name.

So, any new datasets or zVolumes that are created after the snapshot was created, won't be considered for the replication.

 

[Stilez]

it is based on snaphot's name.

But also

Similar answer to the "zfs send -R", it is based on snaphot's name.
So, any new datasets or zVolumes that are created after the snapshot was created, won't be considered for the replication.

Note the inconsistency in your answer - name? or creation timestamp? (or something else?) No criticism, but thats what I'm trying to clarify. It seems obvious that name and date match up, but it's really important if we might zfs rename datasets and snapshots, or delete intermediate ones it might have needed in order to trace "descendants", or inadvertently break internal linkages it might use when we move/rename.

CONCRETE EXAMPLE:

When a dataset or snapshot is renamed, is that technically, sufficient by itself to totally create/destroy the "child" relationship?

Example (contorted I know!) to test the point:

Create pool, create pool/dataset1, create pool/dataset2​

Create snapshots pool/dataset1@snap1, snap2, snap3 at daily intervals while working​

​

Wait a week, and create snapshots pool/dataset2@snap4, snap5, snap6 at daily intervals also while working​

​

Now...​

​

Rename pool/dataset2 --> pool/dataset1/dataset2​

Rename pool/dataset1/dataset2@snap5 --> pool/dataset1/dataset2@snap2​

​

Finally, for good measure...​

​

Take a recursive snapshot pool/dataset1/dataset2@snap7​

Is pool/dataset1/dataset2@snap2 now considered in all ways a child snapshot of pool/dataset1@snap2, as if they were snapped by the same zfs snap -r pool/dataset1 command?

Will all zfs/zpool -R/-r options treat it that way?

If I zfs send -R pool/dataset1@snap2 will snap4 appear in the replication stream because its a previous snap of the now-renamed snap2?

In brief, ZFS is so fluid about rename/move logical relationships, that I need to check technically if zfs uses txg, timestamp, or just path/snap textual name internally, when enumerating what it considers relevant datasets and snaps as a result of -R/-r in its various commands.

 

[Arwen]

I am sorry you have more questions. But, trying to figure out corner case may simply require testing. You can perform a trivial test by:

• Create empty datasets and descendants
• Snap them as desired
• Modify test
• Test send with "zfs send -Rpv POOL/PARENT@SNAP >/dev/null"

And if you find the manual page wrong, lacking enough detail or simply something to improve, put in a GitHub request. I've done it and had a manual page updated to clarify a detail.

Just test what you need.

Here is some output from my tests, (which took more time to write this post than to perform them):

Code:

# zfs snap -r rpool/src@temp

# zfs snap rpool/src/5.4.28-gentoo@mess
# zfs send -Rpv rpool/src@temp >/dev/null
skipping snapshot rpool/src/5.4.28-gentoo@mess because it was created after the destination snapshot (temp)
full send of rpool/src@temp estimated size is 3.14M
... rest of send works
# zfs destroy rpool/src/5.4.28-gentoo@mess

# zfs rename rpool/src/5.4.28-gentoo@temp rpool/src/5.4.28-gentoo@mess
# zfs send -Rpv rpool/src@temp >/dev/null
cannot send rpool/src@temp recursively: snapshot rpool/src/5.4.28-gentoo@temp does not exist
#