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