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
Constantin Gonzalez Schmitz
2006-Aug-18 07:36 UTC
[zfs-discuss] Proposal: user-defined properties
Hi Eric, this is a great proposal and I''m sure this is going to help administrators a lot. One small question below:> 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''.> # 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 12345the example suggests that properties may be case-insensitive. Is that the case (sorry for the pun)? If so, that should be noted in the user defined property definition just for clarity. Best regards, Constantin -- Constantin Gonzalez Sun Microsystems GmbH, Germany Platform Technology Group, Client Solutions http://www.sun.de/ Tel.: +49 89/4 60 08-25 91 http://blogs.sun.com/constantin/
On Fri, Aug 18, 2006 at 09:36:20AM +0200, Constantin Gonzalez Schmitz wrote:> > the example suggests that properties may be case-insensitive. Is that the case > (sorry for the pun)? If so, that should be noted in the user defined property > definition just for clarity. >Good point. The property names are case-insensitive (and internally are always converted to lower-case), but the property values can be anything. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
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 at 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
On Mon, Aug 21, 2006 at 12:21:44PM +0200, Roch wrote:> > We might need something to ''destroy'' those properties, locally and > recursively ?This is what this piece of text is for: "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." So you can do ''zfs inherit -r foo:bar pool'' to clear all settings in the pool.> Is empty string a valid VALUE, does this need to be spelled out ?Yes, it is valid. I will add some text to point this out. - Eric -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
That is very useful feature! I have two questions for you. 1. How to get all the user defined properties? 2. Are there any length limitation for user defined properties and the value? - Junchao This message posted from opensolaris.org