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)
Haudy Kazemi wrote:> 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?zfs inherit compression tank/home/smith> ***** > 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. -- Darren J Moffat
Darren J Moffat wrote:> Haudy Kazemi wrote: >> 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? > > zfs inherit compression tank/home/smith > >> ***** >> 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. -- Andrew
Haudy Kazemi wrote:> 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? -- WBR, Andrey V. Elsukov
On 13.08.09 13:44, Andrey V. Elsukov wrote:> Haudy Kazemi wrote: >> 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 :)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
>>> >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090813/d83897e3/attachment.html>