Re: [zfs-discuss] Proposal: user-defined properties
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
Re: [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 12345
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.
Best regards,
Constantin
--
Constantin GonzalezSun Microsystems GmbH, Germany
Platform Technology Group, Client Solutionshttp://www.sun.de/
Tel.: +49 89/4 60 08-25 91 http://blogs.sun.com/constantin/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] Proposal: user-defined properties
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 ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
[zfs-discuss] Proposal: user-defined properties
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
