c/mirror_zfs
1
0
Fork 0
mirror of https://git.proxmox.com/git/mirror_zfs.git synced 2025-04-06 17:49:11 +03:00
Code Issues Packages Projects Releases Wiki Activity

Consistently captialize GUID for features

Browse Source 
Reviewed-by: George Melikov <mail@gmelikov.ru>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Richard Laager <rlaager@wiktel.com>
Closes #8626
This commit is contained in:
Richard Laager 2019-04-14 21:15:04 -05:00 committed by Brian Behlendorf
parent 612c4930dd
commit 393363c5ec
2 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
man/man5/zpool-features.5
View File

@ -38,15 +38,15 @@ this set may include unsupported features.
.SS "Identifying features" .SS "Identifying features"
.sp .sp
.LP .LP
Every feature has a guid of the form \fIcom.example:feature_name\fR. The reverse Every feature has a GUID of the form \fIcom.example:feature_name\fR. The
DNS name ensures that the feature's guid is unique across all ZFS reverse DNS name ensures that the feature's GUID is unique across all ZFS
implementations. When unsupported features are encountered on a pool they will implementations. When unsupported features are encountered on a pool they will
be identified by their guids. Refer to the documentation for the ZFS be identified by their GUIDs. Refer to the documentation for the ZFS
implementation that created the pool for information about those features. implementation that created the pool for information about those features.
.sp .sp
.LP .LP
Each supported feature also has a short name. By convention a feature's short Each supported feature also has a short name. By convention a feature's short
name is the portion of its guid which follows the ':' (e.g. name is the portion of its GUID which follows the ':' (e.g.
\fIcom.example:feature_name\fR would have the short name \fIfeature_name\fR), \fIcom.example:feature_name\fR would have the short name \fIfeature_name\fR),
however a feature's short name may differ across ZFS implementations if however a feature's short name may differ across ZFS implementations if
following the convention would result in name conflicts. following the convention would result in name conflicts.
@ -109,7 +109,7 @@ importing pools).
.sp .sp
.LP .LP
For each unsupported feature enabled on an imported pool a pool property For each unsupported feature enabled on an imported pool a pool property
named \fIunsupported@feature_guid\fR will indicate why the import was allowed named \fIunsupported@feature_name\fR will indicate why the import was allowed
despite the unsupported feature. Possible values for this property are: despite the unsupported feature. Possible values for this property are:
.sp .sp

10
module/zfs/zfeature.c
View File

@ -41,9 +41,9 @@
* spa_version() number. * spa_version() number.
* *
* Each new on-disk format change will be given a uniquely identifying string * Each new on-disk format change will be given a uniquely identifying string
* guid rather than a version number. This avoids the problem of different * GUID rather than a version number. This avoids the problem of different
* organizations creating new on-disk formats with the same version number. To * organizations creating new on-disk formats with the same version number. To
* keep feature guids unique they should consist of the reverse dns name of the * keep feature GUIDs unique they should consist of the reverse dns name of the
* organization which implemented the feature and a short name for the feature, * organization which implemented the feature and a short name for the feature,
* separated by a colon (e.g. com.delphix:async_destroy). * separated by a colon (e.g. com.delphix:async_destroy).
* *
@ -95,11 +95,11 @@
* These objects are linked to by the following names in the pool directory * These objects are linked to by the following names in the pool directory
* object: * object:
* *
* 1) features_for_read: feature guid -> reference count * 1) features_for_read: feature GUID -> reference count
* Features needed to open the pool for reading. * Features needed to open the pool for reading.
* 2) features_for_write: feature guid -> reference count * 2) features_for_write: feature GUID -> reference count
* Features needed to open the pool for writing. * Features needed to open the pool for writing.
* 3) feature_descriptions: feature guid -> descriptive string * 3) feature_descriptions: feature GUID -> descriptive string
* A human readable string. * A human readable string.
* *
* All enabled features appear in either features_for_read or * All enabled features appear in either features_for_read or