+1 even though not needed.

-- mark

On May 20, 2010, at 12:45 PM, John Forte <jfo...@sac.sfbay.sun.com> 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
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org

Reply via email to