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:
parent
612c4930dd
commit
393363c5ec
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue