ZFS clone - Preserve properties?

[jef]

In "playing around with" 13.1-RC4 in preparation for revamping how I manage jails, I noticed that zfs clone does not preserve ZFS properties from the origin.

To some extent, this makes sense, as a non-default mountpoint may or may not be "right" to preserve.

On the other hand, some are "probably appropriate" to preserve. In my case of a hierarchy that is similar to that produced by bsdinstall, I would want to preserve at least

• canmount
• atime
• exec
• setuid

as well as some others.

I can add specific properties to the script I use to recursively copy, but is this an "already solved" task for ZFS clones, in general?

 

[Erichans]

This is not particular to 13.x; it has been like that for quite some time (perhaps even from the beginning). Illumos mentions it explicitly:

6.2. Overview of ZFS Clones
[...]
Clones do not inherit the properties of the dataset from which it was created. Use the zfs get and zfs set commands to view and change the properties of a cloned dataset. For more information about setting ZFS dataset properties, see Setting ZFS Properties.

as does

• Advanced ZFS Snapshots by Klara Systems, October 27, 2021
  Taking a Deeper Dive Into OpenZFS’s powerful Snapshotting Feature

It’s important to note that clones can only be created from a snapshot and that a snapshot cannot be destroyed as long as it has any clones. Interestingly, clones do not inherit the properties of the snapshot, meaning that different properties can be specified when creating the clone.

I suspect that reasons like those you mentioned are the basis why no decision was made as to which properties to choose to copy and which ones not to choose to copy to the clone, and just let "Clones [] not inherit the properties of the dataset from which it was created". This is something to consider when you have chosen the clone (or BE!) as the one to use instead of the snapshot it was cloned from. Then, you'll probably want to dispose of the old snapshot on which the clone is based to reduce your "administrative load" and to free up space taken up by the old snapshot. You cannot simply destroy that snapshot; for that you will need the zfs promote command option. See Promoting Clones in the Klara article, and the example (Example 10 in zfs(8)) it mentions.

Generally, for more information on ZFS—such as snapshots, clones and BEs—have a look at the two ZFS books ("ZFS" & "Advanced ZFS"), see: FreeBSD Development: Books, Papers, Slides

 

[jef]

I was hoping that in the years passed and the transition from Illumos to OpenZFS that there was a utility or flag that I had somehow missed.

If someone else comes by, here's some code that is sufficient for my low-volume and confined use cases.
(No guarantees on code quality and I'm arguably sloppy with backslashes in my printf format strings.)

PRESERVE_REGEX='^(atime|canmount|compression|exec|setuid)[[:>:]]'

# [...]

errcnt=0
for clone_filesystem in $known_filesystems ; do
        target=${clone_filesystem#$filesystem}
        from_fs=${clone_filesystem}@${snapshot}
        to_fs=${destination}${target}
        printf "%s -> %s" $from_fs $to_fs
        # Any properties to copy over?
        prop_lines=$(zfs get -H -o property,value -s local all ${clone_filesystem})
        prop_lines_keep=$(printf "%s" "$prop_lines" | grep -E "$PRESERVE_REGEX")
        if [ -n "$prop_lines_keep" ] ; then
            prop_str=$(printf -- '-o %s=%s ' $prop_lines_keep)
        else
            prop_str=''
        fi
        printf "\t\t%s\n" "$prop_str"
        prop_lines_drop=$(printf "%s" "$prop_lines" | grep -vE "$PRESERVE_REGEX")
        if [ -n "$prop_lines_drop" ] ; then
            printf "DROPPING properties\n"
            printf "\t%s\t%s\n" $prop_lines_drop
        fi
        if ( ! zfs clone $prop_str $from_fs $to_fs ) ; then
                errcnt=$(( errcnt + 1 ))
        else
        fi
done