Add --snapshot-property argument to pass to zfs snapshot

[digitalsignalperson]

Just exposing the property argument of zfs snapshot

From zfs snapshot man page:

     zfs snapshot [-r] [-o property=value]… dataset@snapname…

     -o property=value
         Set the specified property; see zfs create for details.

This is a different effect than changing a property on received. Also not the same as a pre-snapshot zfs set. A possible use-case is tracking info that should live with the atomic snapshot.

Example of pulling snapshots from different nodes and tracking where the snapshot came from

NAME                                              USED  WRITTEN:BY
rpool/DATA/project@data-2022-06-12_22-44-42        64K  node1
rpool/DATA/project@data-2022-06-12_22-45-41        64K  node2
rpool/DATA/project@data-2022-06-12_22-47-02        72K  node1
rpool/DATA/project@data-2022-06-12_22-48-17         0B  node3

[digitalsignalperson]

Also a bit curious on zfs properties behaviour. I couldn't find the explanation in the zfs docs, but find that properties are NOT creating a persistent history with zfs set, but they do when using zfs snapshot -o property=value

e.g. no history of property changes like this

zfs create rpool/zzz
zfs snapshot rpool/zzz@1
zfs set test:test=1 rpool/zzz
zfs snapshot rpool/zzz@2
zfs set test:test=2 rpool/zzz
zfs snapshot rpool/zzz@3
zfs set test:test=3 rpool/zzz

zfs list -t snapshot -o name,test:test rpool/zzz
NAME         TEST:TEST
rpool/zzz@1  3
rpool/zzz@2  3
rpool/zzz@3  3

vs

zfs create rpool/yyy
zfs snapshot -o test:test=1 rpool/yyy@1
zfs snapshot -o test:test=2 rpool/yyy@2
zfs snapshot -o test:test=3 rpool/yyy@3

zfs list -t snapshot -o name,test:test rpool/yyy
NAME         TEST:TEST
rpool/yyy@1  1
rpool/yyy@2  2
rpool/yyy@3  3

is that a zfs bug or intended behaviour?

[coveralls]

Coverage decreased (-0.3%) to 84.906% when pulling f7d359a on digitalsignalperson:master-snapshot_property into 4873913 on psy0rz:master.

[psy0rz]

Also a bit curious on zfs properties behaviour. I couldn't find the explanation in the zfs docs, but find that properties are NOT creating a persistent history with zfs set, but they do when using zfs snapshot -o property=value

e.g. no history of property changes like this

zfs create rpool/zzz
zfs snapshot rpool/zzz@1
zfs set test:test=1 rpool/zzz
zfs snapshot rpool/zzz@2
zfs set test:test=2 rpool/zzz
zfs snapshot rpool/zzz@3
zfs set test:test=3 rpool/zzz

zfs list -t snapshot -o name,test:test rpool/zzz
NAME         TEST:TEST
rpool/zzz@1  3
rpool/zzz@2  3
rpool/zzz@3  3

vs

zfs create rpool/yyy
zfs snapshot -o test:test=1 rpool/yyy@1
zfs snapshot -o test:test=2 rpool/yyy@2
zfs snapshot -o test:test=3 rpool/yyy@3

zfs list -t snapshot -o name,test:test rpool/yyy
NAME         TEST:TEST
rpool/yyy@1  1
rpool/yyy@2  2
rpool/yyy@3  3

is that a zfs bug or intended behaviour?

good question and very interesting indeed

[psy0rz]

can you call it --set-snapshot-properties and make it behave like --set-properties? (e.g. commaseperated multiple properties)

[Scrin]

is that a zfs bug or intended behaviour?

It's intended behavior, this exact behavior not very clearly documented on it's own, but to actually understand the behavior one has to fully understand zfs properties. In ZFS, there are two distinct types of properties, which both are settable with zfs set etc, but otherwise behave differently:

• native properties: exposes read-only statistics (such as compressratio) and controls various things about a dataset (such as compression)
• user properties: have no effect on ZFS behavior, they are simply user-controlled "annotations" that can be applied to datasets and snapshots, which follow the same inheritance rules as native properties

Also a bit curious on zfs properties behaviour. I couldn't find the explanation in the zfs docs, but find that properties are NOT creating a persistent history with zfs set, but they do when using zfs snapshot -o property=value

The behavior you are seeing here is that hierarchically snapshots are descendants of the dataset they're taken from; hierarchically their parent is the dataset itself, and so if there is no locally set property value (on the snapshot itself), as per the inheritance rules, ZFS will look for a value on the parent, and if it can't find a value on the parent, it will proceed to the parent of that, and so on.

Thus, when you do zfs snapshot -o test:test=1 rpool/yyy@1 you are setting test:test to 1 locally on the snapshot, so when you change test:test on the dataset (=hierarchically the parent of the snapshot), you obviously don't overwrite the locally set value on the snapshot. You can see this by looking at the SOURCE column in zfs get test:test where ZFS explains where it got the value from, in your first example it should say "inherited from rpool/zzz" for the snapshots and in the 2nd it should say "local" for the snapshots

Another point worth noting is that while user properties are settable on snapshots, native properties in general are not. For example, both of these will work:

zfs snapshot -o test:test=1 rpool/yyy@1
zfs set test:test=1 rpool/yyy@1

but neither of these work:

zfs snapshot -o compression=gzip rpool/yyy@1
zfs set compression=gzip rpool/yyy@1

[psy0rz]

very interesting. I can imagine they did this so that the properties on a snapshot are "frozen" as well, just like the snapshot itself? e.g. you can only set them when creating the snapshot, and never change them again after that?

[Scrin]

It depends on the property, but in general that's what happens most of the time, but you should not assume that's always the case.

For example, the compression property affects only newly written data, so if you change it on a dataset, nothing changes until you write new data, which is then written using the new compression property, and thus since snapshots are read-only, all the data "on the snapshot" keeps their original compression no matter what you do

On the other hand for example the mountpoint is not "frozen" in the same way; when you change the mountpoint of a dataset, the old mountpoint is not "preserved"; if you were to roll back to an earlier snapshot, it would stay where you "moved" it, as otherwise moving datasets (ie. migrating data between machines) would easily cause problems if you were to roll back to an earlier snapshot or backup which could then for example conflict with another dataset that took the previous mountpoint after moving the old dataset

In general it's important to remember that snapshots should be more thought of as "snapshots of the data on the dataset", and not necessarily "snapshots of the data on the dataset including metadata about the dataset that exists in the zpool where the dataset resides in"

[psy0rz]

no i meant user properties that are set during zfs snapshot -o test:test=blah

it would make sense that they are immutable after creating the snapshot

[digitalsignalperson]

Thanks for the detailed explanation Scrin.

Looks like props set on snapshots are in fact mutable

zfs list -t snapshot -o name,test:test rpool/yyy
NAME         TEST:TEST
rpool/yyy@1  1
rpool/yyy@2  2
rpool/yyy@3  3

zfs set test:test=3 rpool/yyy@1
zfs list -t snapshot -o name,test:test rpool/yyy
NAME         TEST:TEST
rpool/yyy@1  3
rpool/yyy@2  2
rpool/yyy@3  3

However this feature is still useful to me

[digitalsignalperson]

Hmm aside from syntax error in that last change, the patch is no longer working for me...

My original testing was branched off v3.1.1, not sure where I messed up yet

EDIT nvm, think it was my venv

[Scrin]

Correct, user properties on snapshots are mutable as well. You could for example use user properties on snapshots to mark which of the snapshots have been already synchronized elsewhere

[psy0rz]

thanks for your contribution :)