make createtxg and guid properties public #6102
Conversation
|
@problame, thanks for your PR! By analyzing the history of the files in this pull request, we identified @behlendorf, @ahrens and @rlaager to be potential reviewers. |
man/man8/zfs.8
Outdated
| .ad | ||
| .sp .6 | ||
| .RS 4n | ||
| The transaction group (TXG) in which the dataset or bookmark was created. It is suitable for ordering a list of snapshots, e.g. for incremental \fBsend\fR & \fBrecv\fR. |
There was a problem hiding this comment.
I think it should be made more clear that a bookmark's createtxg is not the TXG in which the bookmark itself was created, but in which the snapshot from which the bookmark was derived from was created. Hence a snapshot and its bookmark (assuming both exist at the same time) will have the same createtxg value.
There was a problem hiding this comment.
Adressed in a4da85a
Should I squash each time I respond to a comment or rather squash right before merge?
There was a problem hiding this comment.
You can squash immediately if your changes are not so big, it will make the merge process faster.
|
If I had to be really really picky, snapshots are already sorted by (Default sort order is by |
Document the existence of `createtxg` and `guid` native properties in
man pages and zfs command output.
One of the great features of ZFS is incremental replication of
snapshots, possibly between pools on different machines.
Shell scripts are commonly used to auomate this procedure. They have to
find the most recent common snapshot between both sides and then
perform incremental send & recv.
Currently, scripts rely on the sorting order of `zfs list`, which
defaults to `createtxg`, and the assumption that snapshot names on
either side do not change.
By making `createtxg` and `guid` part of the public ZFS interface,
scripts are enabled to use
a) `createtxg` to determine the logical & temporal order of snapshots
(the creation property is not an equivalent substitute since
multiple snapshots may be created within one second)
b) `guid` to uniquely identify a snapshot, independent of its current
display name
This has the potential of making scripts safer and correct.
Signed-off-by: Christian Schwarz <me@cschwarz.com>
|
Squashed and ready to go. @rlaager do I have to take care of upstreaming the change to OpenZFS myself or is this done in some automated fashion? |
|
It's a separate process (with I'm not familiar with) to upstream to OpenZFS. |
Description
Document the existence of
createtxgandguidnative properties inman pages and zfs command output.
Motivation and Context
One of the great features of ZFS is incremental replication of
snapshots, possibly between pools on different machines.
Shell scripts are commonly used to auomate this procedure. They have to
find the most recent common snapshot between both sides and then
perform incremental send & recv.
Currently, scripts rely on the sorting order of
zfs list, whichdefaults to
createtxg, and the assumption that snapshot names oneither side do not change.
By making
createtxgandguidpart of the public ZFS interface,scripts are enabled to use
a)
createtxgto determine the logical & temporal order of snapshots(the creation property is not an equivalent substitute since
multiple snapshots may be created within one second)
b)
guidto uniquely identify a snapshot, independent of its currentdisplay name
This has the potential of making scripts safer and correct.
How Has This Been Tested?
The module was built on ArchLinux and Debian Jessie, up-to-date on 05 May 2017.
The output of
zfs getandman zfswas checked to include the now public properties.Types of changes
zfs get outputChecklist:
Signed-off-by.Remarks from author
Should this be upstreamed?