From sacadmin Wed Sep 10 08:38:59 2008 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 m8AFcxWv023107; Wed, 10 Sep 2008 08:38:59 -0700 (PDT) Received: (from johnf@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m8AFcxP5023103; Wed, 10 Sep 2008 08:38:59 -0700 (PDT) Date: Wed, 10 Sep 2008 08:38:59 -0700 (PDT) From: John Fischer Message-Id: <200809101538.m8AFcxP5023103@sac.sfbay.sun.com> To: LSARC-record@sac.sfbay.sun.com Cc: erwann.chenede@sun.com, niall.power@sun.com, tim.foster@sun.com Subject: Snapshot manager [LSARC/2008/571 FastTrack timeout 09/17/2008] Status: RO Content-Length: 561 Template Version: @(#)sac_nextcase %I% %G% SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Snapshot manager 1.2. Name of Document Author/Supplier: Author: Erwann Chenede 1.3 Date of This Document: 10 September, 2008 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: Desktop - JDS 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From John.Fischer@Sun.COM Wed Sep 10 09:35:00 2008 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 m8AGZ08D025684 for ; Wed, 10 Sep 2008 09:35:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8AGYtXs017726 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Wed, 10 Sep 2008 09:34:59 -0700 (PDT) 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 <0K6Z0041LNEBRH00@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 10 Sep 2008 10:34:59 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K6Z00JY7NE7P890@brm-avmta-1.central.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 10 Sep 2008 10:34:55 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8AGYtl5023915 for ; Wed, 10 Sep 2008 09:34:55 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K6Z00801N48S100@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 10 Sep 2008 09:34:55 -0700 (PDT) Received: from [192.168.10.13] ([76.20.56.47]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K6Z00CTENDZI8E0@fe-sfbay-09.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Wed, 10 Sep 2008 09:34:47 -0700 (PDT) Date: Wed, 10 Sep 2008 09:34:30 -0700 From: John Fischer Subject: LSARC/2008/571 - Snapshot manager Sender: John.Fischer@Sun.COM To: lsarc-ext@Sun.COM Cc: Erwann.Chenede@Sun.COM, Tim.Foster@Sun.COM, Niall.Power@Sun.COM Reply-to: John.Fischer@Sun.COM Message-id: <48C7F716.8060502@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_pr9U5H7oH8/ehll4+on/dg)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.14 (X11/20080728) Status: RO Content-Length: 13802 This is a multi-part message in MIME format. --Boundary_(ID_pr9U5H7oH8/ehll4+on/dg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT All, I am sponsoring this fast track for Erwann Cheneda of the JDS team in Ireland. This project was developed in the Open Solaris community and is under CDDL. The case directory contains this proposal, package maps, a couple of twiki pages and the twiki attachments. I have set the timer for Wednesday, September 17th, 2008. This project introduces a snapshot manger to enable automatic ZFS snapshots to be taken for the user. The project is made of 3 separate parts--auto-snapshot, time-slider, time-slider-setup. The project also contains SMF service instances. These interfaces are being declared Uncommitted. The project is requesting a Minor release of Solaris. Thanks, John --Boundary_(ID_pr9U5H7oH8/ehll4+on/dg) Content-type: text/plain; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=proposal.txt 1. Introduction 1.1. Project/Component Working Name: Snapshot manager 1.2. Name of Document Author/Supplier: Author: Erwann Chenede, Tim Foster, Niall Power 1.3 Date of This Document: Sep 9 2008 4. Technical Description The snapshot manger's primary purpose is to enable automatic ZFS snapshots to be taken for the user. The goal is to have this "just work" and require minimal initial user configuration apart from deciding whether they want it on or off. The snapshot manager provides a sensible default configuration which the user is not required to configure in any way. This project is made of 3 separate parts : - auto-snapshot : an SMF service which allows the admin to performs regular, periodic snapshots of user/administrator-specified ZFS filesystems. It is loosely coupled with the ZFS codebase, using only the ZFS CLI, cron and SMF to perform it's functionality. - time-slider : an SMF service which aggregate auto-snapshot functionality to provide : - desktop user oriented default snapshot schedule. - an automatic cleanup functionality to avoid running out of disk space due to the periodic snapshot. - time-slider-setup : a python GNOME GUI application which let the user : - enable the snapshot scheduler service. - customize which zfs filesystems to automatically backup. - customize the automatic cleanup policy. This architecture was choosen to provide a sensible default configuration and yet let power users fine tune the scheduler as needed via the command line. 4.1 Details: 4.1.1 auto-snapshot The service works by having a separate service instance, each denoting a separate schedule of periodic snapshots, per group of fileystems. The SMF method script is responsible for adding/removing the snapshot cron job, which corresponds to enabling and disabling the service. The method script is also called directly from cron according to the crontab entries - in which case it is responsible for taking the snapshot. Filesystems are grouped together either by setting their names as a space separated list in an SMF instance property, or queried dynamically by the method script, by the service searching for an instance-specific ZFS user-property across all ZFS filesystems. With ZFS Delegated Administration (PSARC 2006/465), users can specify this property on their own filesystems, and need not reconfigure the SMF service. The service can also be responsible for destroying older snapshots taken by the service, allowing the administrator to keep a given number of snapshots into the past. The service can perform a backup command at each invocation of the cron job - the admin specifies what command to run at the end of a pipe that starts with "zfs send @", with the option of sending an incremental stream from the previous periodic snapshot. What does this offer that a simple "zfs snapshot @snap" entry in crontab doesn't? Using SMF allows the adminstrator to easily see when snapshots fail for some reason, allows them to easily enable/disable snapshots for groupings of filesystems and adds additional features, like performing backups of their filesystems. In the default configuration, we have daily, weekly, hourly, monthly and yearly snapshots - each managed under a different SMF instance. The administrator could add instances to take more frequent snapshots for some filesystems, less frequent snapshots for other filesystems - and have the service manage the complexity of dealing with cron for them. 4.1.2 time-slider : The default snapshot taking policy is : - Frequent snapshots, taken every 15 minutes, keeping the 4 most recent frequent snapshots. - Hourly snapshots taken once every hour, keeping the 24 most recent hourly snapshots. - Daily snapshots taken once every 24 hours, keeping the 7 most recent daily snapshots. - Weekly snapshots taken once every 7 days, keeping the 4 most recent weekly snapshots. - Monthly snapshots taken on the first day of every month, keeping the 12 most recent monthly snapshots. The above schedule aims to provide a balance between retaining a reasonable duration of available snapshots, but without having to keep an unreasonably large number of snapshots, with more granularity and frequency for recent snapshots. Apple's Time Machine adopts a similar backup scheduling policy. Power users who wish to customise the default policy may do so by modifying the SMF service properties for the hourly, daily, weekly or monthly schedules. 4.1.3 time-slider-setup : The time-slider-setup GUI displays the current configuration of the corresponding time-slider SMF service instance: svc:/application/time-slider:default and the filesystems the user has optionally selected to be automatically snapshotted. The status of the service and that of it's dependencies is queried using the svcs(1) command. The GUI enables and disables the service by invocation of the svcadm(1) command with the appropriate arguments. Configuration of the service is stored using SMF's native property group and property value configuration mechanisms which are queried and modified by the svcprop(1) and svccfg(1) commands respectively. Configuration options include: - Whether the default filesystem selection is chosen or if the user has opted for a customised selection. The SMF property for this is: "zfs/custom-selection" which is a boolean type witha default value of false, indicating that the default filesystem selection should be used. A true value indicates that the user has opted for customised file system selection. - The threshold level at which to reduce the number of snapshots kept on the system when a storage pool usage exceeds the specified percentage value. This is an initial warning level that the user is allowed to specify in the range between 70 and 90 percent. The default value is 80%. The SMF property value associated with this is "zpool/warning-level" Custom filesystem selection is based on zfs(1)'s user properties. The "com.sun:auto-snapshot" boolean property indicates whether or not the filesystem is selected for inclusion or exclusion from the automatic snapshotting by the svc:/system/filesystem.auto-snapshot SMF instances The user can select or deselect a filesystem from a list view in the time-slider-setup GUI. The selection status of a filesystem in the GUI gets applied as a true or false value to the "com.sun:auto-snapshot" property of the ZFS filesystem when the user clicks OK to complete the configuration of the time-slider service. 4.1.4 time-slider-cleanup : This is a helper program executed at regular intervals via crond. It is not intended for direct user invocation. User attempts to invoke the command directly will result in immediate exit of the program. The program gets added to root's crontab file whenever the time-slider service is enabled and get's removed if the service is disabled. The purpose of the program is to perform additional housekeeping by purging older snapshots before their natural expiry date as defined in section 4.1.2. In extreme situations, the user's zfs pool may become very low on available space due to the growth in size of a ZFS filesystem or the growth in size of one or more ZFS snapshots taken by the auto-snapshot service. In such cases, these snapshots need to be purged faster than normal in order to maintain a minimum level of space availability to the ZFS storage pool. The cleanup program takes a minimal approach to this task and is progressive in it's approach to deleting filesystem snapshots. It defines three levels of severity regarding space availability on a storage pool: warning, urgent, critical. These three levels are specified in the time-slider SMF instance's "zpool" property group. The three property values are: "warning-level", "critical-level" and "emergency-level" respectively. The default values of these properties are "80", "90" and "95" respectively, representing an integer value of the percentage of total disk capacity in use on a ZFS storage pool. The warning level has limited customisation ability by the user from the time-slider-seutp GUI. The lower limit of this value is 70 and the upper limit is 90, or the value of the critical-level if it has been customised. The GUI doe not offer the ability to customise the critical and emergency level values. When time-slider-cleanup gets invoked by crond, it checks the capacity level on each storage pool and compares this with the warning, critical and default levels. If the capacity exceeds one of these values it takes action appropriate to the severity of the problem: Warning level exceeded: Hourly, then daily snapshots will be delete, beginning with the oldest first until the storage pool capacity comes back down below the warning level value. Critical level exceeded: In addition to deletion of hourly and daily snapshots, weekly snapshots will also be deleted beginning with oldest first, until the storage pool capacity comes back down below the critical level. Emergency level exceeded: In addition to deletion of hourly, daily and weekly snapshots, monthly snapshots will also be deleted, starting with oldest first, until the storage pool capacity level comes back down below the emergency level value. If deletion of these snapshots fails to bring the pool's capacity back down below the emergency level then as a final measure, frequent (15-minute) snapshots are also deleted. This is a final measure that results in all automatically taken snapshots being deleted in order to try to keep the storage pool and the system usable. The frequent snapshots are deleted last as they are typically the smallest in size having the least devition from the main filesystem associated with them, and also because they will still provide the user with some level of protection from the most common human error such as accidental file deletion or corruption. time-slider-cleanup logs all remedial actions taken via syslog. Additionally it will send the desktop notification to any authorised users logged into the system and running a gnome desktop session. Authorised users are considered to be those posessing either the "Primary Administrator" or "ZFS Filesystem Management" profiles or the root user. 4.1.5 time-slider-notify : This is a helper program for time-slider-cleanup that displays warnings on the specified user's desktop's notification area. It is a wrapper for the /usr/bin/notify-send(1) command line utility. Please refer to : http://jdswiki.ireland.sun.com/twiki/bin/view/JDS/SnapshotManager 4.2 Bug/RFE Number(s): 6738645 4.4 Out of scope: A graphical means to explore zfs snapshots is provided via a new feature in the GNOME file manager (nautilus) see RFE 6738643 4.5 Interfaces: Imported Interfaces: -------------------- ZFS CLI (PSARC/2002/240) SMF (PSARC/2002/547) GNOME 2.24 (LSARC/2008/510) Exported Interfaces: -------------------- auto-snapshot : svc:/system/filesystem/zfs/auto-snapshot:daily Uncommitted svc:/system/filesystem/zfs/auto-snapshot:default Uncommitted svc:/system/filesystem/zfs/auto-snapshot:frequent Uncommitted svc:/system/filesystem/zfs/auto-snapshot:hourly Uncommitted svc:/system/filesystem/zfs/auto-snapshot:monthly Uncommitted svc:/system/filesystem/zfs/auto-snapshot:weekly Uncommitted time-slider : svc:/application/time-slider:default Uncommitted time-slider-setup : /usr/bin/time-slider-setup Uncommitted /usr/lib/time-slider-notify Uncommitted /usr/lib/time-slider-cleanup Uncommitted SUNWtime-slider-root Uncommitted SUNWtime-slider Uncommitted TIMFauto-snapshot Uncommitted 5. Documentation snapshot manager : http://jdswiki.ireland.sun.com/twiki/bin/view/JDS/SnapshotManager auto snapshot service : http://blogs.sun.com/timf/ 6. Resources and Schedule 6.1. Projected Availability OpenSolaris 2008.11 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: Desktop C-Team 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open --Boundary_(ID_pr9U5H7oH8/ehll4+on/dg)-- From Darren.Moffat@sun.com Thu Sep 18 05:36:49 2008 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 m8ICan1r009369 for ; Thu, 18 Sep 2008 05:36:49 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m8ICaljS007409 for <@sunmail2sca.sfbay.sun.com:LSARC-EXT@sun.com>; Thu, 18 Sep 2008 05:36:48 -0700 (PDT) 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 <0K7E00B035PCN300@brm-avmta-1.central.sun.com> for LSARC-EXT@sun.com (ORCPT LSARC-EXT@sun.com); Thu, 18 Sep 2008 06:36:48 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7E00AKM5PBLV00@brm-avmta-1.central.sun.com> for LSARC-EXT@sun.com (ORCPT LSARC-EXT@sun.com); Thu, 18 Sep 2008 06:36:47 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8ICakQj009627 for ; Thu, 18 Sep 2008 12:36:46 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7E00I014K53P00@fe-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for LSARC-EXT@sun.com (ORCPT LSARC-EXT@sun.com); Thu, 18 Sep 2008 13:36:46 +0100 (BST) Received: from [129.156.173.199] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7E006VI5P4M380@fe-emea-10.sun.com> for LSARC-EXT@sun.com (ORCPT LSARC-EXT@sun.com); Thu, 18 Sep 2008 13:36:40 +0100 (BST) Date: Thu, 18 Sep 2008 13:36:40 +0100 From: Darren J Moffat Subject: LSARC/2008/571 - Snapshot manager Sender: Darren.Moffat@sun.com To: LSARC-EXT@sun.com, Erwann.Chenede@sun.com, Tim.Foster@sun.com, Niall.Power@sun.com Message-id: <48D24B58.5030603@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.16 (X11/20080825) Status: RO Content-Length: 563 I believe from conversations with Tim part of the spec is missing. In particular the case doesn't mention that there is a new role created and what the reserved system uid for it is and what profiles the role has. The case also mentions TIMFauto-snapshot as an exported interface, I'm sure this is supposed to be SUNWauto-snapshot or something similar. Other than the issue with the missing details on the role, the case looks architecturally sound to me, but until I see the details on the role I reserve the right to change my mind. -- Darren J Moffat From Tim.Foster@sun.com Thu Sep 18 05:43:38 2008 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 m8IChbag009714 for ; Thu, 18 Sep 2008 05:43:37 -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 m8IChPcZ023777 for <@sunmail2sca.sfbay.sun.com:LSARC-EXT@sun.com>; Thu, 18 Sep 2008 13:43:36 +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 <0K7E00H0L60NKV00@nwk-avmta-2.sfbay.sun.com> for LSARC-EXT@sun.com (ORCPT LSARC-EXT@sun.com); Thu, 18 Sep 2008 05:43:35 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K7E006BX60L3LF0@nwk-avmta-2.sfbay.sun.com> for LSARC-EXT@sun.com (ORCPT LSARC-EXT@sun.com); Thu, 18 Sep 2008 05:43:34 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8IChWDo010579 for ; Thu, 18 Sep 2008 12:43:32 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0K7E00L015W6DP00@fe-emea-09.sun.com> (original mail from Tim.Foster@Sun.COM) for LSARC-EXT@sun.com (ORCPT LSARC-EXT@sun.com); Thu, 18 Sep 2008 13:43:32 +0100 (BST) Received: from [129.156.234.55] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0K7E001SS60974C0@fe-emea-09.sun.com> for LSARC-EXT@sun.com (ORCPT LSARC-EXT@sun.com); Thu, 18 Sep 2008 13:43:22 +0100 (BST) Date: Thu, 18 Sep 2008 13:40:31 +0100 From: Tim Foster Subject: Re: LSARC/2008/571 - Snapshot manager In-reply-to: <48D24B58.5030603@Sun.COM> Sender: Tim.Foster@sun.com To: Darren J Moffat Cc: LSARC-EXT@sun.com, Erwann.Chenede@sun.com, Niall.Power@sun.com Message-id: <1221741631.3268.16.camel@haiiro> Organization: Sun Microsystems, Inc. MIME-version: 1.0 X-Mailer: Evolution 2.22.2 Content-type: multipart/mixed; boundary="Boundary_(ID_zLlf1TMYJgdwo07njrzkHg)" X-PMX-Version: 5.4.1.325704 References: <48D24B58.5030603@Sun.COM> Status: RO Content-Length: 13043 --Boundary_(ID_zLlf1TMYJgdwo07njrzkHg) Content-type: text/plain Content-transfer-encoding: 7BIT Hey Darren, On Thu, 2008-09-18 at 13:36 +0100, Darren J Moffat wrote: > I believe from conversations with Tim part of the spec is missing. Yep - thanks. For the record, I'll attach the draft one pager I have here. I think it answers the questions about the zfssnap role. The package name will be SUNWzfs-auto-snapshot for the core SMF service component (which is a in separate package from the gui components) thanks! tim --Boundary_(ID_zLlf1TMYJgdwo07njrzkHg) Content-type: text/plain; charset=UTF-8; name=zfs-auto-snapshot-one-pager.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=zfs-auto-snapshot-one-pager.txt Template Version: @(#)onepager.txt 1.31 07/08/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: ZFS Automatic Snapshots 1.2. Name of Document Author/Supplier: Tim Foster 1.3. Date of This Document: 02/04/2008 (minor edits 09/09/2008) 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Community you expect to review your project: ZFS OpenSolaris Community [editor's note - I'm not sure what was expected for 1.4.1 above] 1.4.2. The ARC(s) you expect to review your project: PSARC 1.5. Email Aliases: 1.5.2. Responsible Engineer: tim.foster@sun.com 1.5.4. Interest List: zfs-discuss@opensolaris.org 2. Project Summary 2.1. Project Description: This project delivers an SMF service which allows the admin to performs regular, periodic snapshots of user/administrator-specified ZFS filesystems. It is loosely coupled with the ZFS codebase, using only the ZFS CLI, cron and SMF to perform it's functionality. 2.2. Risks and Assumptions: The current prototype has been implemented entirely in Korn shell - performance/scalability testing has not yet been carried out to determine whether this implementation is fast enough. If much tighter integration into the ZFS codebase is required, then this project will need additional resources. This project is not officially Sun funded - the engineer is doing this in his spare time. This could be mitigated by additional resources if a significant amount of additional engineering is recommended by the ARC and those resources become available. 3. Business Summary 3.1. Problem Area: This adds one more feature to the capabilities ZFS brings to Solaris, integrating ZFS more tightly with the operating system and providing a feature that some expect ZFS to have already. 3.2. Market/Requester: No specific person has asked for this feature, but it appears to be a general feature of many NAS boxes. The idea for such a system in ZFS came from a discussion on the zfs-discuss@opensolaris.org mailing list: http://www.opensolaris.org/jive/thread.jspa?messageID=37190 3.3. Business Justification: Not providing scheduled periodic ZFS snapshots on Solaris out of the box, means that there's one more thing that a system administrator needs to write and debug scripts for, before putting a Solaris system into production to best exercise the features ZFS can provide. Having a common facility in Solaris that does this would prevent duplication of effort at user sites, increase the speed-to deploy a Solaris system, and make life easier for support staff when users either request this feature, or try to troubleshoot a user's homemade solution. 3.4. Competitive Analysis: Many other NAS products and operating systems that support snapshots already do this. These include: http://www.emc.com/products/software/snapview2.jsp http://www.microsoft.com/windows/products/windowsvista/features/details/shadowcopy.mspx http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=relnotes&fname=/usr/relnotes/nasmgr http://www.netapp.com/ftp/snapshot-brochure.pdf http://www.real-storage.com/nas-snapshots.html http://people.freebsd.org/~rse/snapshot/ 3.5. Opportunity Window/Exposure: We're playing catchup. 3.6. How will you know when you are done?: The major features have already been implemented in Korn shell, but we could use some performance/stress testing on large systems. This code is primarily aimed at small systems. Community feedback can be used to determine if we've implemented enough of the functionality for this to be useful. [ editor's note: yes, that's pretty vague. I don't know what specific metrics I could use here - any suggestions ? ] 4. Technical Description: 4.1. Details: The service works by having a separate service instance, each denoting a separate schedule of periodic snapshots, per group of fileystems. The SMF method script is responsible for adding/removing the snapshot cron job, which corresponds to enabling and disabling the service. The method script is also called directly from cron according to the crontab entries - in which case it is responsible for taking the snapshot. Filesystems are grouped together either by setting their names as a space separated list in an SMF instance property, or queried dynamically by the method script, by the service searching for an instance-specific ZFS user-property across all ZFS filesystems. With ZFS Delegated Administration (PSARC 2006/465), users can specify this property on their own filesystems, and need not reconfigure the SMF service. The service can also be responsible for destroying older snapshots taken by the service, allowing the administrator to keep a given number of snapshots into the past. The service can perform a backup command at each invocation of the cron job - the admin specifies what command to run at the end of a pipe that starts with "zfs send @", with the option of sending an incremental stream from the previous periodic snapshot. What does this offer that a simple "zfs snapshot @snap" entry in crontab doesn't? Using SMF allows the adminstrator to easily see when snapshots fail for some reason, allows them to easily enable/disable snapshots for groupings of filesystems and adds additional features, like performing backups of their filesystems. In the default configuration, we have daily, weekly, hourly, monthly and yearly snapshots - each managed under a different SMF instance. The administrator could add instances to take more frequent snapshots for some filesystems, less frequent snapshots for other filesystems - and have the service manage the complexity of dealing with cron for them. This has been a personal project up till now, with code (licensed under CDDL) and implementation posted on the engineer's blog. The README documentation for the project is at: http://blogs.sun.com/timf/resource/README.zfs-auto-snapshot.txt The "SEE ALSO" section of the README has a list of links showing the various stages of the project to date. To summarize, the project has evolved over 10 versions since May 2006 to the present date. Users have been running the code, and providing feedback, which has been integrated into each subsequent version. Two known bugs are worth calling out here: One is to do with our reliance on cron. That is, to properly allow the administrator have snapshots taken every 3 days, we'd need to re-write the crontab entry when the days in the month aren't evenly divisible by 3 - at the moment, the following crontab day field would look like: 1,4,7,10,13,16,19,22,25,28,31 after taking the snapshot on the 31st our next snapshot should be taken on the 3rd of the following month - but as implemented, it'll get taken on the 1st instead. Other time periods are similarly affected. The other bug is 6474294 Need to be able to better control who can read files in a snapshot. This service doesn't change the implications of that bug, but having automatic snapshots could result in more people running into the situation. 4.2. Bug/RFE Number(s): TBD 4.3. In Scope: Everything discussed in this one-pager is in scope. 4.4. Out of Scope: While this service does provide a means for a snapshot stream to be stored remotely (the "backup" option allows for a ZFS send-stream to get piped to an administrator-specified command) it doesn't provide the eqivalent "restore" command. This is not a general purpose backup tool (ie. does not fix 5004379). This is also not a general purpose remote replication facility (5036182) although some users have already started using it as a "poor man's cluster". [ editor's note - with that in mind, could this service ultimately end up confusing people who are expecting the above? ] 4.5. Interfaces: The interface will be the SMF service, allowing users to create instances of the service to perform work. Setting/getting SMF properties and refreshing the instance works. For certain operations, we allow the user to set zfs filesystem properties (PSARC 2006/504) these are: zfs set com.sun:auto-snapshot=true|false zfs set com.sun:auto-snapshot: