From sacadmin Tue Aug 15 12:18:40 2006 Received: from pacifica.sfbay.sun.com (pacifica.SFBay.Sun.COM [129.146.228.204]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FJIeVg024715; Tue, 15 Aug 2006 12:18:40 -0700 (PDT) Received: from pacifica.sfbay.sun.com (localhost [127.0.0.1]) by pacifica.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7FJFSSj105657; Tue, 15 Aug 2006 12:15:28 -0700 (PDT) Received: (from ahrens@localhost) by pacifica.sfbay.sun.com (8.13.7+Sun/8.13.7/Submit) id k7FJFSM3105653; Tue, 15 Aug 2006 12:15:28 -0700 (PDT) Date: Tue, 15 Aug 2006 12:15:28 -0700 (PDT) From: Matthew Ahrens Message-Id: <200608151915.k7FJFSM3105653@pacifica.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Cc: noel.dellofano@sun.com Subject: zfs receive -F [PSARC/2006/479 Timeout: 08/23/2006] Status: RO Content-Length: 2636 Subject: PSARC FastTrack [08/23/2006]: zfs receive -F Template Version: @(#)sac_nextcase %I% %G% SMI This information Copyright 2006 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: zfs receive -F 1.2. Name of Document Author/Supplier: Author: Noel Dellofano 1.3 Date of This Document: 15 August, 2006 4. Technical Description 'zfs receive' of an incremental stream will fail if the filesystem has been modified since the most recent snapshot. You must do a 'zfs rollback' to remove the modifications before doing 'zfs receive'. However a problem arises in that spurious processes or users may touch the filesystem after the 'zfs rollback' is done, causing a subsequent attempt to do 'zfs receive' to also fail. Therefore, 'zfs receive' should have a -F "Force" flag which will do a 'zfs rollback' and then the 'zfs receive', without mounting the filesystem in between. This would eliminate the problem of the filesystem changing in between the 'zfs rollback' and the 'zfs receive' so the 'zfs receive' can return successfully. Here are man page changes: in the SYNOPSIS section: > zfs receive [-vnF] filesystem|volume|snapshot > zfs receive [-vnF] -d filesystem in the SUBCOMMANDS section (after 'zfs receive'): > zfs receive [-vnF] filesystem|volume|snapshot > zfs receive [-vnF] -d filesystem ... If a full stream is received, then a new file system is created as well. If an incremental stream is received, then the destination file system must already exist. In addition, the file system's most recent snapshot must > match the incremental stream's source. The destination > file system and all of its child filesystems are unmounted > and cannot be accessed during the receive operation. -d Use the name of the sent snapshot to determine the name of the new snapshot as described in the paragraph above. -v Print verbose information about the stream and the time required to perform the receive. -n Do not actually receive the stream. This can be useful in conjunction with the -v option to determine what name the receive operation would use. > -F Force a rollback of the filesystem to the most > recent snapshot before doing the receive. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From sacadmin Tue Aug 15 12:38:15 2006 Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FJcFbR024996 for ; Tue, 15 Aug 2006 12:38:15 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.5+Sun/8.13.5) with SMTP id k7FJcEuV014979; Tue, 15 Aug 2006 12:38:14 -0700 (PDT) Message-Id: <200608151938.k7FJcEuV014979@ivrel.sfbay.sun.com> Date: Tue, 15 Aug 2006 12:38:14 -0700 (PDT) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: 2006/479 [zfs receive -F] To: PSARC@sac.sfbay.sun.com, ahrens@pacifica.sfbay.sun.com Cc: noel.dellofano@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: fWK82X87hPbAbx5t8lMnow== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 1079 Date: Tue, 15 Aug 2006 12:15:28 -0700 (PDT) From: Matthew Ahrens Subject: zfs receive -F [PSARC/2006/479 Timeout: 08/23/2006] ... 4. Technical Description 'zfs receive' of an incremental stream will fail if the filesystem has been modified since the most recent snapshot. You must do a 'zfs rollback' to remove the modifications before doing 'zfs receive'. However a problem arises in that spurious processes or users may touch the filesystem after the 'zfs rollback' is done, causing a subsequent attempt to do 'zfs receive' to also fail. Therefore, 'zfs receive' should have a -F "Force" flag which will do a 'zfs rollback' and then the 'zfs receive', without mounting the filesystem in between. This would eliminate the problem of the filesystem changing in between the 'zfs rollback' and the 'zfs receive' so the 'zfs receive' can return successfully. Why "-F", as opposed to "-f", which is what other zfs subcommands use to request forced behavior? -- Glenn From sacadmin Tue Aug 15 12:50:49 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FJon3P025154 for ; Tue, 15 Aug 2006 12:50:49 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k7FJomGp018902 for ; Tue, 15 Aug 2006 12:50:48 -0700 (PDT) Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7FJommd004911 for ; Tue, 15 Aug 2006 13:50:48 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J420080119LSD00@mail-amer.sun.com> (original mail from Noel.Dellofano@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 15 Aug 2006 13:50:48 -0600 (MDT) Received: from [192.168.1.100] ([129.150.22.23]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J42008X91SNPYC6@mail-amer.sun.com>; Tue, 15 Aug 2006 13:50:48 -0600 (MDT) Date: Tue, 15 Aug 2006 12:51:18 -0700 From: Noel Dellofano Subject: Re: 2006/479 [zfs receive -F] In-reply-to: <200608151938.k7FJcEuV014979@ivrel.sfbay.sun.com> Sender: Noel.Dellofano@Sun.COM To: Glenn Skinner Cc: PSARC@sac.sfbay.sun.com, ahrens@pacifica.sfbay.sun.com, Noel.Dellofano@Sun.COM Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200608151938.k7FJcEuV014979@ivrel.sfbay.sun.com> Status: RO Content-Length: 1941 > Why "-F", as opposed to "-f", which is what other zfs subcommands use > to request forced behavior? Because we want to reserve the "-f" for use for this RFE: 6451693 want 'zfs receive -f' to force unmount this use of -f will be used to force unmount the filesystem you are trying to receive into as well as any of it's child filesystems (all filesystems must be unmounted to perform the receive). This is closer to what how our current subcommands behave, the -f forces a single operation to complete (an unmount, no in use checking, etc.) The "-F" is actually "forcing" two operations to happen, a rollback immediately followed by the receive. This ensures nothing can change on the filesystem underneath you before you do your receive. Noel On Aug 15, 2006, at 12:38 PM, Glenn Skinner wrote: > Date: Tue, 15 Aug 2006 12:15:28 -0700 (PDT) > From: Matthew Ahrens > Subject: zfs receive -F [PSARC/2006/479 Timeout: 08/23/2006] > > ... > 4. Technical Description > > 'zfs receive' of an incremental stream will fail if the filesystem > has been modified since the most recent snapshot. You must do a > 'zfs rollback' to remove the modifications before doing 'zfs > receive'. However a problem arises in that spurious processes or > users may touch the filesystem after the 'zfs rollback' is done, > causing a subsequent attempt to do 'zfs receive' to also fail. > > Therefore, 'zfs receive' should have a -F "Force" flag which will > do a 'zfs rollback' and then the 'zfs receive', without mounting > the filesystem in between. This would eliminate the problem of > the > filesystem changing in between the 'zfs rollback' and the 'zfs > receive' so the 'zfs receive' can return successfully. > > Why "-F", as opposed to "-f", which is what other zfs subcommands use > to request forced behavior? > > -- Glenn > From sacadmin Tue Aug 15 12:56:08 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FJu8rS025633 for ; Tue, 15 Aug 2006 12:56:08 -0700 (PDT) Received: from nwkea-pix-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7FJu8ld029208 for ; Tue, 15 Aug 2006 12:56:08 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwkea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7FJu3cu025663 for ; Tue, 15 Aug 2006 12:56:03 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4200I011WIQD00@d1-sfbay-09.sun.com> (original mail from Ed.Gould@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 15 Aug 2006 12:56:03 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4200FO521E0X89@d1-sfbay-09.sun.com>; Tue, 15 Aug 2006 12:56:02 -0700 (PDT) Date: Tue, 15 Aug 2006 12:56:14 -0700 From: Ed Gould Subject: Re: zfs receive -F [PSARC/2006/479 Timeout: 08/23/2006] In-reply-to: <200608151915.k7FJFSM3105653@pacifica.sfbay.sun.com> Sender: Ed.Gould@Sun.COM To: Matthew Ahrens Cc: PSARC@sac.sfbay.sun.com, Noel.Dellofano@Sun.COM Message-id: <44E226DE.8070405@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_St7C4ej/tVT0yRv6uZfALg)" References: <200608151915.k7FJFSM3105653@pacifica.sfbay.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1020 This is a multi-part message in MIME format. --Boundary_(ID_St7C4ej/tVT0yRv6uZfALg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Matthew Ahrens wrote: >> -F Force a rollback of the filesystem to the most >> recent snapshot before doing the receive. What happens if the most recent snapshot is newer than the base of the received stream? Should this (or a separate, perhaps -FF?) option force the rollback to the correct base snapshot? -- --Ed --Boundary_(ID_St7C4ej/tVT0yRv6uZfALg) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Sun Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect tel;work:650/786-4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_St7C4ej/tVT0yRv6uZfALg)-- From sacadmin Tue Aug 15 13:25:04 2006 Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FKP3eD026088 for ; Tue, 15 Aug 2006 13:25:03 -0700 (PDT) Received: from [129.146.108.62] (vinifera.SFBay.Sun.COM [129.146.108.62]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id k7FKP2P07869; Tue, 15 Aug 2006 13:25:02 -0700 (PDT) Message-ID: <44E22D9E.4030005@sun.com> Date: Tue, 15 Aug 2006 13:25:02 -0700 From: Scott Rotondo User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060718 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Noel Dellofano CC: Glenn Skinner , PSARC@sac.sfbay.sun.com, ahrens@pacifica.sfbay.sun.com Subject: Re: 2006/479 [zfs receive -F] References: <200608151938.k7FJcEuV014979@ivrel.sfbay.sun.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1228 Noel Dellofano wrote: >> Why "-F", as opposed to "-f", which is what other zfs subcommands use >> to request forced behavior? > > > Because we want to reserve the "-f" for use for this RFE: > 6451693 want 'zfs receive -f' to force unmount > > this use of -f will be used to force unmount the filesystem you are > trying to receive into as well as any of it's child filesystems (all > filesystems must be unmounted to perform the receive). This is closer > to what how our current subcommands behave, the -f forces a single > operation to complete (an unmount, no in use checking, etc.) The "-F" > is actually "forcing" two operations to happen, a rollback immediately > followed by the receive. This ensures nothing can change on the > filesystem underneath you before you do your receive. Is it really useful to distinguish between these two "force" options? It seems to me that administrators who use such an option to override safety checks typically want to override *all* such checks. I predict that common usage of either -f or -F will evolve to "zfs receive -fF". If that's true, it seems simpler to stick with a single -f option to do whatever is necessary to force the operation. Scott From sacadmin Tue Aug 15 13:42:20 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FKgJcR026185 for ; Tue, 15 Aug 2006 13:42:19 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7FKgHVL016027; Tue, 15 Aug 2006 16:42:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7FKgG7u025311; Tue, 15 Aug 2006 16:42:17 -0400 (EDT) Subject: Re: 2006/479 [zfs receive -F] From: Bill Sommerfeld To: Noel Dellofano Cc: Glenn Skinner , PSARC@sac.sfbay.sun.com, ahrens@pacifica.sfbay.sun.com In-Reply-To: References: <200608151938.k7FJcEuV014979@ivrel.sfbay.sun.com> Content-Type: text/plain Date: Tue, 15 Aug 2006 16:42:16 -0400 Message-Id: <1155674536.24747.38.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 769 On Tue, 2006-08-15 at 12:51 -0700, Noel Dellofano wrote: > The "-F" is actually "forcing" two operations to happen, a rollback > immediately followed by the receive. This ensures nothing can change > on the filesystem underneath you before you do your receive. What happens if the rollback would be to a snapshot which doesn't match the origin snapshot of the incremental dump? Does the rollback happen and the restore fail, or does the operation fail before the rollback happens? What happens if you mistype the name of the destination filesystem -- presumably the restore can't possibly run to completion because it's an incremental from the wrong filesystem.. is there any way to tell this before any data in the destination is destroyed? - Bill From sacadmin Tue Aug 15 13:47:38 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FKlcXU026204 for ; Tue, 15 Aug 2006 13:47:38 -0700 (PDT) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7FKlcHV029947; Tue, 15 Aug 2006 13:47:38 -0700 (PDT) Received: (from ahrens@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id k7FKlcfR029946; Tue, 15 Aug 2006 13:47:38 -0700 (PDT) Date: Tue, 15 Aug 2006 13:47:38 -0700 From: Matthew Ahrens To: Scott Rotondo Cc: Noel Dellofano , Glenn Skinner , PSARC@sac.sfbay.sun.com, ahrens@pacifica.sfbay.sun.com Subject: Re: 2006/479 [zfs receive -F] Message-ID: <20060815204738.GN24892@eng.sun.com> References: <200608151938.k7FJcEuV014979@ivrel.sfbay.sun.com> <44E22D9E.4030005@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44E22D9E.4030005@sun.com> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 1531 On Tue, Aug 15, 2006 at 01:25:02PM -0700, Scott Rotondo wrote: > Noel Dellofano wrote: > >>Why "-F", as opposed to "-f", which is what other zfs subcommands use > >>to request forced behavior? > > > > > >Because we want to reserve the "-f" for use for this RFE: > >6451693 want 'zfs receive -f' to force unmount > > > >this use of -f will be used to force unmount the filesystem you are > >trying to receive into as well as any of it's child filesystems (all > >filesystems must be unmounted to perform the receive). This is closer > >to what how our current subcommands behave, the -f forces a single > >operation to complete (an unmount, no in use checking, etc.) The "-F" > >is actually "forcing" two operations to happen, a rollback immediately > >followed by the receive. This ensures nothing can change on the > >filesystem underneath you before you do your receive. > > Is it really useful to distinguish between these two "force" options? > It seems to me that administrators who use such an option to override > safety checks typically want to override *all* such checks. I predict > that common usage of either -f or -F will evolve to "zfs receive -fF". Yes, it is useful to distinguish between these options because -F will remove data from the storage pool (by rolling back), and is therefore much more dangerous than simply forcing the filesystem to be unmounted. I imagine that at least some administrators would want to force the unmount but not the rollback (especially from scripts). --matt From sacadmin Tue Aug 15 15:19:55 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FMJtRB028570 for ; Tue, 15 Aug 2006 15:19:55 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7FMJs5I003775 for ; Tue, 15 Aug 2006 15:19:54 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7FMJssI006901 for ; Tue, 15 Aug 2006 16:19:54 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4200C01840HV00@mail-amer.sun.com> (original mail from Noel.Dellofano@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 15 Aug 2006 16:19:54 -0600 (MDT) Received: from [192.168.1.100] ([129.150.23.233]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4200LKZ8P4STS3@mail-amer.sun.com>; Tue, 15 Aug 2006 16:19:54 -0600 (MDT) Date: Tue, 15 Aug 2006 15:20:23 -0700 From: Noel Dellofano Subject: Re: zfs receive -F [PSARC/2006/479 Timeout: 08/23/2006] In-reply-to: <44E226DE.8070405@sun.com> Sender: Noel.Dellofano@Sun.COM To: Ed Gould Cc: Matthew Ahrens , PSARC@sac.sfbay.sun.com Message-id: <92F24FE2-3A03-4793-896A-954665591CBC@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200608151915.k7FJFSM3105653@pacifica.sfbay.sun.com> <44E226DE.8070405@sun.com> Status: RO Content-Length: 882 If the most recent snapshot is newer than the base stream the command will fail with: "cannot receive: most recent snapshot does not match incremental source" To rollback to anything other than the most recent snapshots requires the deletion of all snapshots taken after the one you want to rollback to. This should be done under close consideration of the sysadmin since they'll be deleting lots of data(i.e. multiple snapshots). Noel On Aug 15, 2006, at 12:56 PM, Ed Gould wrote: > Matthew Ahrens wrote: >>> -F Force a rollback of the filesystem to the most >>> recent snapshot before doing the receive. > > What happens if the most recent snapshot is newer than the base of > the received stream? Should this (or a separate, perhaps -FF?) > option force the rollback to the correct base snapshot? > -- > --Ed > From sacadmin Tue Aug 15 15:32:41 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FMWf6G028652 for ; Tue, 15 Aug 2006 15:32:41 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k7FMWeMb000908 for ; Tue, 15 Aug 2006 15:32:40 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7FMWeEx023816 for ; Tue, 15 Aug 2006 16:32:40 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4200E018WO5A00@mail-amer.sun.com> (original mail from Noel.Dellofano@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 15 Aug 2006 16:32:40 -0600 (MDT) Received: from [192.168.1.100] ([129.150.23.233]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4200LVZ9ACSTS3@mail-amer.sun.com>; Tue, 15 Aug 2006 16:32:40 -0600 (MDT) Date: Tue, 15 Aug 2006 15:33:07 -0700 From: Noel Dellofano Subject: Re: 2006/479 [zfs receive -F] In-reply-to: <1155674536.24747.38.camel@thunk> Sender: Noel.Dellofano@Sun.COM To: Bill Sommerfeld Cc: Glenn Skinner , PSARC@sac.sfbay.sun.com, Matthew Ahrens , Noel.Dellofano@Sun.COM Message-id: <9ACBF9D2-1E64-4926-941F-2149FF14E983@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200608151938.k7FJcEuV014979@ivrel.sfbay.sun.com> <1155674536.24747.38.camel@thunk> Status: RO Content-Length: 1963 > What happens if you mistype the name of the destination filesystem -- > presumably the restore can't possibly run to completion because > it's an > incremental from the wrong filesystem.. is there any way to tell this > before any data in the destination is destroyed? I'm a little unclear on what you're asking. You mean you typed the name of a valid filesystem to do the "receive" into however it wasn't the filesystem you actually wanted to do the "receive" into? Or did you mean you mistyped the name of a filesystem (i.e. an invalid name)? In the case of the latter, all syntax checking is done up front by the user-land code, hence if it's not a valid name of a dataset, you'll error out and print something to that effect. In the case of the former, if it's a valid filesystem and they force a rollback with the -F flag, then the rollback operation of that filesystem will complete(assuming there is also a valid snapshot in that filesystem to rollback to). However the subsequent "receive" operation will fail since the filesystem differs from incremental source. Noel On Aug 15, 2006, at 1:42 PM, Bill Sommerfeld wrote: > On Tue, 2006-08-15 at 12:51 -0700, Noel Dellofano wrote: >> The "-F" is actually "forcing" two operations to happen, a rollback >> immediately followed by the receive. This ensures nothing can change >> on the filesystem underneath you before you do your receive. > > What happens if the rollback would be to a snapshot which doesn't > match > the origin snapshot of the incremental dump? Does the rollback happen > and the restore fail, or does the operation fail before the rollback > happens? > > What happens if you mistype the name of the destination filesystem -- > presumably the restore can't possibly run to completion because > it's an > incremental from the wrong filesystem.. is there any way to tell this > before any data in the destination is destroyed? > > - Bill > > > From sacadmin Tue Aug 15 15:43:04 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FMh4E4028735 for ; Tue, 15 Aug 2006 15:43:04 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7FMh1hE009278; Tue, 15 Aug 2006 18:43:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7FMh1C1026063; Tue, 15 Aug 2006 18:43:01 -0400 (EDT) Subject: Re: 2006/479 [zfs receive -F] From: Bill Sommerfeld To: Noel Dellofano Cc: Glenn Skinner , PSARC@sac.sfbay.sun.com, Matthew Ahrens In-Reply-To: <9ACBF9D2-1E64-4926-941F-2149FF14E983@Sun.COM> References: <200608151938.k7FJcEuV014979@ivrel.sfbay.sun.com> <1155674536.24747.38.camel@thunk> <9ACBF9D2-1E64-4926-941F-2149FF14E983@Sun.COM> Content-Type: text/plain Date: Tue, 15 Aug 2006 18:43:01 -0400 Message-Id: <1155681781.24747.70.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1305 On Tue, 2006-08-15 at 15:33 -0700, Noel Dellofano wrote: > > What happens if you mistype the name of the destination filesystem -- > > presumably the restore can't possibly run to completion because > > it's an > > incremental from the wrong filesystem.. is there any way to tell this > > before any data in the destination is destroyed? > > I'm a little unclear on what you're asking. You mean you typed the > name of a valid filesystem to do the "receive" into however it wasn't > the filesystem you actually wanted to do the "receive" into? Or did > you mean you mistyped the name of a filesystem (i.e. an invalid name)? The former. > In the case of the former, if it's a valid filesystem and they force > a rollback with the -F flag, then the rollback operation of that > filesystem will complete(assuming there is also a valid snapshot in > that filesystem to rollback to). However the subsequent "receive" > operation will fail since the filesystem differs from incremental > source. That's unfortunate; what stands in the way of detecting this case? Is it something you can't validate until you're halfway through the restore? (Could you restore to a clone based off of the proper snapshot and then use a clone swap-like operation to snap it into place?) - Bill From sacadmin Tue Aug 15 16:24:02 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FNO2va001718 for ; Tue, 15 Aug 2006 16:24:02 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7FNO154000359 for ; Tue, 15 Aug 2006 16:24:01 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k7FNO1a3029644 for ; Tue, 15 Aug 2006 17:24:01 -0600 (MDT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J4200901BLAQ600@mail-amer.sun.com> (original mail from Noel.Dellofano@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 15 Aug 2006 17:24:01 -0600 (MDT) Received: from [192.168.1.100] ([129.150.23.233]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J4200EX7BO0SU3E@mail-amer.sun.com>; Tue, 15 Aug 2006 17:24:01 -0600 (MDT) Date: Tue, 15 Aug 2006 16:24:31 -0700 From: Noel Dellofano Subject: Re: 2006/479 [zfs receive -F] In-reply-to: <1155681781.24747.70.camel@thunk> Sender: Noel.Dellofano@Sun.COM To: Bill Sommerfeld Cc: Glenn Skinner , PSARC@sac.sfbay.sun.com, Matthew Ahrens , Ed Gould , Noel.Dellofano@Sun.COM Message-id: <426694FD-E591-4599-88E5-2DFFE79539A3@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <200608151938.k7FJcEuV014979@ivrel.sfbay.sun.com> <1155674536.24747.38.camel@thunk> <9ACBF9D2-1E64-4926-941F-2149FF14E983@Sun.COM> <1155681781.24747.70.camel@thunk> Status: RO Content-Length: 2343 My apologies, I answered too fast. I forgot that in a recent addition to the code, I actually put in an up front check for this case so we wouldn't run into precisely these problems. So the code checks that the most recent snapshot matches the incremental source *before* doing the rollback/receive. If the most recent snapshot doesn't match the incremental source then we return ENODEV and neither the rollback or receive is done. To recap the last two questions from Bill and Ed: 1) What happens if the most recent snapshot doesn't match the incremental source? - Neither the rollback or receive is done, we error out ENODEV 2) What happens if you type the name of another filesystem to do the receive into and you actually didn't want to receive into that filesystem? - Neither the rollback or receive is done, we error out with ENODEV Sorry about that, I made that change very recently and forgot about it, Noel On Aug 15, 2006, at 3:43 PM, Bill Sommerfeld wrote: > On Tue, 2006-08-15 at 15:33 -0700, Noel Dellofano wrote: >>> What happens if you mistype the name of the destination >>> filesystem -- >>> presumably the restore can't possibly run to completion because >>> it's an >>> incremental from the wrong filesystem.. is there any way to tell >>> this >>> before any data in the destination is destroyed? >> >> I'm a little unclear on what you're asking. You mean you typed the >> name of a valid filesystem to do the "receive" into however it wasn't >> the filesystem you actually wanted to do the "receive" into? Or did >> you mean you mistyped the name of a filesystem (i.e. an invalid >> name)? > > The former. > >> In the case of the former, if it's a valid filesystem and they force >> a rollback with the -F flag, then the rollback operation of that >> filesystem will complete(assuming there is also a valid snapshot in >> that filesystem to rollback to). However the subsequent "receive" >> operation will fail since the filesystem differs from incremental >> source. > > That's unfortunate; what stands in the way of detecting this case? Is > it something you can't validate until you're halfway through the > restore? > > (Could you restore to a clone based off of the proper snapshot and > then > use a clone swap-like operation to snap it into place?) > > - Bill > > From sacadmin Tue Aug 15 16:29:39 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7FNTcOC001759 for ; Tue, 15 Aug 2006 16:29:39 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k7FNTaUB016203; Tue, 15 Aug 2006 19:29:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7FNTZ0C026188; Tue, 15 Aug 2006 19:29:35 -0400 (EDT) Subject: Re: 2006/479 [zfs receive -F] From: Bill Sommerfeld To: Noel Dellofano Cc: Glenn Skinner , PSARC@sac.sfbay.sun.com, Matthew Ahrens , Ed Gould In-Reply-To: <426694FD-E591-4599-88E5-2DFFE79539A3@Sun.COM> References: <200608151938.k7FJcEuV014979@ivrel.sfbay.sun.com> <1155674536.24747.38.camel@thunk> <9ACBF9D2-1E64-4926-941F-2149FF14E983@Sun.COM> <1155681781.24747.70.camel@thunk> <426694FD-E591-4599-88E5-2DFFE79539A3@Sun.COM> Content-Type: text/plain Date: Tue, 15 Aug 2006 19:29:35 -0400 Message-Id: <1155684575.24747.75.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 557 On Tue, 2006-08-15 at 16:24 -0700, Noel Dellofano wrote: > My apologies, I answered too fast. I forgot that in a recent > addition to the code, I actually put in an up front check for this > case so we wouldn't run into precisely these problems. > So the code checks that the most recent snapshot matches the > incremental source *before* doing the rollback/receive. If the most > recent snapshot doesn't match the incremental source then we return > ENODEV and neither the rollback or receive is done. Excellent. Thank you. - Bill From sacadmin Fri Aug 18 15:47:23 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k7IMlN4p015703 for ; Fri, 18 Aug 2006 15:47:23 -0700 (PDT) Received: from zion.eng.sun.com (localhost [127.0.0.1]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k7IMlNIn011270; Fri, 18 Aug 2006 15:47:23 -0700 (PDT) Received: (from ahrens@localhost) by zion.eng.sun.com (8.13.7+Sun/8.13.7/Submit) id k7IMlMsP011268; Fri, 18 Aug 2006 15:47:22 -0700 (PDT) Date: Fri, 18 Aug 2006 15:47:22 -0700 From: Matthew Ahrens To: PSARC@sac.sfbay.sun.com, noel.dellofano@sun.com Subject: Re: 2006/479 [zfs receive -F] Message-ID: <20060818224722.GW24892@eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 134 Forgot to mention, this change is interface stability: evolving (like the rest of zfs(1m)), and release binding: patch/micro. --matt