Actions
Bug #15512
openzfs: Check the dataset type more rigorously when fetching properties.
Start date:
Due date:
% Done:
90%
Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:
Description
Picking update from OpenZFS:
commit 962d52421236fc9cd61d59b4f18cff3276077da9 Author: Tim Chase <tim@chase2k.com> Date: Mon Apr 21 13:22:08 2014 -0500 Check the dataset type more rigorously when fetching properties. When fetching property values of snapshots, a check against the head dataset type must be performed. Previously, this additional check was performed only when fetching "version", "normalize", "utf8only" or "case". This caused the ZPL properties "acltype", "exec", "devices", "nbmand", "setuid" and "xattr" to be erroneously displayed with meaningless values for snapshots of volumes. It also did not allow for the display of "volsize" of a snapshot of a volume. This patch adds the headcheck flag paramater to zfs_prop_valid_for_type() and zprop_valid_for_type() to indicate the check is being done against a head dataset's type in order that properties valid only for snapshots are handled correctly. This allows the the head check in get_numeric_property() to be performed when fetching a property for a snapshot. Signed-off-by: Tim Chase <tim@chase2k.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #2265
Testing done:
Volume snapshot properties before:
root@test:/export/home/tsoome# zfs get all rpool/dump@test NAME PROPERTY VALUE SOURCE rpool/dump@test type snapshot - rpool/dump@test creation R sept 8 20:18 2023 - rpool/dump@test used 0 - rpool/dump@test referenced 1,88G - rpool/dump@test compressratio 1.00x - rpool/dump@test devices on default rpool/dump@test exec on default rpool/dump@test setuid on default rpool/dump@test createtxg 3131647 - rpool/dump@test xattr on default rpool/dump@test nbmand off default rpool/dump@test guid 5012531615399328199 - rpool/dump@test primarycache all default rpool/dump@test secondarycache all default rpool/dump@test defer_destroy off - rpool/dump@test userrefs 0 - rpool/dump@test mlslabel none default rpool/dump@test refcompressratio 1.00x - rpool/dump@test written 1,88G - rpool/dump@test logicalreferenced 1,88G - rpool/dump@test encryption off default rpool/dump@test org.openindiana.caiman:install ready inherited from rpool root@test:/export/home/tsoome#
and after update:
tsoome@test:~$ sudo zfs get all rpool/dump@test NAME PROPERTY VALUE SOURCE rpool/dump@test type snapshot - rpool/dump@test creation R sept 8 20:18 2023 - rpool/dump@test used 13K - rpool/dump@test referenced 1,88G - rpool/dump@test compressratio 1.00x - rpool/dump@test volsize 1,88G local rpool/dump@test createtxg 3131647 - rpool/dump@test guid 5012531615399328199 - rpool/dump@test primarycache all default rpool/dump@test secondarycache all default rpool/dump@test defer_destroy off - rpool/dump@test userrefs 0 - rpool/dump@test mlslabel none default rpool/dump@test refcompressratio 1.00x - rpool/dump@test written 1,88G - rpool/dump@test logicalreferenced 1,88G - rpool/dump@test encryption off default rpool/dump@test org.openindiana.caiman:install ready inherited from rpool tsoome@test:~$
Also we need follow up fix:
Return default value on numeric properties failing the "head check. Updates 962d52421236fc9cd61d59b4f18cff3276077da9. The referenced fix to get_numeric_property() caused numeric property lookups to consider the type of the parent (head) dataset when checking validity but there are some cases in the caller expects to see the property's default value even when the lookup is invalid. One case in which this is true is change_one() which is part of the renaming infrastructure. It may look up "zoned" on a snapshot of a volume which is not valid but it expects to see the default value of false. There may be other, yet unidentified cases in which zfs_prop_get_int() is used on technically invalid properties but which expect the property's default value to be returned. Signed-off-by: Tim Chase <tim@chase2k.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Turbo Fredriksson <turbo@bayour.com> Closes #2320
Related issues
Actions