Consistently captialize GUID for features

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

View File

@ -38,15 +38,15 @@ this set may include unsupported features.
.SS "Identifying features"
.sp
.LP
Every feature has a guid of the form \fIcom.example:feature_name\fR. The reverse
DNS name ensures that the feature's guid is unique across all ZFS
Every feature has a GUID of the form \fIcom.example:feature_name\fR. The
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
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.
.sp
.LP
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),
however a feature's short name may differ across ZFS implementations if
following the convention would result in name conflicts.
@ -109,7 +109,7 @@ importing pools).
.sp
.LP
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:
.sp

View File

@ -41,9 +41,9 @@
* spa_version() number.
*
* 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
* 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,
* 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
* 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.
* 2) features_for_write: feature guid -> reference count
* 2) features_for_write: feature GUID -> reference count
* 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.
*
* All enabled features appear in either features_for_read or