unsetting/resetting ZFS properties

[Haudy Kazemi]

Hello,

I recently asked myself this question: Is it possible to unset ZFS
properties? Or reset one to its default state without looking up what
that default state is?
I believe the answer is yes, via the zfs inherit command (I haven't
verified yet, but I think a case could be made to add functionality to
the zfs set command...or the documentation...to make this clearer.)

An example:
You have a pool named tank.
You have created a filesystem called 'home' and it has a child
filesystem called 'smith'.
You run: zfs set compression=on tank/home
which turns on compression on the 'home' filesystem (it is a local
property) and on the 'smith' filesystem (as an inherited property).
(You inspect the properties with 'zfs get'.)

You then run: zfs set compression=on tank/home/smith
which makes compression on the 'smith' filesystem also be a local property.

At this point you decide you would rather that the compression property
for filesystem 'smith' be inherited after all, not be a local property
anymore.

You run:
zfs set compression=off tank/home/smith
but that doesn't unset the compression setting for filesystem 'smith',
it just overrides the inheritance of compression=on (as expected).

So how to unset/reset?

In looking for an answer I went back to the page where I found the
available properties and their valid parameters:
Introducing ZFS Properties
http://docs.sun.com/app/docs/doc/817-2271/gazss?l=en&a=view

I didn't see anything under 'zfs set' or under the 'compression' section
for how to unset a property. I did find a link to this page:
Setting ZFS Properties
http://docs.sun.com/app/docs/doc/817-2271/gazsp?l=en&a=view

which had a link to this page:
man pages section 1M: System Administration Commands
http://docs.sun.com/app/docs/doc/819-2240/zfs-1m?l=en&a=view

which talked about 'zfs inherit' and 'zfs set':
zfs inherit [-r] property filesystem|volume|snapshot ...
zfs set property=value filesystem|volume|snapshot ...

*****
In short, I think an alias for 'zfs inherit' could be added to 'zfs set'
to make it more clear to those of us still new to ZFS. Either that, or
add some additional pointers in the Properties documentation that the
set command can't unset/reset properties.
The alias could work like this:
If someone issues a command like this:
zfs set property=inherit filesystem|volume|snapshot
then run this code path:
zfs inherit property filesystem|volume|snapshot

The -r command could be added to 'zfs set' as well, to allow 'zfs set'
to recursively set local properties on child filesystems.
zfs set -r property=inherit filesystem|volume|snapshot
then run this code path:
zfs inherit -r property filesystem|volume|snapshot

Another example if zfs set was extended:
zfs set -r compression=on tank/home
would set a local property of compression=on for 'home' and each of its
child filesystems. (new functionality)

zfs set -r compression=inherit tank/home
would set the property of compression to default for 'home' and each of
its child filesystems. (alias of zfs inherit -r compression tank/home)

zfs set compression=inherit tank/home
would set the property of compression to default for 'home' and leave
the child filesystems properties untouched (alias of zfs inherit
compression tank/home)

[Darren J Moffat]

Post by Haudy Kazemi
Hello,
I recently asked myself this question: Is it possible to unset ZFS
properties? Or reset one to its default state without looking up what
that default state is?
I believe the answer is yes, via the zfs inherit command (I haven't
verified yet, but I think a case could be made to add functionality to
the zfs set command...or the documentation...to make this clearer.)
You have a pool named tank.
You have created a filesystem called 'home' and it has a child
filesystem called 'smith'.
You run: zfs set compression=on tank/home
which turns on compression on the 'home' filesystem (it is a local
property) and on the 'smith' filesystem (as an inherited property).
(You inspect the properties with 'zfs get'.)
You then run: zfs set compression=on tank/home/smith
which makes compression on the 'smith' filesystem also be a local property.
At this point you decide you would rather that the compression property
for filesystem 'smith' be inherited after all, not be a local property
anymore.
zfs set compression=off tank/home/smith
but that doesn't unset the compression setting for filesystem 'smith',
it just overrides the inheritance of compression=on (as expected).
So how to unset/reset?

zfs inherit compression tank/home/smith

Post by Haudy Kazemi
*****
In short, I think an alias for 'zfs inherit' could be added to 'zfs set'
to make it more clear to those of us still new to ZFS. Either that, or
add some additional pointers in the Properties documentation that the
set command can't unset/reset properties.

That would to me be confusing it would also complicate the code quite a
lot because now the action would be part of the value for a different
subcommand. It also won't work at all for some properties, in
particular what if you have a hostname called "inherit" that is going to
be very confusing for the share* properties.

If there is an issue here I believe we should first trying and resolve
it with documentation changes.

[Andrew Gabriel]

Post by Darren J Moffat

Post by Haudy Kazemi
zfs set compression=off tank/home/smith
but that doesn't unset the compression setting for filesystem
'smith', it just overrides the inheritance of compression=on (as
expected).
So how to unset/reset?

zfs inherit compression tank/home/smith

Post by Haudy Kazemi
*****
In short, I think an alias for 'zfs inherit' could be added to 'zfs
set' to make it more clear to those of us still new to ZFS. Either
that, or add some additional pointers in the Properties documentation
that the set command can't unset/reset properties.

That would to me be confusing it would also complicate the code quite
a lot because now the action would be part of the value for a
different subcommand. It also won't work at all for some properties,
in particular what if you have a hostname called "inherit" that is
going to be very confusing for the share* properties.
If there is an issue here I believe we should first trying and resolve
it with documentation changes.

I'd have to say that probably most customers I've worked with on zfs
have fallen over this one, given up trying to work out how to do it, and
had to ask (and the first time it happened, I had to ask too). The
obvious things they have tried are generally something along the lines

zfs set foobar=inherit[ed] ...

There is something unnatural about the 'zfs inherit' command -- it just
isn't where that functionality is expected to be, based on the structure
of the other commands.

[Haudy Kazemi]

Post by Andrew Gabriel

Post by Darren J Moffat

Post by Haudy Kazemi
In short, I think an alias for 'zfs inherit' could be added to 'zfs
set' to make it more clear to those of us still new to ZFS. Either
that, or add some additional pointers in the Properties
documentation that the set command can't unset/reset properties.

That would to me be confusing it would also complicate the code quite
a lot because now the action would be part of the value for a
different subcommand. It also won't work at all for some
properties, in particular what if you have a hostname called
"inherit" that is going to be very confusing for the share* properties.

Maybe I'm missing something, but what would a specific example be? I
don't see one in the docs that would create a conflict.

I see the following valid options for sharesmb at
http://docs.sun.com/app/docs/doc/817-2271/gfwqv?l=en&a=view and at
http://docs.sun.com/app/docs/doc/817-2271/gfwpk?l=en&a=view:
# zfs set sharesmb=off sandbox/fs2
# zfs set sharesmb=on sandbox
# zfs set sharesmb=name=myshare sandbox/fs2
The documentation says this in regards to 'name': "A pseudo property
/name /is also supported that allows you to replace the dataset name
with a specific name. The specific name is then used to replace the
prefix dataset in the case of inheritance."

I see the following valid options for sharenfs at
http://docs.sun.com/app/docs/doc/817-2271/gamnd?l=en&a=view :
# zfs set sharenfs=on tank/home
# zfs set sharenfs=ro tank/home/tabriz
# zfs set sharenfs=off tank/home

The documentation says this: The sharenfs property is a comma-separated
list of options to pass to the share command. The special value on is an
alias for the default share options, which are read/write permissions
for anyone. The special value off indicates that the file system is not
managed by ZFS and can be shared through traditional means, such as the
/etc/dfs/dfstab file. All file systems whose sharenfs property is not
off are shared during boot.

'inherited' would be one more special value.

Post by Andrew Gabriel

Post by Darren J Moffat
If there is an issue here I believe we should first trying and
resolve it with documentation changes.

Some UI guides say there is room for improvement in the design of a
system if it isn't self-evident/self-documenting to reasonably informed
people. As this is happening to tech savvy people (assuming that those
who are using/trying out OpenSolaris and ZFS are relatively tech savvy),
this is particularly evident.

Post by Andrew Gabriel
I'd have to say that probably most customers I've worked with on zfs
have fallen over this one, given up trying to work out how to do it,
and had to ask (and the first time it happened, I had to ask too). The
obvious things they have tried are generally something along the lines
zfs set foobar=inherit[ed] ...
There is something unnatural about the 'zfs inherit' command -- it
just isn't where that functionality is expected to be, based on the
structure of the other commands.

This is exactly what happened to me.

I had tried:
zfs set compression=off tank/home/smith (had the logical result of
setting a local property)
zfs set compression=default tank/home/smith
zfs set compression=inherit tank/home/smith
zfs set compression=inherited tank/home/smith

None of which did what I wanted (to set the value to
default/inherited). The commands 'zfs get' and 'zfs set' felt natural
to view/set/edit filesystem properties. Editing the property to go back
to the default/inherited setting really feels like something that
belongs under 'zfs set', rather than as a top level command. The
documentation examples show 'zfs set' as being 'property=value', and
'value' can take on various text or numerical settings depending on
which property is being changed. The intuitive setting is to have a
'value' that unsets/resets. The general thought process: "I used 'zfs
set' to change the value of the property, now I want to change it back
to what it was, so why should I expect to need to use a different top
level command? "

I'd like the properties documentation to show all the valid range of
values for a given property, if practical. If a 'zfs inherit'/'zfs set'
alias was created, one of these values would be 'inherit' or 'inherited'
or 'default'. On a related note, the documentation (same URL below) for
the "normalization" property is missing the list of valid values besides
"none".

In regards to potential edge/corner(?) case conflicts with the share*
properties, the documentation at
http://docs.sun.com/app/docs/doc/817-2271/gazss?l=en&a=view says:

Under sharenfs:
If set to on, the zfs share command is invoked with no options.
Otherwise, the zfs share command is invoked with options equivalent to
the contents of this property.

Under sharesmb:
If the property is set to on, the sharemgr command is invoked with no
options. Otherwise, the sharemgr command is invoked with options that
are equivalent to the contents of this property.

This tells me these two properties are already in effect aliases of
other commands. That's what I'm suggesting in 'zfs set -r
property=inherited'...when a zfs set command is issued with 'inherited'
in the value
field, the zfs inherit "command is invoked with options equivalent to
the contents of this property". In pseudo-code:

//ZFS SET code
IF value="inherited" THEN invoke zfs inherit "equivalent options"
ELSE IF property="sharenfs" THEN invoke zfs share "equivalent options"
ELSE IF property="sharesmb" THEN invoke sharemgr "equivalent options"
ELSE IF ...<other properties>
END IF

The value 'inherited' becomes a special value available for all the
properties currently supported by the 'zfs inherit' command. Sharenfs
and sharesmb should still work as they currently do because
zfs set sharenfs=inherited
zfs set sharesmb=inherited
do not at present appear to have valid values in the commands.
"inherited" can be treated as a special value just like "on" and "off".
(On and off are described this way in the sharenfs documentation I
copied above.)

Thanks,

-hk

[Andrey V. Elsukov]

Post by Haudy Kazemi
I recently asked myself this question: Is it possible to unset ZFS
properties? Or reset one to its default state without looking up what
that default state is?

I have another question: is it possible to set ZFS properties without
inheritance to all descendant datasets?

I'll try to describe my situation. I'm FreeBSD user and for example
i have following datasets:
zroot/usr
zroot/usr/home
zroot/usr/home/user1
zroot/usr/home/user2
...
zroot/usr/local
zroot/usr/src
zroot/usr/ports
zroot/usr/ports/distfiles
zroot/usr/ports/packages

After some initial configuration i want to set readonly property
to the `zroot/usr` dataset. And there is problem :)
In this situation it will be very useful to have ability to set
properties without inheritance. For example:

# zfs set -R readonly=on zroot/usr

and readonly property will be set only to zroot/usr, but not to all
descendants. Or maybe this functional is already implemented?

[Victor Latushkin]

Post by Andrey V. Elsukov

Post by Haudy Kazemi
I recently asked myself this question: Is it possible to unset ZFS
properties? Or reset one to its default state without looking up what
that default state is?

I have another question: is it possible to set ZFS properties without
inheritance to all descendant datasets?
I'll try to describe my situation. I'm FreeBSD user and for example
zroot/usr
zroot/usr/home
zroot/usr/home/user1
zroot/usr/home/user2
...
zroot/usr/local
zroot/usr/src
zroot/usr/ports
zroot/usr/ports/distfiles
zroot/usr/ports/packages
After some initial configuration i want to set readonly property
to the `zroot/usr` dataset. And there is problem :)

And the problem is that you mix two datasets with different intended uses into
one hierarchy. You can better do split these two datasets into separate
hierarchies but combine them as you want in the filesystem namespace, something
like this:

zfs create zroot/usr
zfs set mountpoint=$USR
zfs create -o mountpoint=$USR/home zroot/home
zfs create zroot/home/user1
zfs create zroot/home/user2
zfs set readonly=on zroot/usr

victor