Darren J Moffat
2007-Sep-03 16:10 UTC
[zfs-discuss] "inherit" vs "clone" and property values.
I had expected that when I clone''d a snapshot properties like "compression" would be "copied" over to the clone from the parent snapshot regardless of the inheritance implied from the place in the tree. Particularly since ''zfs clone'' doesn''t have the ability to set options. However it seems this doesn''t happen. For example: braveheart# zfs create -o compression=on tank/x braveheart# zfs snapshot tank/x at s1 braveheart# zfs clone tank/x at s1 tank/y braveheart# zfs get compression tank/y NAME PROPERTY VALUE SOURCE tank/y compression off default Versus: braveheart# zfs clone tank/x at s1 tank/x/y braveheart# zfs get compression tank/x/y NAME PROPERTY VALUE SOURCE tank/x/y compression on inherited from tank/x I assume this is the intended behaviour and not a bug ? That is that inheritance follows only the "tree names" not the clone parent. However if I do this for ZVOL rather than a filesystem I do get the behaviour I expected for the volblocksize (but still not compression). It wasn''t intuitive to me and it is the opposite of the behaviour I need to arrange for the "encryption", "keytype" and "wrappedkey" properties for ZFS Crypto support. For clones both "encryption", "keytype" and "wrappedkey" can not be set for the clone and they must be the same as the clone_parent. I can code this in myself (I already have in place and working the ability to create the per-dataset keys when a normal dataset is created) but I expected this to have been done automatically for clones. -- Darren J Moffat
Eric Schrock
2007-Sep-03 16:54 UTC
[zfs-discuss] "inherit" vs "clone" and property values.
Yes, this would be useful. See: 6364688 method to preserve properties when making a clone The infrastructure is all there (zfs_clone() takes an nvlist of properties), it just hasn''t been implemented yet. Note that ''volblocksize'' is special because it is a create-time property and cannot be changed once it is set. It doesn''t make sense to ''inherit'' volblocksize from the new parent, as the resulting volume would be unusable. I believe that ''volsize'', while changeable, is also preserved with a snapshot for a similar purpose. Can the encryption properties be changed once a filesystem is created? - Eric On Mon, Sep 03, 2007 at 05:10:45PM +0100, Darren J Moffat wrote:> I had expected that when I clone''d a snapshot properties like > "compression" would be "copied" over to the clone from the parent > snapshot regardless of the inheritance implied from the place in the > tree. Particularly since ''zfs clone'' doesn''t have the ability to > set options. However it seems this doesn''t happen. > > For example: > > braveheart# zfs create -o compression=on tank/x > braveheart# zfs snapshot tank/x at s1 > braveheart# zfs clone tank/x at s1 tank/y > braveheart# zfs get compression tank/y > NAME PROPERTY VALUE SOURCE > tank/y compression off default > > Versus: > > braveheart# zfs clone tank/x at s1 tank/x/y > braveheart# zfs get compression tank/x/y > NAME PROPERTY VALUE SOURCE > tank/x/y compression on inherited from tank/x > > > I assume this is the intended behaviour and not a bug ? That is that > inheritance follows only the "tree names" not the clone parent. > > However if I do this for ZVOL rather than a filesystem I do get the > behaviour I expected for the volblocksize (but still not compression). > > It wasn''t intuitive to me and it is the opposite of the behaviour I need > to arrange for the "encryption", "keytype" and "wrappedkey" properties > for ZFS Crypto support. For clones both "encryption", "keytype" and > "wrappedkey" can not be set for the clone and they must be the same as > the clone_parent. > > I can code this in myself (I already have in place and working the > ability to create the per-dataset keys when a normal dataset is created) > but I expected this to have been done automatically for clones. > > -- > Darren J Moffat > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss-- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock
Darren J Moffat
2007-Sep-05 09:07 UTC
[zfs-discuss] "inherit" vs "clone" and property values.
Eric Schrock wrote:> Yes, this would be useful. See: > > 6364688 method to preserve properties when making a cloneThanks for that pointer. I''d say it should be the default - but then that was basically the topic of this thread :-)> The infrastructure is all there (zfs_clone() takes an nvlist of > properties), it just hasn''t been implemented yet.Yep I spotted that.> Note that ''volblocksize'' is special because it is a create-time property > and cannot be changed once it is set. It doesn''t make sense to > ''inherit'' volblocksize from the new parent, as the resulting volume > would be unusable. I believe that ''volsize'', while changeable, is also > preserved with a snapshot for a similar purpose.It is exactly because it is create-time that I used that for my comparison.> Can the encryption properties be changed once a filesystem is created?There are currently three separate properties for a dataset that deals with encryption and none of them can be changed by the end user after creation and they must all be the same in the clone. For context they are: "encryption": should be create time only since changing this changes policy and could result in a mix of clear text and cipher text. Even changes between "on" values aren''t allowed since it is too hard to rationalise about the overall security of the dataset. "keytype": This is currently create time only. In theory some future project could allow it to be changed (ie the same clear text key is available via a different key management system). For the first delivery it will be create time only. Need not be identical in the clone but see below, realistically it should always be identical in the clone [I haven''t found a real world case yet where it would be useful to have different key management but the same key value in the clone]. "wrappedkey": This is a hidden property that is an implementation artefact rather than a property exposed via zfs(1) [we may not even allow it to be exposed over the ioctl but that depends on the future of zfs send/recv with properties and is a much more complex issue ]. This is the encrypted per data set key. The clear text of this must be identical in the clone and currently I''m planning for the actual property value to be identical too. -- Darren J Moffat