From ahrens@sac.sfbay.sun.com Thu Sep 24 10:52:06 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8OHq4Ed028598 for ; Thu, 24 Sep 2009 10:52:05 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n8OHq2oG004088; Fri, 25 Sep 2009 01:52:03 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQH00A0HLMPC000@brm-avmta-1.central.sun.com>; Thu, 24 Sep 2009 11:52:01 -0600 (MDT) Received: from localhost.sfbay.sun.com ([129.146.17.46]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQH00IGALMO0CE0@brm-avmta-1.central.sun.com>; Thu, 24 Sep 2009 11:52:01 -0600 (MDT) Received: from localhost.sfbay.sun.com (localhost [127.0.0.1] (may be forged)) by localhost.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8OHq0KS028893; Thu, 24 Sep 2009 10:52:00 -0700 (PDT) Received: (from ahrens@localhost) by localhost.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n8OHq0wp028889; Thu, 24 Sep 2009 10:52:00 -0700 (PDT) Date: Thu, 24 Sep 2009 10:52:00 -0700 (PDT) From: Matthew Ahrens Subject: ZFS received properties [PSARC/2009/510 FastTrack timeout 09/30/2009] To: PSARC-ext@sun.com Cc: zfs-eng@sun.com Message-id: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5983 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: ZFS received properties 1.2. Name of Document Author/Supplier: Author: Tom Erickson 1.3 Date of This Document: 24 September, 2009 4. Technical Description ZFS received properties A. SUMMARY This case adds received property values to ZFS so that 'zfs receive' preserves local properties and the administrator can revert to received values if desired. Also, it adds the option to include a sent dataset's properties without also replicating its child datasets. B. PROBLEM Many customers have asked for the ability to have different properties for datasets on the disaster recovery site than on the primary site. For example, they may want to compress data on the DR site, or have a different set of NFS exports, or a different automatic snapshot policy (which is governed in the Fishworks stack by a ZFS dataset user property). To facilitate this, there should be a way of setting a property in ZFS that will not be overwritten by 'zfs receive'. Ideally, it would be possible to observe the state of this property (overridden locally vs. received) as well as revert to its received value. Also, it will be generally useful to be able to include properties in the send stream without also including child datasets. That option will be used by NDMP backup in an upcoming Fishworks project. C. PROPOSED SOLUTION C.1. Overview A ZFS dataset property can now have both a local and a received value. A newly received dataset uses received property values by default until they are explicitly overridden by setting or inheriting properties locally with 'zfs set' or 'zfs inherit'. However, since the received values still exist, it remains possible to activate them again by clearing the local settings. The 'zfs receive' command now overwrites any existing received values but leaves the locally set values intact. (Previously all local settings were overwritten.) Values inherited locally from a parent dataset also override received values. That is, the effects of 'zfs inherit' are also left intact by 'zfs receive'. The 'zfs inherit' subcommand has a new -S option to clear any locally set value or explicit inheritance and revert to the received value. (In the case where there is no received value, the property is implicitly inherited.) The 'zfs get' subcommand also adds a non-default "received" column, making it possible to display received property values even when they are overridden locally. C.2. Version Compatibility Using this feature requires a pool upgrade. Properties received on earlier pool versions will be cleared by the first 'zfs receive' after the upgrade, otherwise the older received values would override the newly received values just as if the older values had been set locally. Properties set locally by 'zfs set' on earlier pool versions will also be cleared by the first 'zfs receive' after the upgrade, since they are indistinguishable from pre-upgrade received properties. That is, the first 'zfs receive' after the upgrade will have the same behavior as 'zfs receive' before the upgrade (not preserving local properties). C.3. Changes to Existing Subcommands C.3.1 zfs get C.3.1.1 zfs get -o The -o option to specify the set of fields to display now takes some new option arguments. The previous syntax: [-o field[,field]...] is now [-o all | field[,field]...] and field is expanded to include a new "received" value: -o Set of fields to display. One of "name,property,value, received,source". Default is "name,property,value,source". "all" is an alias for all five. C.3.1.2 zfs get -s The -s option to specify the set of allowed sources now takes an additional "received" source: -s Set of sources to allow. One of "local,default,inherited,received,temporary,none". Default is all six. For example, to see all received properties, whether or not they are overridden locally: # zfs get -o all -s local,inherited,received all srecv.dst/tom NAME PROPERTY VALUE RECEIVED SOURCE srecv.dst/tom compression on off local srecv.dst/tom tom:color blue red local srecv.dst/tom tom:word apple apple received srecv.dst/tom tom:shape triangle square inherited from srecv.dst # The effective value is displayed under the VALUE column, and the source of that value under the SOURCE column. If desired, the administrator can revert to the value under the RECEIVED column using 'zfs inherit -S'. C.3.2 zfs inherit -S The 'zfs inherit' subcommand now takes a -S option, which reverts a property to its received value (if any) by clearing any locally set value. If there is no received value, then 'zfs inherit -S' has exactly the same behavior as inherit without the -S option. Note that 'zfs inherit' without the -S option now overrides the received value by explicitly inheriting from the parent dataset. In the example above, the tom:shape property inherited from the parent dataset can still be reverted to the received value as follows: # zfs inherit -S tom:shape srecv.dst/tom # zfs get -o all tom:shape srecv.dst/tom NAME PROPERTY VALUE RECEIVED SOURCE srecv.dst/tom tom:shape square square received # C.3.3 zfs send -p The 'zfs send' subcommand now takes a -p option that is like 'zfs send -R' in that it includes properties, but it does not include child datasets. Stability This case requests patch/micro release binding. The new interfaces are Committed. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From edward.pilatowicz@sun.com Thu Sep 24 11:30:59 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8OIUx8m029807 for ; Thu, 24 Sep 2009 11:30:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8OIUwZa016738; Thu, 24 Sep 2009 11:30:59 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQH00C0HNFN1W00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 24 Sep 2009 11:30:59 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQH008BPNFMJR40@nwk-avmta-1.sfbay.Sun.COM>; Thu, 24 Sep 2009 11:30:58 -0700 (PDT) Received: from eng.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8OIUwdq034976; Thu, 24 Sep 2009 11:30:58 -0700 (PDT) Date: Thu, 24 Sep 2009 11:30:58 -0700 From: Edward Pilatowicz Subject: Re: ZFS received properties [PSARC/2009/510 FastTrack timeout 09/30/2009] In-reply-to: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> To: Matthew Ahrens Cc: PSARC-ext@sun.com, zfs-eng@sun.com Message-id: <20090924183058.GC364607@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 6577 if you have a pool that has zfs received filesystems, then you set overriding local properties, and then you zfs send those filesystems, i assume that only the previously received properties (and not the new locally properties) are transmitted in the send stream? ed On Thu, Sep 24, 2009 at 10:52:00AM -0700, Matthew Ahrens wrote: > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > ZFS received properties > 1.2. Name of Document Author/Supplier: > Author: Tom Erickson > 1.3 Date of This Document: > 24 September, 2009 > 4. Technical Description > > ZFS received properties > > A. SUMMARY > > This case adds received property values to ZFS so that 'zfs receive' > preserves local properties and the administrator can revert to received > values if desired. Also, it adds the option to include a sent dataset's > properties without also replicating its child datasets. > > B. PROBLEM > > Many customers have asked for the ability to have different properties > for datasets on the disaster recovery site than on the primary site. For > example, they may want to compress data on the DR site, or have a > different set of NFS exports, or a different automatic snapshot policy > (which is governed in the Fishworks stack by a ZFS dataset user > property). To facilitate this, there should be a way of setting a > property in ZFS that will not be overwritten by 'zfs receive'. Ideally, > it would be possible to observe the state of this property (overridden > locally vs. received) as well as revert to its received value. > > Also, it will be generally useful to be able to include properties in > the send stream without also including child datasets. That option will > be used by NDMP backup in an upcoming Fishworks project. > > C. PROPOSED SOLUTION > > C.1. Overview > > A ZFS dataset property can now have both a local and a received value. > A newly received dataset uses received property values by default until > they are explicitly overridden by setting or inheriting properties > locally with 'zfs set' or 'zfs inherit'. However, since the received > values still exist, it remains possible to activate them again by > clearing the local settings. The 'zfs receive' command now overwrites > any existing received values but leaves the locally set values intact. > (Previously all local settings were overwritten.) Values inherited > locally from a parent dataset also override received values. That is, > the effects of 'zfs inherit' are also left intact by 'zfs receive'. The > 'zfs inherit' subcommand has a new -S option to clear any locally set > value or explicit inheritance and revert to the received value. (In the > case where there is no received value, the property is implicitly > inherited.) The 'zfs get' subcommand also adds a non-default "received" > column, making it possible to display received property values even when > they are overridden locally. > > C.2. Version Compatibility > > Using this feature requires a pool upgrade. Properties received on > earlier pool versions will be cleared by the first 'zfs receive' after > the upgrade, otherwise the older received values would override the > newly received values just as if the older values had been set locally. > Properties set locally by 'zfs set' on earlier pool versions will also > be cleared by the first 'zfs receive' after the upgrade, since they are > indistinguishable from pre-upgrade received properties. That is, the > first 'zfs receive' after the upgrade will have the same behavior as > 'zfs receive' before the upgrade (not preserving local properties). > > C.3. Changes to Existing Subcommands > > C.3.1 zfs get > C.3.1.1 zfs get -o > > The -o option to specify the set of fields to display now takes some new > option arguments. The previous syntax: > > [-o field[,field]...] > > is now > > [-o all | field[,field]...] > > and field is expanded to include a new "received" value: > > -o Set of fields to display. One of "name,property,value, > received,source". Default is "name,property,value,source". > "all" is an alias for all five. > > C.3.1.2 zfs get -s > > The -s option to specify the set of allowed sources now takes an > additional "received" source: > > -s Set of sources to allow. One of > "local,default,inherited,received,temporary,none". > Default is all six. > > For example, to see all received properties, whether or not they are > overridden locally: > > # zfs get -o all -s local,inherited,received all srecv.dst/tom > NAME PROPERTY VALUE RECEIVED SOURCE > srecv.dst/tom compression on off local > srecv.dst/tom tom:color blue red local > srecv.dst/tom tom:word apple apple received > srecv.dst/tom tom:shape triangle square inherited from srecv.dst > # > > The effective value is displayed under the VALUE column, and the source > of that value under the SOURCE column. If desired, the administrator can > revert to the value under the RECEIVED column using 'zfs inherit -S'. > > C.3.2 zfs inherit -S > > The 'zfs inherit' subcommand now takes a -S option, which reverts a > property to its received value (if any) by clearing any locally set > value. If there is no received value, then 'zfs inherit -S' has exactly > the same behavior as inherit without the -S option. > > Note that 'zfs inherit' without the -S option now overrides the received > value by explicitly inheriting from the parent dataset. In the example > above, the tom:shape property inherited from the parent dataset can > still be reverted to the received value as follows: > > # zfs inherit -S tom:shape srecv.dst/tom > # zfs get -o all tom:shape srecv.dst/tom > NAME PROPERTY VALUE RECEIVED SOURCE > srecv.dst/tom tom:shape square square received > # > > C.3.3 zfs send -p > > The 'zfs send' subcommand now takes a -p option that is like > 'zfs send -R' in that it includes properties, but it does not include > child datasets. > > Stability > > This case requests patch/micro release binding. The new interfaces are > Committed. > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open From Darren.Moffat@sun.com Thu Sep 24 12:53:29 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8OJrSU9001449 for ; Thu, 24 Sep 2009 12:53:28 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id n8OJrQBl016026; Thu, 24 Sep 2009 12:53:28 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQH00E1DR94T800@nwk-avmta-2.sfbay.sun.com>; Thu, 24 Sep 2009 12:53:28 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQH008A0R92ZU80@nwk-avmta-2.sfbay.sun.com>; Thu, 24 Sep 2009 12:53:27 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8OJrQ5f011044; Thu, 24 Sep 2009 19:53:26 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQH00A00QXZ5Y00@fe-emea-09.sun.com>; Thu, 24 Sep 2009 20:53:20 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQH0019GR8WB870@fe-emea-09.sun.com>; Thu, 24 Sep 2009 20:53:20 +0100 (BST) Date: Thu, 24 Sep 2009 20:53:20 +0100 From: Darren J Moffat Subject: Re: ZFS received properties [PSARC/2009/510 FastTrack timeout 09/30/2009] In-reply-to: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> Sender: Darren.Moffat@sun.com To: Matthew Ahrens Cc: PSARC-ext@sun.com, zfs-eng@sun.com Message-id: <4ABBCE30.6070901@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 450 I think there is in impact to ZFS Crypto and potentially other create time only properties here. Create time only properties can't change so they can't be "reverted" either. This is especially true of the encryption property which is really hiding quite a lot of complex infrastructure behind it. Maybe this isn't actually an issue but I didn't see any mention of special treatment of create time only dataset properties. -- Darren J Moffat From Matthew.Ahrens@sun.com Thu Sep 24 23:21:46 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8P6Lkrs012724 for ; Thu, 24 Sep 2009 23:21:46 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8P6Lhp7016805; Fri, 25 Sep 2009 07:21:45 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQI00E05KC7V600@nwk-avmta-2.sfbay.sun.com>; Thu, 24 Sep 2009 23:21:43 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQI006DWKC7DU40@nwk-avmta-2.sfbay.sun.com>; Thu, 24 Sep 2009 23:21:43 -0700 (PDT) Received: from stationary.local (punchin-ahrens.SFBay.Sun.COM [10.7.251.178]) by zion.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8P6Kd2Z010585; Fri, 25 Sep 2009 06:20:39 +0000 (GMT) Date: Thu, 24 Sep 2009 23:21:38 -0700 From: Matthew Ahrens Subject: Re: ZFS received properties [PSARC/2009/510 FastTrack timeout 09/30/2009] In-reply-to: <4ABBCE30.6070901@Sun.COM> To: Darren J Moffat Cc: Matthew Ahrens , PSARC-ext@sun.com, zfs-eng@sun.com Message-id: <4ABC6172.8090701@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> <4ABBCE30.6070901@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 599 Darren J Moffat wrote: > I think there is in impact to ZFS Crypto and potentially other create > time only properties here. Create time only properties can't change so > they can't be "reverted" either. This is especially true of the > encryption property which is really hiding quite a lot of complex > infrastructure behind it. > > Maybe this isn't actually an issue but I didn't see any mention of > special treatment of create time only dataset properties. I don't see how this is an issue. Since create-time properties can't be changed, nothing in this case applies to them. --matt From tomee@cabochon.sfbay.sun.com Fri Sep 25 13:57:22 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8PKvLRv020825 for ; Fri, 25 Sep 2009 13:57:21 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8PKvHFN015558; Fri, 25 Sep 2009 21:57:19 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQJ00K03OVI8E00@brm-avmta-1.central.sun.com>; Fri, 25 Sep 2009 14:57:18 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQJ00JITOVI4N10@brm-avmta-1.central.sun.com>; Fri, 25 Sep 2009 14:57:18 -0600 (MDT) Received: from cabochon.sfbay.sun.com (cabochon.SFBay.Sun.COM [129.146.229.245]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8PKvHkG047833; Fri, 25 Sep 2009 13:57:17 -0700 (PDT) Received: from cabochon.sfbay.sun.com (cabochon.local [127.0.0.1]) by cabochon.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8PKs6hV026075; Fri, 25 Sep 2009 13:54:06 -0700 (PDT) Received: (from tomee@localhost) by cabochon.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n8PKs61C026074; Fri, 25 Sep 2009 13:54:06 -0700 (PDT) Date: Fri, 25 Sep 2009 13:54:06 -0700 From: Tom Erickson Subject: Re: ZFS received properties [PSARC/2009/510 FastTrack timeout 09/30/2009] In-reply-to: <20090924183058.GC364607@eng.sun.com> To: Edward Pilatowicz Cc: Matthew Ahrens , PSARC-ext@sun.com, zfs-eng@sun.com Message-id: <20090925205405.GD21531@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> <20090924183058.GC364607@eng.sun.com> User-Agent: Mutt/1.5.14 (2007-02-12) Status: RO Content-Length: 7303 On Thu, Sep 24, 2009 at 11:30:58AM -0700, Edward Pilatowicz wrote: > if you have a pool that has zfs received filesystems, then you set > overriding local properties, and then you zfs send those filesystems, i > assume that only the previously received properties (and not the new > locally properties) are transmitted in the send stream? > > ed > 'zfs send -R' and 'zfs send -p' send any property set on that file system, whether set locally or by 'zfs receive'. In the case where there is both a local and a received setting, I assumed that we would prefer to send the local setting over the received setting. Can you describe the use case for preferring the received setting? Thanks, Tom > On Thu, Sep 24, 2009 at 10:52:00AM -0700, Matthew Ahrens wrote: > > > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > > This information is Copyright 2009 Sun Microsystems > > 1. Introduction > > 1.1. Project/Component Working Name: > > ZFS received properties > > 1.2. Name of Document Author/Supplier: > > Author: Tom Erickson > > 1.3 Date of This Document: > > 24 September, 2009 > > 4. Technical Description > > > > ZFS received properties > > > > A. SUMMARY > > > > This case adds received property values to ZFS so that 'zfs receive' > > preserves local properties and the administrator can revert to received > > values if desired. Also, it adds the option to include a sent dataset's > > properties without also replicating its child datasets. > > > > B. PROBLEM > > > > Many customers have asked for the ability to have different properties > > for datasets on the disaster recovery site than on the primary site. For > > example, they may want to compress data on the DR site, or have a > > different set of NFS exports, or a different automatic snapshot policy > > (which is governed in the Fishworks stack by a ZFS dataset user > > property). To facilitate this, there should be a way of setting a > > property in ZFS that will not be overwritten by 'zfs receive'. Ideally, > > it would be possible to observe the state of this property (overridden > > locally vs. received) as well as revert to its received value. > > > > Also, it will be generally useful to be able to include properties in > > the send stream without also including child datasets. That option will > > be used by NDMP backup in an upcoming Fishworks project. > > > > C. PROPOSED SOLUTION > > > > C.1. Overview > > > > A ZFS dataset property can now have both a local and a received value. > > A newly received dataset uses received property values by default until > > they are explicitly overridden by setting or inheriting properties > > locally with 'zfs set' or 'zfs inherit'. However, since the received > > values still exist, it remains possible to activate them again by > > clearing the local settings. The 'zfs receive' command now overwrites > > any existing received values but leaves the locally set values intact. > > (Previously all local settings were overwritten.) Values inherited > > locally from a parent dataset also override received values. That is, > > the effects of 'zfs inherit' are also left intact by 'zfs receive'. The > > 'zfs inherit' subcommand has a new -S option to clear any locally set > > value or explicit inheritance and revert to the received value. (In the > > case where there is no received value, the property is implicitly > > inherited.) The 'zfs get' subcommand also adds a non-default "received" > > column, making it possible to display received property values even when > > they are overridden locally. > > > > C.2. Version Compatibility > > > > Using this feature requires a pool upgrade. Properties received on > > earlier pool versions will be cleared by the first 'zfs receive' after > > the upgrade, otherwise the older received values would override the > > newly received values just as if the older values had been set locally. > > Properties set locally by 'zfs set' on earlier pool versions will also > > be cleared by the first 'zfs receive' after the upgrade, since they are > > indistinguishable from pre-upgrade received properties. That is, the > > first 'zfs receive' after the upgrade will have the same behavior as > > 'zfs receive' before the upgrade (not preserving local properties). > > > > C.3. Changes to Existing Subcommands > > > > C.3.1 zfs get > > C.3.1.1 zfs get -o > > > > The -o option to specify the set of fields to display now takes some new > > option arguments. The previous syntax: > > > > [-o field[,field]...] > > > > is now > > > > [-o all | field[,field]...] > > > > and field is expanded to include a new "received" value: > > > > -o Set of fields to display. One of "name,property,value, > > received,source". Default is "name,property,value,source". > > "all" is an alias for all five. > > > > C.3.1.2 zfs get -s > > > > The -s option to specify the set of allowed sources now takes an > > additional "received" source: > > > > -s Set of sources to allow. One of > > "local,default,inherited,received,temporary,none". > > Default is all six. > > > > For example, to see all received properties, whether or not they are > > overridden locally: > > > > # zfs get -o all -s local,inherited,received all srecv.dst/tom > > NAME PROPERTY VALUE RECEIVED SOURCE > > srecv.dst/tom compression on off local > > srecv.dst/tom tom:color blue red local > > srecv.dst/tom tom:word apple apple received > > srecv.dst/tom tom:shape triangle square inherited from srecv.dst > > # > > > > The effective value is displayed under the VALUE column, and the source > > of that value under the SOURCE column. If desired, the administrator can > > revert to the value under the RECEIVED column using 'zfs inherit -S'. > > > > C.3.2 zfs inherit -S > > > > The 'zfs inherit' subcommand now takes a -S option, which reverts a > > property to its received value (if any) by clearing any locally set > > value. If there is no received value, then 'zfs inherit -S' has exactly > > the same behavior as inherit without the -S option. > > > > Note that 'zfs inherit' without the -S option now overrides the received > > value by explicitly inheriting from the parent dataset. In the example > > above, the tom:shape property inherited from the parent dataset can > > still be reverted to the received value as follows: > > > > # zfs inherit -S tom:shape srecv.dst/tom > > # zfs get -o all tom:shape srecv.dst/tom > > NAME PROPERTY VALUE RECEIVED SOURCE > > srecv.dst/tom tom:shape square square received > > # > > > > C.3.3 zfs send -p > > > > The 'zfs send' subcommand now takes a -p option that is like > > 'zfs send -R' in that it includes properties, but it does not include > > child datasets. > > > > Stability > > > > This case requests patch/micro release binding. The new interfaces are > > Committed. > > > > 6. Resources and Schedule > > 6.4. Steering Committee requested information > > 6.4.1. Consolidation C-team Name: > > ON > > 6.5. ARC review type: FastTrack > > 6.6. ARC Exposure: open From edward.pilatowicz@sun.com Sat Sep 26 09:11:28 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8QGBQuZ021062 for ; Sat, 26 Sep 2009 09:11:27 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8QGBLEO024443; Sat, 26 Sep 2009 17:11:25 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQL00B076B0BW00@brm-avmta-1.central.sun.com>; Sat, 26 Sep 2009 10:11:24 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQL007DO6AZO130@brm-avmta-1.central.sun.com>; Sat, 26 Sep 2009 10:11:23 -0600 (MDT) Received: from eng.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8QGBLcU005253; Sat, 26 Sep 2009 09:11:21 -0700 (PDT) Date: Sat, 26 Sep 2009 09:11:21 -0700 From: Edward Pilatowicz Subject: Re: ZFS received properties [PSARC/2009/510 FastTrack timeout 09/30/2009] In-reply-to: <20090925205405.GD21531@eng.sun.com> To: Tom Erickson Cc: Matthew Ahrens , PSARC-ext@sun.com, zfs-eng@sun.com Message-id: <20090926161121.GA119999@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> <20090924183058.GC364607@eng.sun.com> <20090925205405.GD21531@eng.sun.com> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 8298 On Fri, Sep 25, 2009 at 01:54:06PM -0700, Tom Erickson wrote: > On Thu, Sep 24, 2009 at 11:30:58AM -0700, Edward Pilatowicz wrote: > > if you have a pool that has zfs received filesystems, then you set > > overriding local properties, and then you zfs send those filesystems, i > > assume that only the previously received properties (and not the new > > locally properties) are transmitted in the send stream? > > > > ed > > > 'zfs send -R' and 'zfs send -p' send any property set on that file > system, whether set locally or by 'zfs receive'. In the case where there > is both a local and a received setting, I assumed that we would prefer > to send the local setting over the received setting. Can you describe > the use case for preferring the received setting? > > Thanks, > Tom > you mentioned that the common use case for this feature is backup and restore. i was assuming if you're restoring filesystems to a client you'd want them to be restored with their original properties, not the local properties used on the backup server. hence i was guessing that send would ignore the local properties. (otherwise, if a client had compression disabled and shares exported, and the server had compression enabled and nothing exported, and you restored the client, you would have to manually disable compression and re-enabled all your shares after the restore was done, right?) ed > > On Thu, Sep 24, 2009 at 10:52:00AM -0700, Matthew Ahrens wrote: > > > > > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > > > This information is Copyright 2009 Sun Microsystems > > > 1. Introduction > > > 1.1. Project/Component Working Name: > > > ZFS received properties > > > 1.2. Name of Document Author/Supplier: > > > Author: Tom Erickson > > > 1.3 Date of This Document: > > > 24 September, 2009 > > > 4. Technical Description > > > > > > ZFS received properties > > > > > > A. SUMMARY > > > > > > This case adds received property values to ZFS so that 'zfs receive' > > > preserves local properties and the administrator can revert to received > > > values if desired. Also, it adds the option to include a sent dataset's > > > properties without also replicating its child datasets. > > > > > > B. PROBLEM > > > > > > Many customers have asked for the ability to have different properties > > > for datasets on the disaster recovery site than on the primary site. For > > > example, they may want to compress data on the DR site, or have a > > > different set of NFS exports, or a different automatic snapshot policy > > > (which is governed in the Fishworks stack by a ZFS dataset user > > > property). To facilitate this, there should be a way of setting a > > > property in ZFS that will not be overwritten by 'zfs receive'. Ideally, > > > it would be possible to observe the state of this property (overridden > > > locally vs. received) as well as revert to its received value. > > > > > > Also, it will be generally useful to be able to include properties in > > > the send stream without also including child datasets. That option will > > > be used by NDMP backup in an upcoming Fishworks project. > > > > > > C. PROPOSED SOLUTION > > > > > > C.1. Overview > > > > > > A ZFS dataset property can now have both a local and a received value. > > > A newly received dataset uses received property values by default until > > > they are explicitly overridden by setting or inheriting properties > > > locally with 'zfs set' or 'zfs inherit'. However, since the received > > > values still exist, it remains possible to activate them again by > > > clearing the local settings. The 'zfs receive' command now overwrites > > > any existing received values but leaves the locally set values intact. > > > (Previously all local settings were overwritten.) Values inherited > > > locally from a parent dataset also override received values. That is, > > > the effects of 'zfs inherit' are also left intact by 'zfs receive'. The > > > 'zfs inherit' subcommand has a new -S option to clear any locally set > > > value or explicit inheritance and revert to the received value. (In the > > > case where there is no received value, the property is implicitly > > > inherited.) The 'zfs get' subcommand also adds a non-default "received" > > > column, making it possible to display received property values even when > > > they are overridden locally. > > > > > > C.2. Version Compatibility > > > > > > Using this feature requires a pool upgrade. Properties received on > > > earlier pool versions will be cleared by the first 'zfs receive' after > > > the upgrade, otherwise the older received values would override the > > > newly received values just as if the older values had been set locally. > > > Properties set locally by 'zfs set' on earlier pool versions will also > > > be cleared by the first 'zfs receive' after the upgrade, since they are > > > indistinguishable from pre-upgrade received properties. That is, the > > > first 'zfs receive' after the upgrade will have the same behavior as > > > 'zfs receive' before the upgrade (not preserving local properties). > > > > > > C.3. Changes to Existing Subcommands > > > > > > C.3.1 zfs get > > > C.3.1.1 zfs get -o > > > > > > The -o option to specify the set of fields to display now takes some new > > > option arguments. The previous syntax: > > > > > > [-o field[,field]...] > > > > > > is now > > > > > > [-o all | field[,field]...] > > > > > > and field is expanded to include a new "received" value: > > > > > > -o Set of fields to display. One of "name,property,value, > > > received,source". Default is "name,property,value,source". > > > "all" is an alias for all five. > > > > > > C.3.1.2 zfs get -s > > > > > > The -s option to specify the set of allowed sources now takes an > > > additional "received" source: > > > > > > -s Set of sources to allow. One of > > > "local,default,inherited,received,temporary,none". > > > Default is all six. > > > > > > For example, to see all received properties, whether or not they are > > > overridden locally: > > > > > > # zfs get -o all -s local,inherited,received all srecv.dst/tom > > > NAME PROPERTY VALUE RECEIVED SOURCE > > > srecv.dst/tom compression on off local > > > srecv.dst/tom tom:color blue red local > > > srecv.dst/tom tom:word apple apple received > > > srecv.dst/tom tom:shape triangle square inherited from srecv.dst > > > # > > > > > > The effective value is displayed under the VALUE column, and the source > > > of that value under the SOURCE column. If desired, the administrator can > > > revert to the value under the RECEIVED column using 'zfs inherit -S'. > > > > > > C.3.2 zfs inherit -S > > > > > > The 'zfs inherit' subcommand now takes a -S option, which reverts a > > > property to its received value (if any) by clearing any locally set > > > value. If there is no received value, then 'zfs inherit -S' has exactly > > > the same behavior as inherit without the -S option. > > > > > > Note that 'zfs inherit' without the -S option now overrides the received > > > value by explicitly inheriting from the parent dataset. In the example > > > above, the tom:shape property inherited from the parent dataset can > > > still be reverted to the received value as follows: > > > > > > # zfs inherit -S tom:shape srecv.dst/tom > > > # zfs get -o all tom:shape srecv.dst/tom > > > NAME PROPERTY VALUE RECEIVED SOURCE > > > srecv.dst/tom tom:shape square square received > > > # > > > > > > C.3.3 zfs send -p > > > > > > The 'zfs send' subcommand now takes a -p option that is like > > > 'zfs send -R' in that it includes properties, but it does not include > > > child datasets. > > > > > > Stability > > > > > > This case requests patch/micro release binding. The new interfaces are > > > Committed. > > > > > > 6. Resources and Schedule > > > 6.4. Steering Committee requested information > > > 6.4.1. Consolidation C-team Name: > > > ON > > > 6.5. ARC review type: FastTrack > > > 6.6. ARC Exposure: open From tomee@cabochon.sfbay.sun.com Mon Sep 28 16:07:41 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8SN7fRx004076 for ; Mon, 28 Sep 2009 16:07:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8SN7dMY006042; Mon, 28 Sep 2009 17:07:40 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQP0010FEWSA600@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Sep 2009 16:07:40 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQP00FJ8EWRYHC0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Sep 2009 16:07:39 -0700 (PDT) Received: from cabochon.sfbay.sun.com (cabochon.SFBay.Sun.COM [129.146.229.245]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8SN7cvH004017; Mon, 28 Sep 2009 16:07:38 -0700 (PDT) Received: from cabochon.sfbay.sun.com (cabochon.local [127.0.0.1]) by cabochon.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8SN4MjC026946; Mon, 28 Sep 2009 16:04:22 -0700 (PDT) Received: (from tomee@localhost) by cabochon.sfbay.sun.com (8.14.3+Sun/8.14.3/Submit) id n8SN4MOa026945; Mon, 28 Sep 2009 16:04:22 -0700 (PDT) Date: Mon, 28 Sep 2009 16:04:22 -0700 From: Tom Erickson Subject: Re: ZFS received properties [PSARC/2009/510 FastTrack timeout 09/30/2009] In-reply-to: <20090926161121.GA119999@eng.sun.com> To: Edward Pilatowicz Cc: Tom Erickson , Matthew Ahrens , PSARC-ext@sun.com, zfs-eng@sun.com Message-id: <20090928230421.GA26940@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> <20090924183058.GC364607@eng.sun.com> <20090925205405.GD21531@eng.sun.com> <20090926161121.GA119999@eng.sun.com> User-Agent: Mutt/1.5.14 (2007-02-12) Status: RO Content-Length: 9386 On Sat, Sep 26, 2009 at 09:11:21AM -0700, Edward Pilatowicz wrote: > On Fri, Sep 25, 2009 at 01:54:06PM -0700, Tom Erickson wrote: > > On Thu, Sep 24, 2009 at 11:30:58AM -0700, Edward Pilatowicz wrote: > > > if you have a pool that has zfs received filesystems, then you set > > > overriding local properties, and then you zfs send those filesystems, i > > > assume that only the previously received properties (and not the new > > > locally properties) are transmitted in the send stream? > > > > > > ed > > > > > 'zfs send -R' and 'zfs send -p' send any property set on that file > > system, whether set locally or by 'zfs receive'. In the case where there > > is both a local and a received setting, I assumed that we would prefer > > to send the local setting over the received setting. Can you describe > > the use case for preferring the received setting? > > > > Thanks, > > Tom > > > > you mentioned that the common use case for this feature is backup and > restore. i was assuming if you're restoring filesystems to a client > you'd want them to be restored with their original properties, not the > local properties used on the backup server. hence i was guessing that > send would ignore the local properties. (otherwise, if a client had > compression disabled and shares exported, and the server had compression > enabled and nothing exported, and you restored the client, you would > have to manually disable compression and re-enabled all your shares > after the restore was done, right?) > > ed > That sounds like a good thing to be able to do, but it would be confusing if it was the default behavior. Right now, 'zfs send -R' sends the property values that are currently active on the system, the same values you see with 'zfs get'. Doing something else would be hard to explain unless the adminstrator specified an explicit option to send only received property values and no local settings. (Not to mention you need to send local properties to do the backup in the first place.) I filed CR 6886341 want a 'zfs send' option to ignore local property settings when restoring from a backup to track this as a future enhancement. Thanks, Tom > > > > On Thu, Sep 24, 2009 at 10:52:00AM -0700, Matthew Ahrens wrote: > > > > > > > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > > > > This information is Copyright 2009 Sun Microsystems > > > > 1. Introduction > > > > 1.1. Project/Component Working Name: > > > > ZFS received properties > > > > 1.2. Name of Document Author/Supplier: > > > > Author: Tom Erickson > > > > 1.3 Date of This Document: > > > > 24 September, 2009 > > > > 4. Technical Description > > > > > > > > ZFS received properties > > > > > > > > A. SUMMARY > > > > > > > > This case adds received property values to ZFS so that 'zfs receive' > > > > preserves local properties and the administrator can revert to received > > > > values if desired. Also, it adds the option to include a sent dataset's > > > > properties without also replicating its child datasets. > > > > > > > > B. PROBLEM > > > > > > > > Many customers have asked for the ability to have different properties > > > > for datasets on the disaster recovery site than on the primary site. For > > > > example, they may want to compress data on the DR site, or have a > > > > different set of NFS exports, or a different automatic snapshot policy > > > > (which is governed in the Fishworks stack by a ZFS dataset user > > > > property). To facilitate this, there should be a way of setting a > > > > property in ZFS that will not be overwritten by 'zfs receive'. Ideally, > > > > it would be possible to observe the state of this property (overridden > > > > locally vs. received) as well as revert to its received value. > > > > > > > > Also, it will be generally useful to be able to include properties in > > > > the send stream without also including child datasets. That option will > > > > be used by NDMP backup in an upcoming Fishworks project. > > > > > > > > C. PROPOSED SOLUTION > > > > > > > > C.1. Overview > > > > > > > > A ZFS dataset property can now have both a local and a received value. > > > > A newly received dataset uses received property values by default until > > > > they are explicitly overridden by setting or inheriting properties > > > > locally with 'zfs set' or 'zfs inherit'. However, since the received > > > > values still exist, it remains possible to activate them again by > > > > clearing the local settings. The 'zfs receive' command now overwrites > > > > any existing received values but leaves the locally set values intact. > > > > (Previously all local settings were overwritten.) Values inherited > > > > locally from a parent dataset also override received values. That is, > > > > the effects of 'zfs inherit' are also left intact by 'zfs receive'. The > > > > 'zfs inherit' subcommand has a new -S option to clear any locally set > > > > value or explicit inheritance and revert to the received value. (In the > > > > case where there is no received value, the property is implicitly > > > > inherited.) The 'zfs get' subcommand also adds a non-default "received" > > > > column, making it possible to display received property values even when > > > > they are overridden locally. > > > > > > > > C.2. Version Compatibility > > > > > > > > Using this feature requires a pool upgrade. Properties received on > > > > earlier pool versions will be cleared by the first 'zfs receive' after > > > > the upgrade, otherwise the older received values would override the > > > > newly received values just as if the older values had been set locally. > > > > Properties set locally by 'zfs set' on earlier pool versions will also > > > > be cleared by the first 'zfs receive' after the upgrade, since they are > > > > indistinguishable from pre-upgrade received properties. That is, the > > > > first 'zfs receive' after the upgrade will have the same behavior as > > > > 'zfs receive' before the upgrade (not preserving local properties). > > > > > > > > C.3. Changes to Existing Subcommands > > > > > > > > C.3.1 zfs get > > > > C.3.1.1 zfs get -o > > > > > > > > The -o option to specify the set of fields to display now takes some new > > > > option arguments. The previous syntax: > > > > > > > > [-o field[,field]...] > > > > > > > > is now > > > > > > > > [-o all | field[,field]...] > > > > > > > > and field is expanded to include a new "received" value: > > > > > > > > -o Set of fields to display. One of "name,property,value, > > > > received,source". Default is "name,property,value,source". > > > > "all" is an alias for all five. > > > > > > > > C.3.1.2 zfs get -s > > > > > > > > The -s option to specify the set of allowed sources now takes an > > > > additional "received" source: > > > > > > > > -s Set of sources to allow. One of > > > > "local,default,inherited,received,temporary,none". > > > > Default is all six. > > > > > > > > For example, to see all received properties, whether or not they are > > > > overridden locally: > > > > > > > > # zfs get -o all -s local,inherited,received all srecv.dst/tom > > > > NAME PROPERTY VALUE RECEIVED SOURCE > > > > srecv.dst/tom compression on off local > > > > srecv.dst/tom tom:color blue red local > > > > srecv.dst/tom tom:word apple apple received > > > > srecv.dst/tom tom:shape triangle square inherited from srecv.dst > > > > # > > > > > > > > The effective value is displayed under the VALUE column, and the source > > > > of that value under the SOURCE column. If desired, the administrator can > > > > revert to the value under the RECEIVED column using 'zfs inherit -S'. > > > > > > > > C.3.2 zfs inherit -S > > > > > > > > The 'zfs inherit' subcommand now takes a -S option, which reverts a > > > > property to its received value (if any) by clearing any locally set > > > > value. If there is no received value, then 'zfs inherit -S' has exactly > > > > the same behavior as inherit without the -S option. > > > > > > > > Note that 'zfs inherit' without the -S option now overrides the received > > > > value by explicitly inheriting from the parent dataset. In the example > > > > above, the tom:shape property inherited from the parent dataset can > > > > still be reverted to the received value as follows: > > > > > > > > # zfs inherit -S tom:shape srecv.dst/tom > > > > # zfs get -o all tom:shape srecv.dst/tom > > > > NAME PROPERTY VALUE RECEIVED SOURCE > > > > srecv.dst/tom tom:shape square square received > > > > # > > > > > > > > C.3.3 zfs send -p > > > > > > > > The 'zfs send' subcommand now takes a -p option that is like > > > > 'zfs send -R' in that it includes properties, but it does not include > > > > child datasets. > > > > > > > > Stability > > > > > > > > This case requests patch/micro release binding. The new interfaces are > > > > Committed. > > > > > > > > 6. Resources and Schedule > > > > 6.4. Steering Committee requested information > > > > 6.4.1. Consolidation C-team Name: > > > > ON > > > > 6.5. ARC review type: FastTrack > > > > 6.6. ARC Exposure: open From Matthew.Ahrens@sun.com Mon Sep 28 22:45:38 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8T5jco4010226 for ; Mon, 28 Sep 2009 22:45:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8T5jaRR013322; Tue, 29 Sep 2009 06:45:37 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQP00B09XC0UW00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Sep 2009 22:45:36 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQP0003FXC0R560@nwk-avmta-1.sfbay.Sun.COM>; Mon, 28 Sep 2009 22:45:36 -0700 (PDT) Received: from stationary.local (punchin-ahrens.SFBay.Sun.COM [10.7.251.178]) by zion.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8T5iYlF002022; Tue, 29 Sep 2009 05:44:34 +0000 (GMT) Date: Mon, 28 Sep 2009 22:45:35 -0700 From: Matthew Ahrens Subject: Re: ZFS received properties [PSARC/2009/510 FastTrack timeout 09/30/2009] In-reply-to: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> To: Matthew Ahrens Cc: PSARC-ext@sun.com, zfs-eng@sun.com Message-id: <4AC19EFF.7070802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 33 Can we get a +1? Thanks, --matt From Darren.Moffat@sun.com Tue Sep 29 02:02:27 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8T92QwM024700 for ; Tue, 29 Sep 2009 02:02:26 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n8T92LIW002808; Tue, 29 Sep 2009 10:02:23 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQQ00F0H6FYFW00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 29 Sep 2009 02:02:22 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQQ0003L6FWU3C0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 29 Sep 2009 02:02:21 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n8T92HqX000934; Tue, 29 Sep 2009 09:02:20 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KQQ0080064KOG00@fe-emea-10.sun.com>; Tue, 29 Sep 2009 10:02:11 +0100 (BST) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KQQ00A3V6EHPK40@fe-emea-10.sun.com>; Tue, 29 Sep 2009 10:01:30 +0100 (BST) Date: Tue, 29 Sep 2009 10:01:29 +0100 From: Darren J Moffat Subject: Re: ZFS received properties [PSARC/2009/510 FastTrack timeout 09/30/2009] In-reply-to: <4ABC6172.8090701@sun.com> Sender: Darren.Moffat@sun.com To: Matthew Ahrens Cc: Matthew Ahrens , PSARC-ext@sun.com, zfs-eng@sun.com Message-id: <4AC1CCE9.90401@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> <4ABBCE30.6070901@Sun.COM> <4ABC6172.8090701@sun.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090818) Status: RO Content-Length: 811 Matthew Ahrens wrote: > Darren J Moffat wrote: >> I think there is in impact to ZFS Crypto and potentially other create >> time only properties here. Create time only properties can't change >> so they can't be "reverted" either. This is especially true of the >> encryption property which is really hiding quite a lot of complex >> infrastructure behind it. >> >> Maybe this isn't actually an issue but I didn't see any mention of >> special treatment of create time only dataset properties. > > I don't see how this is an issue. Since create-time properties can't be > changed, nothing in this case applies to them. Matt clarified further offline for me with a specific example. The ZPL properties are "sticky" with the data - which is the only way to do it. So +1 from me. -- Darren J Moffat From Matthew.Ahrens@sun.com Wed Sep 30 10:22:27 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8UHMRbe023777 for ; Wed, 30 Sep 2009 10:22:27 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8UHM3mL057473; Wed, 30 Sep 2009 11:22:27 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQS0001XO9DUT00@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Sep 2009 10:22:25 -0700 (PDT) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQS00I2JO9CPY70@nwk-avmta-2.sfbay.sun.com>; Wed, 30 Sep 2009 10:22:24 -0700 (PDT) Received: from stationary.local (punchin-ahrens.SFBay.Sun.COM [10.7.251.178]) by zion.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8UHLM4S008174; Wed, 30 Sep 2009 17:21:22 +0000 (GMT) Date: Wed, 30 Sep 2009 10:22:23 -0700 From: Matthew Ahrens Subject: Re: ZFS received properties [PSARC/2009/510 FastTrack timeout 09/30/2009] In-reply-to: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> To: Matthew Ahrens Cc: PSARC-ext@sun.com, zfs-eng@sun.com Message-id: <4AC393CF.8040802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200909241752.n8OHq0wp028889@localhost.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 51 This case was approved at today's meeting. --matt