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

Reply via email to