Feature #3569
open
ZFS dataset cloning should replicate "local" attributes from the origin
0%
Description
Currently, if a ZFS dataset's snapshot is cloned, the clone inherits all attributes from its new "parent" dataset in the hierarchy (not from its origin).
On an annoying side, this disables explicitly configured compression of split-rootfs hierarchy during "beadm clone" (as discussed in my RFE #829), and on an even more evil side - I recently found that custom "recordsize" value configured for a database was ignored during cloning (i.e. clone's new writes became 128KB aligned, as they were for its new hierarchical parent dataset, instead of 8KB as was proper for this database). Since the situation was not noted instantly, this performance problem was solvable only by destruction and recreation of the dataset along with data migration - causing a downtime.
The proposal is to inspect origin dataset's current explicitly set values (as in "zfs get all DATASET | grep -w local") and set them on the newly created clone like "zfs clone -o ... -o .... src@snap dst").
Perhaps unfortunately, the snapshots don't retain attribute values at the time of their creation, so this cloning should likely rather follow the example of "zfs send -R" and replicate properties from the snapshot namesake's live dataset (i.e. "src" for "src@snap", as opposed to other datasets which also have this snapshot in their cloned history).
If this feature, for the sake of reverse-compatibility, becomes a non-default optional one, then in particular "beadm clone" should be amended to try and invoke it.
Updated by Jim Klimov over 9 years ago
Following my recent work on improvements of ZBE cloning with "zoneadm clone" as part of bug #1204, I came to realize that this is another area where snapshots are created from, usually, an active source with some specifically set attributes, and it may be desired that these settings are retained in the clone as well.
Again, this feature can be implemented in the zone-cloning scripts for particular brands (perhaps as a new option for the invoker to enable this feature), in case of scripting this is almost a simple one-liner. However, it would be more correct to implement and maintain this logic once, in the "zfs" command, and just update the invokers like the zone-brand "clone" scripts or the "beadm" program.