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

Reply via email to