From jforte@sac.sfbay.sun.com Thu May 20 11:45:21 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KIjLQp026257 for ; Thu, 20 May 2010 11:45:21 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KIjJ7p024403; Thu, 20 May 2010 13:45:21 -0500 (CDT) 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 <0L2Q00B2ZERK1O00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 20 May 2010 11:45:20 -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 <0L2Q00LQXERKA1D0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 20 May 2010 11:45:20 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4KIjGxQ012619; Thu, 20 May 2010 11:45:17 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4KIjF8a026252; Thu, 20 May 2010 11:45:15 -0700 (PDT) Received: (from jforte@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o4KIjFEq026248; Thu, 20 May 2010 11:45:15 -0700 (PDT) Date: Thu, 20 May 2010 11:45:15 -0700 (PDT) From: John Forte Subject: SMF enhancements for zfs-based ndmp backup [PSARC/2010/186 Self Review] To: PSARC-ext@sun.com Cc: janice.chang@oracle.com Message-id: <201005201845.o4KIjFEq026248@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 5424 I am sponsoring this closed approved automatic case for Janice Chang. It adds one SMF property to an already approved fasttrack (PSARC 2010/048). Binding is minor. PSARC 2010/048 was originally submitted closed but is now open and that change to open exposure is being recorded here. If anyone feels this doesn't qualify for self review, I'll convert it to a fasttrack. - John Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: SMF enhancements for zfs-based ndmp backup 1.2. Name of Document Author/Supplier: Author: Janice Chang 1.3 Date of This Document: 19 May 2010 4. Technical Description SMF enhancements for zfs-based ndmp backup 4.1. Description The PSARC case "zfs-based ndmpd backup" (2010/048) introduced a new backup type for use with the Solaris NDMP service. Two new SMF variables were introduced in conjunction with this new backup type (see Section 4.4. of the original functional specification). Several new NDMP environment variables were also introduced in this case, including ZFS_FORCE. The current case introduces a third SMF variable, zfs-force-override. zfs-force-override is intended to allow the specification of the value of ZFS_FORCE on the server running ndmpd, thereby bypassing any value (or non-value) from the data management application (DMA) for this environment variable. As noted in Section 5.1.4. of the functional specification for PSARC 2010/048, ZFS_FORCE is "a new NDMP environment variable which forces an incremental restore where such a restore might normally fail. Its default value is 'n'." As with all other NDMP environment variables, this variable is intended to be set on the DMA (if needed); the DMA will then pass its value along to the NDMP server. ZFS_FORCE, in particular, is meant to be set at restore time only if it is deemed necessary, due to potential risks in setting the variable. (For more details, please refer to Section 5.2. of the specification.) However, certain data management applications (DMAs) do not allow NDMP environment variables to be set only at restore time (e.g., they may instead require such variables to be set at backup time. These values would later be propagated to the restore at restore time.) This could be a problem if the administrator realizes belatedly, at restore time, that the setting of ZFS_FORCE was necessary. Though a manual procedure can sometimes be used in lieu of setting ZFS_FORCE (as detailed in the original functional specification), this procedure is not always effective and can be inconvenient and unwieldy. To address the above deficiency, the current case introduces the new SMF "zfs-force-override" option, which allows the administrator to essentially set ZFS_FORCE at restore time regardless of DMA limitations. This is done by setting zfs-force-override on the NDMP server via SMF. By default, zfs-force-override will have the value "off", which will mean that it will have no effect. In this case, ndmpd will use the value of ZFS_FORCE as set by the DMA (or its default value, which is 'n'). If the value of zfs-force-override is "yes", then zfs-force-override will override ZFS_FORCE with a value of 'y'. If the value of zfs-force-override is "no", then zfs-force-override will override ZFS_FORCE with a value of 'n'. Any value other than these will be treated as if zfs-force-override were set to "off". The classification of zfs-force-override will be the same as that of the two SMF variables introduced in PSARC 2010/048. Since this classification was left out of 2010/048 inadvertently, it is now specified (for all three SMF variables) in Section 4.5. below. The current case also proposes a minor change to the previously introduced SMF variables. Instead of "force_type" and "zfs_mode", these variables will now be named "force-type" and "zfs-mode". 4.2. Bug/RFE number(s): 6944258 - Investigate alternatives to ZFS_FORCE 4.5. Interfaces Interfaces Exported Minor binding Interface Classification Comments --------------------------------------------------------------------- SMF variables Committed (This covers zfs-force-override, introduced in the NDMP service for this case, as well as force-type and zfs-mode, originally introduced in 2010/048) 4.6. Doc Impact: Proposed ndmp man page change version Set the maximum active NDMP protocol version. Valid values are currently 2, 3, and 4. The default is 4. + zfs-force-override Override the value of ZFS_FORCE. + "yes" will force a value of 'y'. + "no" will force a value of 'n'. + By default, zfs-force-override has + a value of "off" and will not override + ZFS_FORCE. + The following property can only be set when using the ndmpadm enable or ndmpadm disable command: 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From mark.carlson@oracle.com Fri May 21 10:50:24 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LHoNWl009819 for ; Fri, 21 May 2010 10:50:24 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LHoLsM016476 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 12:50:23 -0500 (CDT) 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 <0L2S0021N6VZ7Z00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 10:50:23 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S0058O6VYVL80@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 10:50:22 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4LHoL6m008555; Fri, 21 May 2010 17:50:21 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4LGKEN7024810; Fri, 21 May 2010 17:50:19 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 288720181274464213; Fri, 21 May 2010 10:50:13 -0700 Received: from [192.168.1.2] (/75.226.217.154) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 10:50:12 -0700 Date: Fri, 21 May 2010 11:50:02 -0600 From: Mark A Carlson Subject: Re: SMF enhancements for zfs-based ndmp backup [PSARC/2010/186 Self Review] In-reply-to: <201005201845.o4KIjFEq026248@sac.sfbay.sun.com> To: John Forte Cc: "PSARC-ext@sun.com" , "janice.chang@oracle.com" Message-id: MIME-version: 1.0 X-Mailer: iPad Mail (7B367) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BF6C7DC.013D:SCFMA4539814,ss=1,fgs=0 References: <201005201845.o4KIjFEq026248@sac.sfbay.sun.com> Status: RO Content-Length: 5849 +1 even though not needed. -- mark On May 20, 2010, at 12:45 PM, John Forte wrote: > I am sponsoring this closed approved automatic case for Janice Chang. It adds one SMF property to an already approved fasttrack (PSARC 2010/048). Binding is minor. PSARC 2010/048 was originally submitted closed but is now open and that change to open exposure is being recorded here. If anyone feels this doesn't qualify for self review, I'll convert it to a fasttrack. > > - John > > > Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI > This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. > 1. Introduction > 1.1. Project/Component Working Name: > SMF enhancements for zfs-based ndmp backup > 1.2. Name of Document Author/Supplier: > Author: Janice Chang > 1.3 Date of This Document: > 19 May 2010 > 4. Technical Description > > SMF enhancements for zfs-based ndmp backup > > 4.1. Description > > The PSARC case "zfs-based ndmpd backup" (2010/048) introduced a new backup type > for use with the Solaris NDMP service. Two new SMF variables were introduced > in conjunction with this new backup type (see Section 4.4. of the original > functional specification). Several new NDMP environment variables were also > introduced in this case, including ZFS_FORCE. The current case introduces a > third SMF variable, zfs-force-override. zfs-force-override is intended to > allow the specification of the value of ZFS_FORCE on the server running ndmpd, > thereby bypassing any value (or non-value) from the data management application > (DMA) for this environment variable. As noted in Section 5.1.4. of the > functional specification for PSARC 2010/048, ZFS_FORCE is "a new NDMP > environment variable which forces an incremental restore where such a restore > might normally fail. Its default value is 'n'." As with all other NDMP > environment variables, this variable is intended to be set on the DMA (if > needed); the DMA will then pass its value along to the NDMP server. ZFS_FORCE, > in particular, is meant to be set at restore time only if it is deemed > necessary, due to potential risks in setting the variable. (For more details, > please refer to Section 5.2. of the specification.) > However, certain data management applications (DMAs) do not allow NDMP > environment variables to be set only at restore time (e.g., they may instead > require such variables to be set at backup time. These values would later be > propagated to the restore at restore time.) This could be a problem if the > administrator realizes belatedly, at restore time, that the setting of > ZFS_FORCE was necessary. Though a manual procedure can sometimes be used in > lieu of setting ZFS_FORCE (as detailed in the original functional > specification), this procedure is not always effective and can be inconvenient > and unwieldy. > > To address the above deficiency, the current case introduces the new SMF > "zfs-force-override" option, which allows the administrator to essentially set > ZFS_FORCE at restore time regardless of DMA limitations. This is done by > setting zfs-force-override on the NDMP server via SMF. > > By default, zfs-force-override will have the value "off", which will > mean that it will have no effect. In this case, ndmpd will use the value of > ZFS_FORCE as set by the DMA (or its default value, which is 'n'). If the value > of zfs-force-override is "yes", then zfs-force-override will override ZFS_FORCE > with a value of 'y'. If the value of zfs-force-override is "no", then > zfs-force-override will override ZFS_FORCE with a value of 'n'. Any value > other than these will be treated as if zfs-force-override were set to "off". > > The classification of zfs-force-override will be the same as that of the > two SMF variables introduced in PSARC 2010/048. Since this classification was > left out of 2010/048 inadvertently, it is now specified (for all three SMF > variables) in Section 4.5. below. > > The current case also proposes a minor change to the previously introduced > SMF variables. Instead of "force_type" and "zfs_mode", these variables will > now be named "force-type" and "zfs-mode". > > > 4.2. Bug/RFE number(s): > > 6944258 - Investigate alternatives to ZFS_FORCE > > > 4.5. Interfaces > > Interfaces Exported > > Minor binding > > Interface Classification Comments > --------------------------------------------------------------------- > SMF variables Committed (This covers zfs-force-override, > introduced in the NDMP service for > this case, as well as force-type and > zfs-mode, originally introduced in > 2010/048) > > > 4.6. Doc Impact: Proposed ndmp man page change > > > version Set the maximum active NDMP protocol > version. Valid values are currently > 2, 3, and 4. The default is 4. > > + zfs-force-override Override the value of ZFS_FORCE. > + "yes" will force a value of 'y'. > + "no" will force a value of 'n'. > + By default, zfs-force-override has > + a value of "off" and will not override > + ZFS_FORCE. > + > The following property can only be set when using the > ndmpadm enable or ndmpadm disable command: > > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: Automatic > 6.6. ARC Exposure: open > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org