Eric Schrock writes:
> Following up on a string of related proposals, here is another draft
> proposal for user-defined properties. As usual, all feedback and
> comments are welcome.
>
> The prototype is finished, and I would expect the code to be integrated
> sometime within the next month.
>
> - Eric
>
> INTRODUCTION
>
> ZFS currently supports a well-defined set of properties for managing ZFS
> datasets. These properties represent either read-only statistics
> exported by the ZFS framework ('available', 'compressratio', etc), or
> editable properties which affect the behavior of ZFS ('compression',
> 'readonly', etc).
>
> While these properties provide a structured way to interact with ZFS, a
> common request is to allow unstructured properties to be attached to ZFS
> datasets. This is covered by the following RFE:
>
> 6281585 user defined properties
>
> This would allow administrators to add annotations to datasets, as well
> as allowing ISVs to store application-specific settings that interact
> with individual datasets.
>
> DETAILS
>
> This proposal adds a new classification of ZFS properties known as 'user
> properties'. The existing native properties will remain, as they
> provide additional semantics (mainly validation) which are closely tied
> to the underlying implementation.
>
> Any property which contains a colon (':') is defined as a 'user
> property'. The name can contain alphanumeric characters, plus the
> following special characters: ':', '-', '.', '_'. User properties are
> always strings, and are always inherited. No additional validation is
> done on the contents. Properties are set and retrieved through the
> standard mechanisms: 'zfs set', 'zfs get', and 'zfs inherit'.
> Inheriting a property which is not set in any parent is equivalent to
> clearing the property, as there is no default value for user-defined
> properties.
>
> It is expected that the colon will serve two purposes: to distinguish
> between native properties and provide an (unenforced) namespace for user
> properties. For example, it is hoped that properties are defined as
> '<module>:<property>', to group properties together and to provide a
> larger namespace for logical separation of properties. No enforcement
> of this namespace is done by ZFS, however, and the empty string is valid
> on both sides of the colon.
>
> EXAMPLES
>
> # zfs set local:department=12345 test
> # zfs get -r local:department test
> NAME PROPERTY VALUE SOURCE
> test local:department 12345 local
> test/foo local:department 12345 inherited from test
> # zfs list -o name,local:department
> NAME LOCAL:DEPARTMENT
> test 12345
> test/foo 12345
> # zfs set local:department=67890 test/foo
> # zfs inherit local:department test
> # zfs get -s local -r all test
> NAME PROPERTY VALUE SOURCE
> test/foo local:department 12345 local
> # zfs list -o name,local:department
> NAME LOCAL:DEPARTMENT
> test -
> test/foo 12345
>
> MANPAGE CHANGES
>
> TBD
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Great.
We might need something to 'destroy' those properties, locally and recursively ?
Is empty string a valid VALUE, does this need to be spelled out ?
-r
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
