From sacadmin Tue Mar 21 02:42:02 2006 Received: from cathy.eng.sun.com (cathy.SFBay.Sun.COM [129.146.228.63]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LAg2IQ011243; Tue, 21 Mar 2006 02:42:02 -0800 (PST) Received: from cathy.eng.sun.com (localhost [127.0.0.1]) by cathy.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2LAg0Cn138218; Tue, 21 Mar 2006 02:42:00 -0800 (PST) Received: (from bonwick@localhost) by cathy.eng.sun.com (8.13.5+Sun/8.13.5/Submit) id k2LAg0xd138214; Tue, 21 Mar 2006 02:42:00 -0800 (PST) Date: Tue, 21 Mar 2006 02:42:00 -0800 (PST) From: Jeff Bonwick Message-Id: <200603211042.k2LAg0xd138214@cathy.eng.sun.com> To: PSARC@sac.sfbay.sun.com Cc: matthew.ahrens@sun.com Subject: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] Status: RO Content-Length: 1659 Subject: PSARC FastTrack [03/27/2006]: zfs send/receive Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI Copyright 2006 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: zfs send/receive 1.2. Name of Document Author/Supplier: Author: Matt Ahrens 1.3 Date of This Document: 21 March, 2006 4. Technical Description Summary: The zfs backup/restore subcommands should be renamed send/receive before ZFS goes into production in S10u2. Detail: 'zfs backup' and 'zfs restore' produce and consume byte streams which can be used to store a copy of a snapshot, or send data between machines. However, they do not provide a comprehensive backup solution. At a minimum, a real solution would provide the ability to backup a filesystem and all its descendent filesystems and snapshots, preserving any properties that have been set. A real solution would also probably be able to deal with tape drives and breaking the stream into segments to put onto multiple tapes / dvds / whatevers. Given that 'zfs backup' and 'zfs restore' do not actually provide full backup and restore capabilities, we should rename them so as to avoid confusion. The new names will be 'zfs send' and 'zfs receive' ('zfs recv' will be permitted as an alias for 'zfs receive'). These names imply the intended usage -- to transmit filesystems between machines, not only for backups but also for real-time remote replication (in the latter case, we send snapshot deltas). 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 Mar 21 02:48:09 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LAm8IQ011280 for ; Tue, 21 Mar 2006 02:48:09 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2LAm6oR000041; Tue, 21 Mar 2006 10:48:06 GMT Received: from [129.156.173.21] (enoexec [129.156.173.21]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k2LAm4L6025002; Tue, 21 Mar 2006 10:48:06 GMT Message-ID: <441FD9E4.6070809@Sun.COM> Date: Tue, 21 Mar 2006 10:48:04 +0000 From: Darren J Moffat User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Jeff Bonwick CC: PSARC@sac.sfbay.sun.com, matthew.ahrens@Sun.COM Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] References: <200603211042.k2LAg0xd138214@cathy.eng.sun.com> In-Reply-To: <200603211042.k2LAg0xd138214@cathy.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 366 I agree with not calling these backup/restore. However send/receive implied to me that this case wasn't just about the renaming but was adding network support and I got really interested in the case and was starting have all sorts of "how do you secure the link, how do you do key managment..." questions. What about "stream/unstream" or "pack/unpack". Darren From sacadmin Tue Mar 21 02:51:56 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LAptIQ011322 for ; Tue, 21 Mar 2006 02:51:55 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2LApqCM023276; Tue, 21 Mar 2006 11:51:52 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2LAppDk025004; Tue, 21 Mar 2006 11:51:52 +0100 (MET) Message-Id: <200603211051.k2LAppDk025004@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Darren J Moffat cc: Jeff Bonwick , PSARC@sac.sfbay.sun.com, Matthew.Ahrens@Sun.COM Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] In-Reply-To: <441FD9E4.6070809@Sun.COM> References: <200603211042.k2LAg0xd138214@cathy.eng.sun.com> <441FD9E4.6070809@Sun.COM> Date: Tue, 21 Mar 2006 11:51:51 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 391 >I agree with not calling these backup/restore. However send/receive >implied to me that this case wasn't just about the renaming but was >adding network support and I got really interested in the case and was >starting have all sorts of "how do you secure the link, how do you do >key managment..." questions. > >What about "stream/unstream" or "pack/unpack". copyout/copyin? Casper From sacadmin Tue Mar 21 03:13:29 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LBDTIQ011947 for ; Tue, 21 Mar 2006 03:13:29 -0800 (PST) Received: from unknown (vpn-129-150-16-38.SFBay.Sun.COM [129.150.16.38]) by zion.eng.sun.com (8.13.3+Sun/8.13.3) with SMTP id k2LBDRVT013066; Tue, 21 Mar 2006 03:13:28 -0800 (PST) Message-Id: <200603211113.k2LBDRVT013066@zion.eng.sun.com> Date: Tue, 21 Mar 2006 03:13:04 -0800 (PST) From: Jeff Bonwick Reply-To: Jeff Bonwick Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] To: bonwick@cathy.eng.sun.com, Darren.Moffat@Sun.COM Cc: PSARC@sac.sfbay.sun.com, matthew.ahrens@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 4aO0b8GoA5Zu69YVWwqD+Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_35 SunOS 5.9 sun4u sparc Status: RO Content-Length: 702 > What about "stream/unstream" or "pack/unpack". I think send/receive is more accurate. Sigh... I was tempted to file this case closed-approved-automatic just to avoid the endless debate that naming always generates. ;-) But as long as we're going to do the inevitable... (1) unstream isn't a word. (2) pack/unpack imply compression, which isn't what this is about. I should mention that in the interest of time, we've already got the doc folks working on this in parallel. I'd like to avoid changing it on them unless there's a truly compelling reason. Please, everyone... unless there's something genuinely wrong with the proposed names, let's not exchange 500 messages on this topic. Jeff From sacadmin Tue Mar 21 03:29:48 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LBTmIQ012175 for ; Tue, 21 Mar 2006 03:29:48 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2LBTjoR023076; Tue, 21 Mar 2006 11:29:46 GMT Received: from [129.156.173.21] (enoexec [129.156.173.21]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k2LBThbn005721; Tue, 21 Mar 2006 11:29:45 GMT Message-ID: <441FE3A7.40806@Sun.COM> Date: Tue, 21 Mar 2006 11:29:43 +0000 From: Darren J Moffat User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Jeff Bonwick CC: bonwick@cathy.eng.sun.com, PSARC@sac.sfbay.sun.com, matthew.ahrens@Sun.COM Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] References: <200603211113.k2LBDRVT013066@zion.eng.sun.com> In-Reply-To: <200603211113.k2LBDRVT013066@zion.eng.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1506 Jeff Bonwick wrote: >> What about "stream/unstream" or "pack/unpack". > > I think send/receive is more accurate. and I disagree. That doesn't make either of us correct. Maybe you could say why it is more accurate. > Sigh... I was tempted to file this case closed-approved-automatic > just to avoid the endless debate that naming always generates. ;-) > But as long as we're going to do the inevitable... > > (1) unstream isn't a word. fair enough. > (2) pack/unpack imply compression, which isn't what this is about. Really ? It doesn't to me. My clothes don't compress when I pack them in a suitcase. Sure if you mean as in pack(1) yes I guess that does mean compresison but the English word pack certainly doesn't imply compression. Not all uses of pack/unpack imply compression in commuting either. > I should mention that in the interest of time, we've already got > the doc folks working on this in parallel. I'd like to avoid > changing it on them unless there's a truly compelling reason. > > Please, everyone... unless there's something genuinely wrong with > the proposed names, let's not exchange 500 messages on this topic. Yes there as far as I'm concerned there is. As I said send/receive implies to me and others a network component. I've already had an ARC lurker here in the UK come to my desk and say the same thing and he hadn't read my email yet. However if no other ARC member agrees with me I'll shut-up and grumble in the corner to myself. -- Darren J Moffat From sacadmin Tue Mar 21 03:54:09 2006 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LBs9IQ012808 for ; Tue, 21 Mar 2006 03:54:09 -0800 (PST) Received: from unknown (vpn-129-150-16-38.SFBay.Sun.COM [129.150.16.38]) by zion.eng.sun.com (8.13.3+Sun/8.13.3) with SMTP id k2LBs7gT013505; Tue, 21 Mar 2006 03:54:08 -0800 (PST) Message-Id: <200603211154.k2LBs7gT013505@zion.eng.sun.com> Date: Tue, 21 Mar 2006 03:53:44 -0800 (PST) From: Jeff Bonwick Reply-To: Jeff Bonwick Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] To: bonwick@zion.eng.sun.com, Darren.Moffat@Sun.COM Cc: bonwick@cathy.eng.sun.com, PSARC@sac.sfbay.sun.com, matthew.ahrens@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LeR3N8MMLZKySabqoOSn6A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_35 SunOS 5.9 sun4u sparc Status: RO Content-Length: 471 > My clothes don't compress when I pack them in a suitcase. Then you're not doing it right. ;-) > As I said send/receive implies to me and others a network component. I hear you. No words are perfect. All common words are overloaded. Naming debates are like "please remove me from this alias" storms. Once one begins, there's just no way to stop it until it burns through the population. Sigh. OK, fine. Everybody weigh in. Fill my inbox. Bring it on. Jeff From sacadmin Tue Mar 21 06:17:07 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LEH6IQ015245 for ; Tue, 21 Mar 2006 06:17:06 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2LEH3oR026637; Tue, 21 Mar 2006 14:17:03 GMT Received: from [129.156.173.228] (coptic [129.156.173.228]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k2LEGwtL020348; Tue, 21 Mar 2006 14:16:58 GMT Message-ID: <44200AA2.607@sun.com> Date: Tue, 21 Mar 2006 14:16:02 +0000 From: Julian Pullen - Sun Microsystems User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051010 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeff Bonwick CC: Darren.Moffat@sun.com, bonwick@cathy.eng.sun.com, PSARC@sac.sfbay.sun.com, matthew.ahrens@sun.com Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] References: <200603211154.k2LBs7gT013505@zion.eng.sun.com> In-Reply-To: <200603211154.k2LBs7gT013505@zion.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 605 I would go with import/export, but I believe they are already used. Julian Jeff Bonwick wrote: >>My clothes don't compress when I pack them in a suitcase. > > > Then you're not doing it right. ;-) > > >>As I said send/receive implies to me and others a network component. > > > I hear you. No words are perfect. All common words are overloaded. > > Naming debates are like "please remove me from this alias" storms. > Once one begins, there's just no way to stop it until it burns > through the population. > > Sigh. OK, fine. Everybody weigh in. Fill my inbox. Bring it on. > > Jeff > From sacadmin Tue Mar 21 08:03:02 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LG31IQ018267 for ; Tue, 21 Mar 2006 08:03:02 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2LG2TJu011584; Tue, 21 Mar 2006 16:02:30 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.5+Sun/8.13.5/Submit) id k2LG2TwS011583; Tue, 21 Mar 2006 11:02:29 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] From: Bill Sommerfeld To: Jeff Bonwick Cc: Darren.Moffat@sun.com, bonwick@cathy.eng.sun.com, PSARC@sac.sfbay.sun.com, Matthew.Ahrens@sun.com In-Reply-To: <200603211154.k2LBs7gT013505@zion.eng.sun.com> References: <200603211154.k2LBs7gT013505@zion.eng.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1142956948.10497.816.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.334 Date: Tue, 21 Mar 2006 11:02:28 -0500 Status: RO Content-Length: 1535 We sometimes say "arc early, arc often", and I think the "arc early" part is especially true with cases like this. I understand and sympathize with wanting to avoid the bikeshed syndrome resulting from an unconstrained naming discussion. But we got here because what some people associate with "backup" and maybe also "restore" were a little off. I guess I see "send" and "receive" as roughly as far off in a different direction. (From my perspective as a networking/security guy, I was more OK with "backup"/"restore" than "send"/"receive"). My thoughts on pack/unpack: The perl builtin pack/unpack functions do not imply any compression. I suspect that these days more sysadmins are familiar with the perl functions than with pack(1) -- compression formats keep rolling onwards; my recollection is that pack/unpack were considered recently obsoleted by compress/uncompress at around the time I started seriously using BSD. For real-world objects "pack for shipment" often involves some expansion in volume (styrofoam, bubble wrap, packing peanuts, cardboard, etc.). An observation on import/export: import/export are subcommands of zpool(1m) while the current backup/restore are subcommands of zfs(1m) so there wouldn't be an actual conflict. But I've occasionally gotten twisted around and typed "zpool x" when I meant to type "zfs x" and vice-versa. Since zpool export is a disruptive command -- it unmounts filesystems and makes the pool unavailable -- I think it would be bad to have a "zfs export". - Bill From sacadmin Tue Mar 21 09:43:54 2006 Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LHhsIQ022463 for ; Tue, 21 Mar 2006 09:43:54 -0800 (PST) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.5+Sun/8.13.5) with SMTP id k2LHhrkK011043; Tue, 21 Mar 2006 09:43:53 -0800 (PST) Message-Id: <200603211743.k2LHhrkK011043@ivrel.sfbay.sun.com> Date: Tue, 21 Mar 2006 09:43:53 -0800 (PST) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: 2006/185 [zfs send/receive] To: PSARC@sac.sfbay.sun.com, bonwick@cathy.eng.sun.com Cc: matthew.ahrens@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0V4TtsyDxD9AsCaJg495/A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 287 Given that the naming storm has started, let me offer my suggestion: externalize internalize I think this pairing accurately describes what the subcommands do, without connoting anything else. In particular, it avoids the "does it compress?" question of "pack/unpack". -- Glenn From sacadmin Tue Mar 21 10:20:47 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LIKlIQ025527 for ; Tue, 21 Mar 2006 10:20:47 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2LIKZvG610437; Tue, 21 Mar 2006 10:20:39 -0800 (PST) Message-Id: <200603211820.k2LIKZvG610437@jurassic.eng.sun.com> Date: Tue, 21 Mar 2006 08:19:05 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] To: bonwick@zion.eng.sun.com, Darren.Moffat@sun.com Cc: bonwick@cathy.eng.sun.com, PSARC@sac.sfbay.sun.com, matthew.ahrens@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: HsGA853c6SGTXdew9qVOuA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 189 > From: Darren J Moffat ... > Really ? It doesn't to me. My clothes don't compress when > I pack them in a suitcase. Mine do, but I do tend to overpack! 8^) From sacadmin Tue Mar 21 10:24:12 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LIOCIQ025951 for ; Tue, 21 Mar 2006 10:24:12 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2LIO7ge612618; Tue, 21 Mar 2006 10:24:10 -0800 (PST) Message-Id: <200603211824.k2LIO7ge612618@jurassic.eng.sun.com> Date: Tue, 21 Mar 2006 08:22:37 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] To: bonwick@cathy.eng.sun.com, Darren.Moffat@Sun.COM, bonwick@zion.eng.sun.com Cc: PSARC@sac.sfbay.sun.com, matthew.ahrens@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: C9rJfjO7CcMJ2E6cKyRNEw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 679 > Sigh... I was tempted to file this case closed-approved-automatic > just to avoid the endless debate that naming always generates. ;-) > But as long as we're going to do the inevitable... Look at it this way: You avoided the discussion that this should be a fast-track... 8^) > Please, everyone... unless there's something genuinely wrong with > the proposed names, let's not exchange 500 messages on this topic. I almost agree. I've seen the suggestions and I have my personal favorite among them, but none seems "head and shoulders" above the others. Unless someone comes up with a trully sublime suggestion, let's just move on. Nothing to see here folks... - jek3 From sacadmin Tue Mar 21 10:32:23 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LIWNIQ029079 for ; Tue, 21 Mar 2006 10:32:23 -0800 (PST) Received: from nwkes-gis-mail-2.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2LIWMEZ008364 for ; Tue, 21 Mar 2006 10:32:22 -0800 (PST) Received: from d1-sfbay-06.sun.com ([192.18.39.116]) by nwkes-gis-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id k2LIWHVs009406 for ; Tue, 21 Mar 2006 10:32:17 -0800 (PST) Received: from conversion-daemon.d1-sfbay-06.sun.com by d1-sfbay-06.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWH00G01OOIYH00@d1-sfbay-06.sun.com> (original mail from Artem.Kachitchkin@Sun.COM) for PSARC@sac.sfbay.sun.com; Tue, 21 Mar 2006 10:32:17 -0800 (PST) Received: from [129.146.228.101] by d1-sfbay-06.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWH00EJ3Q5TXQ30@d1-sfbay-06.sun.com>; Tue, 21 Mar 2006 10:32:17 -0800 (PST) Date: Tue, 21 Mar 2006 10:32:26 -0800 From: Artem Kachitchkine Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] In-reply-to: <200603211042.k2LAg0xd138214@cathy.eng.sun.com> Sender: Artem.Kachitchkin@Sun.COM To: PSARC@sac.sfbay.sun.com Cc: matthew.ahrens@Sun.COM Message-id: <442046BA.7000106@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200603211042.k2LAg0xd138214@cathy.eng.sun.com> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 189 In OOP, to "serialize" is to turn an internal object representation into a byte-stream for the purpose of storing or sending over the network. The reverse is "deserialize". 2c, -Artem. From sacadmin Tue Mar 21 10:40:56 2006 Received: from ivrel.sfbay.sun.com (ivrel.SFBay.Sun.COM [129.146.74.76]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LIeuIQ004092 for ; Tue, 21 Mar 2006 10:40:56 -0800 (PST) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.5+Sun/8.13.5) with SMTP id k2LIeu0f011124; Tue, 21 Mar 2006 10:40:56 -0800 (PST) Message-Id: <200603211840.k2LIeu0f011124@ivrel.sfbay.sun.com> Date: Tue, 21 Mar 2006 10:40:56 -0800 (PST) From: Glenn Skinner Reply-To: Glenn Skinner Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] To: PSARC@sac.sfbay.sun.com, Artem.Kachitchkin@sun.com Cc: matthew.ahrens@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0Nk6NVKYEM6uavr2y8CMSQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Status: RO Content-Length: 637 Date: Tue, 21 Mar 2006 10:32:26 -0800 From: Artem Kachitchkine Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] In OOP, to "serialize" is to turn an internal object representation into a byte-stream for the purpose of storing or sending over the network. The reverse is "deserialize". Yes, that pairing is a reasonable alternative to the internalize/externalize I suggested. I suggested the pair I did in preference to serialize/deserialize because it's somewhat less suggestive of a specific technique and somewhat more suggestive of the results. -- Glenn From sacadmin Tue Mar 21 10:48:57 2006 Received: from phys-bur1-1 (phys-bur1-1.East.Sun.COM [129.148.13.15]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LImvIQ011867 for ; Tue, 21 Mar 2006 10:48:57 -0800 (PST) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IWH00L01QWXWD@bur-mail2.east.sun.com> (original mail from mark.johnson@sun.com) for PSARC@sac.sfbay.sun.com; Tue, 21 Mar 2006 13:48:56 -0500 (EST) Received: from [63.246.199.225] (vpn-129-150-65-45.East.Sun.COM [129.150.65.45]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IWH001T2QXKC9@bur-mail2.east.sun.com>; Tue, 21 Mar 2006 13:48:56 -0500 (EST) Date: Tue, 21 Mar 2006 13:48:53 -0500 From: Mark Johnson Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] In-reply-to: <200603211154.k2LBs7gT013505@zion.eng.sun.com> To: Jeff Bonwick Cc: PSARC@sac.sfbay.sun.com Message-id: <44204A95.3090204@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mail/News 1.5.0.2 (Macintosh/20060310) References: <200603211154.k2LBs7gT013505@zion.eng.sun.com> Status: RO Content-Length: 621 Jeff Bonwick wrote: >> My clothes don't compress when I pack them in a suitcase. > > Then you're not doing it right. ;-) > >> As I said send/receive implies to me and others a network component. > > I hear you. No words are perfect. All common words are overloaded. > > Naming debates are like "please remove me from this alias" storms. > Once one begins, there's just no way to stop it until it burns > through the population. > > Sigh. OK, fine. Everybody weigh in. Fill my inbox. Bring it on. send/receive seems fine to me, but since you prompted :-) zfs stdout/zfs stdin or zfs out/zfs in MRJ From sacadmin Tue Mar 21 14:01:24 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2LM1LIQ005874 for ; Tue, 21 Mar 2006 14:01:23 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k2LM1FRb006181 for ; Wed, 22 Mar 2006 06:01:16 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWH00D01ZPNAA00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC@sac.sfbay.sun.com; Wed, 22 Mar 2006 06:01:15 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWH00HL2ZU1RPP2@mail-apac.sun.com>; Wed, 22 Mar 2006 06:01:15 +0800 (SGT) Date: Tue, 21 Mar 2006 13:58:43 -0800 From: Darren Reed Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] In-reply-to: <44204A95.3090204@sun.com> Sender: Darren.Reed@Sun.COM To: Mark Johnson Cc: Jeff Bonwick , PSARC@sac.sfbay.sun.com Message-id: <44207713.80308@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200603211154.k2LBs7gT013505@zion.eng.sun.com> <44204A95.3090204@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20041221 Status: RO Content-Length: 813 Mark Johnson wrote: > > > Jeff Bonwick wrote: > >>> My clothes don't compress when I pack them in a suitcase. >> >> >> Then you're not doing it right. ;-) >> >>> As I said send/receive implies to me and others a network component. >> >> >> I hear you. No words are perfect. All common words are overloaded. >> >> Naming debates are like "please remove me from this alias" storms. >> Once one begins, there's just no way to stop it until it burns >> through the population. >> >> Sigh. OK, fine. Everybody weigh in. Fill my inbox. Bring it on. > > > send/receive seems fine to me, but since you prompted :-) > > > zfs stdout/zfs stdin > or > zfs out/zfs in How about: zfs [un]archive ? This is similar to 'backup' but doesn't necessarily have the same implications as using backup/restore. Darren From sacadmin Tue Mar 21 23:59:14 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2M7xDIQ028102 for ; Tue, 21 Mar 2006 23:59:13 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2M7xBoR010561; Wed, 22 Mar 2006 07:59:11 GMT Received: from [129.150.120.102] (vpn-129-150-120-102.UK.Sun.COM [129.150.120.102]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k2M7x94S010244; Wed, 22 Mar 2006 07:59:10 GMT Message-ID: <44210357.5010308@Sun.COM> Date: Wed, 22 Mar 2006 07:57:11 +0000 From: Darren J Moffat User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Darren Reed CC: Mark Johnson , Jeff Bonwick , PSARC@sac.sfbay.sun.com Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] References: <200603211154.k2LBs7gT013505@zion.eng.sun.com> <44204A95.3090204@sun.com> <44207713.80308@sun.com> In-Reply-To: <44207713.80308@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 528 Darren Reed wrote:> > How about: > > zfs [un]archive ? > > This is similar to 'backup' but doesn't necessarily have the same > implications as using backup/restore. Except that for some reason the dictionary.com definition of archive explicitly says that compression is used. Which is news to me since none of tar or cpio do native compression. The other definition of archive given has the explicit implication of offlining. Sorry I started this naming debate :-) the data, which is not true either -- Darren J Moffat From sacadmin Wed Mar 22 12:23:39 2006 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2MKNcIQ000368 for ; Wed, 22 Mar 2006 12:23:38 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.12.10+Sun/8.12.9) with ESMTP id k2MKNVRb017351 for ; Thu, 23 Mar 2006 04:23:32 +0800 (SGT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IWJ00001PNQUC00@mail-apac.sun.com> (original mail from James.McPherson@Sun.COM) for PSARC@sac.sfbay.sun.com; Thu, 23 Mar 2006 04:23:31 +0800 (SGT) Received: from [129.150.153.2] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IWJ00HO6PZ2RMWM@mail-apac.sun.com>; Thu, 23 Mar 2006 04:23:31 +0800 (SGT) Date: Thu, 23 Mar 2006 07:21:05 +1100 From: "James C. McPherson" Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] In-reply-to: <44204A95.3090204@sun.com> Sender: James.McPherson@Sun.COM To: Jeff Bonwick Cc: PSARC@sac.sfbay.sun.com Reply-to: James.McPherson@Sun.COM Message-id: <4421B1B1.4080109@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200603211154.k2LBs7gT013505@zion.eng.sun.com> <44204A95.3090204@sun.com> User-Agent: Mail/News 1.5 (X11/20060315) Status: RO Content-Length: 758 Mark Johnson wrote: > Jeff Bonwick wrote: >>> My clothes don't compress when I pack them in a suitcase. >> Then you're not doing it right. ;-) >>> As I said send/receive implies to me and others a network component. >> I hear you. No words are perfect. All common words are overloaded. >> Naming debates are like "please remove me from this alias" storms. >> Once one begins, there's just no way to stop it until it burns >> through the population. >> Sigh. OK, fine. Everybody weigh in. Fill my inbox. Bring it on. > send/receive seems fine to me, but since you prompted :-) > zfs stdout/zfs stdin > or > zfs out/zfs in Or how about zfs spit/zfs swallow James C. McPherson -- Solaris Datapath Engineering Data Management Group Sun Microsystems From sacadmin Wed Mar 29 10:56:55 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2TIusIQ012909 for ; Wed, 29 Mar 2006 10:56:54 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k2TIurbB021480; Wed, 29 Mar 2006 13:56:53 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2TIurLV026037; Wed, 29 Mar 2006 13:56:53 -0500 (EST) Subject: Re: zfs send/receive [PSARC/2006/185 Timeout: 03/27/2006] From: Bill Sommerfeld To: James.McPherson@sun.com Cc: Jeff Bonwick , PSARC@sac.sfbay.sun.com In-Reply-To: <4421B1B1.4080109@Sun.COM> References: <200603211154.k2LBs7gT013505@zion.eng.sun.com> <44204A95.3090204@sun.com> <4421B1B1.4080109@Sun.COM> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1143658610.24096.189.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Wed, 29 Mar 2006 13:56:53 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 370 On Wed, 2006-03-22 at 15:21, James C. McPherson wrote: > zfs spit/zfs swallow which seems to have brought the brainstorming to an abrupt halt... Well, it's Wednesday again. This case will be on the agenda today (but we're meeting at 4pm today). Of the names suggested so far I haven't seen anything dramatically better than the original proposal. - Bill