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.
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.
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
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
