From sacadmin Wed Feb 17 07:52:04 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1HFq4xN005119 for ; Wed, 17 Feb 2010 07:52:04 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1HFq3ta016265 for <@sunmail2sca.sfbay.sun.com:PSARC@sun.com>; Wed, 17 Feb 2010 09:52:03 -0600 (CST) 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 <0KXZ00N19TER0700@brm-avmta-1.central.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 17 Feb 2010 08:52:03 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KXZ00EXETEQP1C0@brm-avmta-1.central.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 17 Feb 2010 08:52:02 -0700 (MST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1HFq2g7028212 for ; Wed, 17 Feb 2010 15:52:02 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KXZ00M00RXQPX00@mail-amer.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 17 Feb 2010 08:52:02 -0700 (MST) Received: from vpn-129-150-65-52.east.sun.com ([unknown] [129.150.65.52]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KXZ00IJPTEAIO90@mail-amer.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 17 Feb 2010 08:51:48 -0700 (MST) Date: Wed, 17 Feb 2010 08:51:46 -0700 From: "Mark A. Carlson" Subject: zfs-based ndmpd backup PSARC 2010/048 - New materials uploaded Sender: Mark.Carlson@sun.com To: PSARC@sun.com Cc: Janice Chang , Dan Maslowski Message-id: <4B7C1092.1050505@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HZn/9pyCugloqk2AgpTrAQ)" X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 1501 This is a multi-part message in MIME format. --Boundary_(ID_HZn/9pyCugloqk2AgpTrAQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT New materials have been uploaded to the case directory for today's inception review: 61 -rw-r--r-- 1 markcarl staff 30658 Feb 17 07:40 zfs-ndmpd-4.2.odt 17 -rw-r--r-- 1 markcarl staff 8145 Feb 17 07:39 1pagerupdate.txt 49 -rw-r--r-- 1 markcarl staff 24433 Feb 17 07:39 ndmpd-20update.txt Change bars from the previous version are shown. -- mark --Boundary_(ID_HZn/9pyCugloqk2AgpTrAQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT New materials have been uploaded to the case directory
for today's inception review:

61 -rw-r--r--   1 markcarl staff      30658 Feb 17 07:40 zfs-ndmpd-4.2.odt
17 -rw-r--r--   1 markcarl staff       8145 Feb 17 07:39 1pagerupdate.txt
49 -rw-r--r--   1 markcarl staff      24433 Feb 17 07:39 ndmpd-20update.txt

Change bars from the previous version are shown.

-- mark

--Boundary_(ID_HZn/9pyCugloqk2AgpTrAQ)-- From sacadmin Wed Feb 17 11:07:00 2010 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 o1HJ6xlt013099 for ; Wed, 17 Feb 2010 11:06:59 -0800 (PST) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1HJ6xoY021261 for <@sunmail2sca.sfbay.sun.com:PSARC@sun.com>; Wed, 17 Feb 2010 11:06:59 -0800 (PST) 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 <0KY000I052FNXP00@brm-avmta-1.central.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 17 Feb 2010 12:06:59 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KY000DSJ2FM3O80@brm-avmta-1.central.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 17 Feb 2010 12:06:58 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1HJ6wM8011186 for ; Wed, 17 Feb 2010 19:06:58 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KY000H0028ONB00@mail-amer.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 17 Feb 2010 12:06:58 -0700 (MST) Received: from [129.152.9.14] ([unknown] [129.152.9.14]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KY0006Q62FF6HC0@mail-amer.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 17 Feb 2010 12:06:57 -0700 (MST) Date: Wed, 17 Feb 2010 13:06:51 -0600 From: Rick Matthews Subject: PSARC 2010/048 - zfs-based ndmpd backup Sender: Richard.Matthews@sun.com To: Janice.Chang@sun.com, PSARC@sun.com Cc: Dan Maslowski Reply-to: Richard.Matthews@sun.com Message-id: <4B7C3E4B.9060500@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.23 (X11/20090910) Status: RO Content-Length: 1912 Janice, I checked the spec and do see where you have a header definition and data definition. While the zfs send stream is listed as a committed format in the zfs(1) man page, that may be a result of a comment made to PSARC 2007/574. I didn't see any definition of the stream that would allow me to determine that the format was anything other than an unbounded byte stream. My concern the size of one tape. If the data is an unbounded byte stream, the indicator for end of data would normally be a tape mark (EOF essentially). There is always a tape mark at the end of tape. Since the data produced by zfs send can represent all active blocks in a volume, for example, the data stream produced may be larger than a single tape. This presents some problems, as I see it. 1) How do we know when the send stream is complete, and 2) if the stream is larger than a single tape, how do we know where the data stream is continued, and 3) how do we know we have all the data in the stream? Some of these issues are pointed out by PSARC 2006/185 zfs send/receive. A size of the data stream is one (but only one...there can be others) approach to knowing when the data is complete. tar (ustar) formats include sizes, which is why they may not have the same issue. I understand it may not be possible to have the "size" of a zfs send stream to be placed in a header of some sort. Please explain how the data can span multiple tapes, and can be considered complete. Thanks -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Oracle Corporation 1270 Eagan Industrial Road phone(Sun internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- From sacadmin Wed Feb 17 16:37:56 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1I0btwU022895 for ; Wed, 17 Feb 2010 16:37:55 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1I0brvO015714; Wed, 17 Feb 2010 18:37:54 -0600 (CST) 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 <0KY00070JHR50700@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Feb 2010 16:37:53 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KY0001KGHR4KW90@nwk-avmta-2.sfbay.sun.com>; Wed, 17 Feb 2010 16:37:52 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1I0bqfv016240; Thu, 18 Feb 2010 00:37:52 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KY000100HCH7500@mail-amer.sun.com>; Wed, 17 Feb 2010 17:37:52 -0700 (MST) Received: from [129.150.212.14] ([unknown] [129.150.212.14]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KY0007FVHQYBA00@mail-amer.sun.com>; Wed, 17 Feb 2010 17:37:52 -0700 (MST) Date: Wed, 17 Feb 2010 19:37:45 -0500 From: Janice Chang Subject: Re: PSARC 2010/048 - zfs-based ndmpd backup In-reply-to: <4B7C3E4B.9060500@Sun.COM> Sender: Janice.Chang@sun.com To: Richard.Matthews@sun.com Cc: PSARC@sun.com, Dan Maslowski , David Pacheco , Reza Sabdar , Matthew Ahrens Message-id: <4B7C8BD9.6030801@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B7C3E4B.9060500@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 1982 Rick Matthews wrote: > Janice, > I checked the spec and do see where you have a header definition and > data definition. > While the zfs send stream is listed as a committed format in the zfs(1) > man page, that may be a result of a comment made to PSARC 2007/574. I > didn't > see any definition of the stream that would allow me to determine that > the > format was anything other than an unbounded byte stream. > My concern the size of one tape. If the data is an unbounded byte > stream, > the indicator for end of data would normally be a tape mark (EOF > essentially). > There is always a tape mark at the end of tape. > Since the data produced by zfs send can represent all active blocks > in a volume, > for example, the data stream produced may be larger than a single > tape. This presents > some problems, as I see it. 1) How do we know when the send stream is > complete, and > 2) if the stream is larger than a single tape, how do we know where > the data stream > is continued, and 3) how do we know we have all the data in the stream? > Some of these issues are pointed out by PSARC 2006/185 zfs send/receive. > A size of the data stream is one (but only one...there can be others) > approach to knowing when the data is complete. tar (ustar) formats > include > sizes, which is why they may not have the same issue. I understand it > may not > be possible to have the "size" of a zfs send stream to be placed in a > header > of some sort. > Please explain how the data can span multiple tapes, and can be > considered > complete. > > Thanks > Hi Rick.... The zfs send/recv stream knows how to determine the end of the stream. Tape spanning is handled automatically by the data management application (DMA) (e.g. Netbackup). In this case, Netbackup is keeping track of which streams are on each of the tapes and reconstituting a single stream on recovery. I believe this should address the three concerns you raised...... Thanks, Janice From sacadmin Thu Feb 18 09:14:28 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1IHEREC023197 for ; Thu, 18 Feb 2010 09:14:27 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o1IHEQfL006253; Thu, 18 Feb 2010 10:14:26 -0700 (MST) 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 <0KY10010PRW2DI00@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Feb 2010 09:14:26 -0800 (PST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KY100M8ORW12I40@nwk-avmta-2.sfbay.sun.com>; Thu, 18 Feb 2010 09:14:25 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1IHEOtQ019399; Thu, 18 Feb 2010 17:14:24 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KY100200O19V100@mail-amer.sun.com>; Thu, 18 Feb 2010 10:14:24 -0700 (MST) Received: from [129.152.9.14] ([unknown] [129.152.9.14]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KY10063HRVNBH10@mail-amer.sun.com>; Thu, 18 Feb 2010 10:14:18 -0700 (MST) Date: Thu, 18 Feb 2010 11:14:11 -0600 From: Rick Matthews Subject: Re: PSARC 2010/048 - zfs-based ndmpd backup In-reply-to: <4B7C8BD9.6030801@sun.com> Sender: Richard.Matthews@sun.com To: Janice Chang Cc: PSARC@sun.com, Dan Maslowski , David Pacheco , Reza Sabdar , Matthew Ahrens Reply-to: Richard.Matthews@sun.com Message-id: <4B7D7563.6050704@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B7C3E4B.9060500@Sun.COM> <4B7C8BD9.6030801@sun.com> User-Agent: Thunderbird 2.0.0.23 (X11/20090910) Status: RO Content-Length: 3265 OK...some documentation on either mechanism wold be nice. It could be stated that the format of the send stream is out of scope for your project. It also seems to violate the spirit of a committed interface (See Interface Taxonomy: http://sac.eng/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp) not to have a documented interface. That said, you are not proposing the interface, just consuming it. Did the previous NDMP case define how tape spanning occurs, or does it just leave it to the DMA provider (like NetBackup)? I looked, but didn't see anything. From an ARC member prospective, the project is asking us to accept the interface as adequate because the project has indicated that it is. I guess I've done stranger things. -- Rick On 02/17/10 06:37 PM, Janice Chang wrote: > > > Rick Matthews wrote: >> Janice, >> I checked the spec and do see where you have a header definition and >> data definition. >> While the zfs send stream is listed as a committed format in the zfs(1) >> man page, that may be a result of a comment made to PSARC 2007/574. I >> didn't >> see any definition of the stream that would allow me to determine >> that the >> format was anything other than an unbounded byte stream. >> My concern the size of one tape. If the data is an unbounded byte >> stream, >> the indicator for end of data would normally be a tape mark (EOF >> essentially). >> There is always a tape mark at the end of tape. >> Since the data produced by zfs send can represent all active blocks >> in a volume, >> for example, the data stream produced may be larger than a single >> tape. This presents >> some problems, as I see it. 1) How do we know when the send stream is >> complete, and >> 2) if the stream is larger than a single tape, how do we know where >> the data stream >> is continued, and 3) how do we know we have all the data in the stream? >> Some of these issues are pointed out by PSARC 2006/185 zfs >> send/receive. >> A size of the data stream is one (but only one...there can be others) >> approach to knowing when the data is complete. tar (ustar) formats >> include >> sizes, which is why they may not have the same issue. I understand it >> may not >> be possible to have the "size" of a zfs send stream to be placed in a >> header >> of some sort. >> Please explain how the data can span multiple tapes, and can be >> considered >> complete. >> >> Thanks >> > Hi Rick.... > > The zfs send/recv stream knows how to determine the end of the > stream. Tape spanning is handled automatically by the data management > application (DMA) (e.g. Netbackup). In this case, Netbackup is > keeping track of which streams are on each of the tapes and > reconstituting a single stream on recovery. > > I believe this should address the three concerns you raised...... > > Thanks, > Janice -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Oracle Corporation 1270 Eagan Industrial Road phone(Sun internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- From sacadmin Thu Feb 18 12:16:47 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o1IKGlG3027418 for ; Thu, 18 Feb 2010 12:16:47 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1IKGkRU007760; Thu, 18 Feb 2010 12:16:47 -0800 (PST) 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 <0KY200D0N0BYMU00@brm-avmta-1.central.sun.com>; Thu, 18 Feb 2010 13:16:46 -0700 (MST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KY20004C0BXPW70@brm-avmta-1.central.sun.com>; Thu, 18 Feb 2010 13:16:45 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1IKGjpk027187; Thu, 18 Feb 2010 20:16:45 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KY200300019UL00@mail-amer.sun.com>; Thu, 18 Feb 2010 13:16:45 -0700 (MST) Received: from [129.150.212.10] ([unknown] [129.150.212.10]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KY200K510BRTD40@mail-amer.sun.com>; Thu, 18 Feb 2010 13:16:45 -0700 (MST) Date: Thu, 18 Feb 2010 15:16:38 -0500 From: Janice Chang Subject: Re: PSARC 2010/048 - zfs-based ndmpd backup In-reply-to: <4B7D7563.6050704@Sun.COM> Sender: Janice.Chang@sun.com To: Richard.Matthews@sun.com Cc: PSARC@sun.com, Dan Maslowski , David Pacheco , Reza Sabdar , Matthew Ahrens , "Mark A. Carlson" Message-id: <4B7DA026.9050603@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B7C3E4B.9060500@Sun.COM> <4B7C8BD9.6030801@sun.com> <4B7D7563.6050704@Sun.COM> User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) Status: RO Content-Length: 3587 Hi Rick. The NDMP protocol (referenced in the 2010/048 PSARC case) describes what happens when data cannot fit on a single tape (e.g. see NDMP V4 spec: section D.2.1., Recovery exceptions; section D.8., NDMP exceptions). The link to the NDMP V4 spec is provided in the case materials, but here it is for your reference: http://www.ndmp.org/download/sdk_v4/draft-skardal-ndmp4-04.txt We agree that the format of the zfs send stream is out of scope for this project. Per Mark, documentation for the stream can be handled on the next iteration of a ZFS case where this interface is mentioned. Thanks, Janice Rick Matthews wrote: > OK...some documentation on either mechanism wold be nice. > > It could be stated that the format of the send stream is out of scope > for your > project. It also seems to violate the spirit of a committed interface > (See Interface > Taxonomy: http://sac.eng/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp) not > to have a documented interface. That said, you are not proposing the > interface, > just consuming it. > > Did the previous NDMP case define how tape spanning occurs, or does it > just > leave it to the DMA provider (like NetBackup)? I looked, but didn't > see anything. > > From an ARC member prospective, the project is asking us to accept the > interface > as adequate because the project has indicated that it is. I guess I've > done stranger things. > -- > Rick > > On 02/17/10 06:37 PM, Janice Chang wrote: >> >> >> Rick Matthews wrote: >>> Janice, >>> I checked the spec and do see where you have a header definition and >>> data definition. >>> While the zfs send stream is listed as a committed format in the >>> zfs(1) >>> man page, that may be a result of a comment made to PSARC 2007/574. >>> I didn't >>> see any definition of the stream that would allow me to determine >>> that the >>> format was anything other than an unbounded byte stream. >>> My concern the size of one tape. If the data is an unbounded byte >>> stream, >>> the indicator for end of data would normally be a tape mark (EOF >>> essentially). >>> There is always a tape mark at the end of tape. >>> Since the data produced by zfs send can represent all active blocks >>> in a volume, >>> for example, the data stream produced may be larger than a single >>> tape. This presents >>> some problems, as I see it. 1) How do we know when the send stream >>> is complete, and >>> 2) if the stream is larger than a single tape, how do we know where >>> the data stream >>> is continued, and 3) how do we know we have all the data in the stream? >>> Some of these issues are pointed out by PSARC 2006/185 zfs >>> send/receive. >>> A size of the data stream is one (but only one...there can be others) >>> approach to knowing when the data is complete. tar (ustar) formats >>> include >>> sizes, which is why they may not have the same issue. I understand >>> it may not >>> be possible to have the "size" of a zfs send stream to be placed in >>> a header >>> of some sort. >>> Please explain how the data can span multiple tapes, and can be >>> considered >>> complete. >>> >>> Thanks >>> >> Hi Rick.... >> >> The zfs send/recv stream knows how to determine the end of the >> stream. Tape spanning is handled automatically by the data >> management application (DMA) (e.g. Netbackup). In this case, >> Netbackup is keeping track of which streams are on each of the tapes >> and reconstituting a single stream on recovery. >> >> I believe this should address the three concerns you raised...... >> >> Thanks, >> Janice > > From sacadmin Fri Feb 19 05:42:13 2010 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 o1JDgDHs026715 for ; Fri, 19 Feb 2010 05:42:13 -0800 (PST) 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.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o1JDgBDE007516; Fri, 19 Feb 2010 05:42:13 -0800 (PST) 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 <0KY300B0FCQDP400@brm-avmta-1.central.sun.com>; Fri, 19 Feb 2010 06:42:13 -0700 (MST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KY300MF5CQCD970@brm-avmta-1.central.sun.com>; Fri, 19 Feb 2010 06:42:12 -0700 (MST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o1JDgC2x027053; Fri, 19 Feb 2010 13:42:12 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KY300700CI40N00@mail-amer.sun.com>; Fri, 19 Feb 2010 06:42:12 -0700 (MST) Received: from rick-matthews-powerbook-g4-15.local ([unknown] [98.240.226.104]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KY300I99CPYEBC0@mail-amer.sun.com>; Fri, 19 Feb 2010 06:42:11 -0700 (MST) Date: Fri, 19 Feb 2010 07:42:27 -0600 From: Rick Matthews Subject: Re: PSARC 2010/048 - zfs-based ndmpd backup In-reply-to: <4B7DA026.9050603@sun.com> Sender: Richard.Matthews@sun.com To: Janice Chang Cc: PSARC@sun.com, Dan Maslowski , David Pacheco , Reza Sabdar , Matthew Ahrens , "Mark A. Carlson" Message-id: <4B7E9543.4010001@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B7C3E4B.9060500@Sun.COM> <4B7C8BD9.6030801@sun.com> <4B7D7563.6050704@Sun.COM> <4B7DA026.9050603@sun.com> User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) Status: RO Content-Length: 4440 Janice, I looked at the protocol doc. It does nicely describe tape spanning, although the section you referenced was the read side, not write. Write (to EOT and beyond) was described later in detail. I'm satisfied with that. Thanks. -- Rick Janice Chang wrote: > Hi Rick. > > The NDMP protocol (referenced in the 2010/048 PSARC case) describes > what happens when data cannot fit on a single tape (e.g. see NDMP V4 > spec: section D.2.1., Recovery exceptions; section D.8., NDMP > exceptions). The link to the NDMP V4 spec is provided in the case > materials, but here it is for your reference: > http://www.ndmp.org/download/sdk_v4/draft-skardal-ndmp4-04.txt > > We agree that the format of the zfs send stream is out of scope for > this project. Per Mark, documentation for the stream can be handled > on the next iteration of a ZFS case where this interface is mentioned. > > Thanks, > Janice > > Rick Matthews wrote: >> OK...some documentation on either mechanism wold be nice. >> >> It could be stated that the format of the send stream is out of scope >> for your >> project. It also seems to violate the spirit of a committed interface >> (See Interface >> Taxonomy: http://sac.eng/cgi-bin/bp.cgi?NAME=interface_taxonomy.bp) not >> to have a documented interface. That said, you are not proposing the >> interface, >> just consuming it. >> >> Did the previous NDMP case define how tape spanning occurs, or does >> it just >> leave it to the DMA provider (like NetBackup)? I looked, but didn't >> see anything. >> >> From an ARC member prospective, the project is asking us to accept >> the interface >> as adequate because the project has indicated that it is. I guess >> I've done stranger things. >> -- >> Rick >> >> On 02/17/10 06:37 PM, Janice Chang wrote: >>> >>> >>> Rick Matthews wrote: >>>> Janice, >>>> I checked the spec and do see where you have a header definition and >>>> data definition. >>>> While the zfs send stream is listed as a committed format in the >>>> zfs(1) >>>> man page, that may be a result of a comment made to PSARC 2007/574. >>>> I didn't >>>> see any definition of the stream that would allow me to determine >>>> that the >>>> format was anything other than an unbounded byte stream. >>>> My concern the size of one tape. If the data is an unbounded byte >>>> stream, >>>> the indicator for end of data would normally be a tape mark (EOF >>>> essentially). >>>> There is always a tape mark at the end of tape. >>>> Since the data produced by zfs send can represent all active >>>> blocks in a volume, >>>> for example, the data stream produced may be larger than a single >>>> tape. This presents >>>> some problems, as I see it. 1) How do we know when the send stream >>>> is complete, and >>>> 2) if the stream is larger than a single tape, how do we know where >>>> the data stream >>>> is continued, and 3) how do we know we have all the data in the >>>> stream? >>>> Some of these issues are pointed out by PSARC 2006/185 zfs >>>> send/receive. >>>> A size of the data stream is one (but only one...there can be others) >>>> approach to knowing when the data is complete. tar (ustar) formats >>>> include >>>> sizes, which is why they may not have the same issue. I understand >>>> it may not >>>> be possible to have the "size" of a zfs send stream to be placed in >>>> a header >>>> of some sort. >>>> Please explain how the data can span multiple tapes, and can be >>>> considered >>>> complete. >>>> >>>> Thanks >>>> >>> Hi Rick.... >>> >>> The zfs send/recv stream knows how to determine the end of the >>> stream. Tape spanning is handled automatically by the data >>> management application (DMA) (e.g. Netbackup). In this case, >>> Netbackup is keeping track of which streams are on each of the tapes >>> and reconstituting a single stream on recovery. >>> >>> I believe this should address the three concerns you raised...... >>> >>> Thanks, >>> Janice >> >> -- --------------------------------------------------------------------- Rick Matthews email: Rick.Matthews@sun.com Sun Microsystems, Inc. phone:+1(651) 554-1518 1270 Eagan Industrial Road phone(internal): 54418 Suite 160 fax: +1(651) 554-1540 Eagan, MN 55121-1231 USA main: +1(651) 554-1500 --------------------------------------------------------------------- From sacadmin Wed Mar 24 05:45:40 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2OCjeBW023201 for ; Wed, 24 Mar 2010 05:45:40 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2OCje0c029147 for <@sunmail2sca.sfbay.sun.com:PSARC@sun.com>; Wed, 24 Mar 2010 05:45:40 -0700 (PDT) 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 <0KZS00F0NE43LP00@nwk-avmta-2.sfbay.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 24 Mar 2010 05:45:39 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZS00CRSE42GW30@nwk-avmta-2.sfbay.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 24 Mar 2010 05:45:38 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2OCjcxZ005069 for ; Wed, 24 Mar 2010 12:45:38 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZS00500DPLF500@mail-amer.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 24 Mar 2010 06:45:38 -0600 (MDT) Received: from Macintosh-335.local ([unknown] [67.166.17.211]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZS00H8QE41HDC0@mail-amer.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 24 Mar 2010 06:45:38 -0600 (MDT) Date: Wed, 24 Mar 2010 06:45:52 -0600 From: "Mark A. Carlson" Subject: Re: zfs-based ndmpd backup [PSARC 2010/048 Fast Track timeout 03/31/2010] In-reply-to: <4B7C1092.1050505@sun.com> Sender: Mark.Carlson@sun.com To: PSARC@sun.com Cc: Janice Chang , Dan Maslowski Message-id: <4BAA0980.2010103@sun.com> Organization: Oracle MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_PRd0kVCL4ObzA/EwCoi3Jg)" X-PMX-Version: 5.4.1.325704 References: <4B7C1092.1050505@sun.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 2106 This is a multi-part message in MIME format. --Boundary_(ID_PRd0kVCL4ObzA/EwCoi3Jg) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT This case, as you recall, already had it's inception review and has now updated the case directory with the final materials: drwxrwsr-x 2 markcarl sac 5 Mar 24 05:36 final.materials -rw-r--r-- 1 markcarl staff 35126 Mar 24 05:34 1pagerfinal.txt -rw-r--r-- 1 markcarl staff 35126 Mar 24 05:34 ndmpd-20final.txt -rw-r--r-- 1 markcarl staff 28802 Mar 24 05:34 zfs-ndmpd-4.3-official.odt I have started the timer as a Fast Track, but if folks have time to review the update to these materials, we could do an ARC business vote at today's Closed meeting. Thanks, -- mark --Boundary_(ID_PRd0kVCL4ObzA/EwCoi3Jg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT This case, as you recall, already had it's inception review and has
now updated the case directory with the final materials:

drwxrwsr-x   2 markcarl sac            5 Mar 24 05:36 final.materials
    -rw-r--r--   1 markcarl staff      35126 Mar 24 05:34 1pagerfinal.txt
    -rw-r--r--   1 markcarl staff      35126 Mar 24 05:34 ndmpd-20final.txt
    -rw-r--r--   1 markcarl staff      28802 Mar 24 05:34 zfs-ndmpd-4.3-official.odt

I have started the timer as a Fast Track, but if folks have time to review
the update to these materials, we could do an ARC business vote at
today's Closed meeting.

Thanks,

-- mark

--Boundary_(ID_PRd0kVCL4ObzA/EwCoi3Jg)-- From sacadmin Wed Mar 24 06:37:29 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2ODbTkc023940 for ; Wed, 24 Mar 2010 06:37:29 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2ODbT4a001003 for <@sunmail2sca.sfbay.sun.com:PSARC@sun.com>; Wed, 24 Mar 2010 08:37:29 -0500 (CDT) 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 <0KZS00407GIHZR00@brm-avmta-1.central.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 24 Mar 2010 07:37:29 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZS007IXGIG0MC0@brm-avmta-1.central.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 24 Mar 2010 07:37:29 -0600 (MDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o2ODbRso020490 for ; Wed, 24 Mar 2010 13:37:28 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZS00400GH27B00@fe-emea-13.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 24 Mar 2010 13:37:14 +0000 (GMT) Received: from [192.168.1.105] (cpc2-rdng20-2-0-cust917.15-3.cable.virginmedia.com [86.28.167.150]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZS0029VGI1FA70@fe-emea-13.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 24 Mar 2010 13:37:14 +0000 (GMT) Date: Wed, 24 Mar 2010 13:37:13 +0000 From: Darren J Moffat Subject: Re: zfs-based ndmpd backup [PSARC 2010/048 Fast Track timeout 03/31/2010] In-reply-to: <4BAA0980.2010103@sun.com> Sender: Darren.Moffat@sun.com To: "Mark A. Carlson" Cc: PSARC@sun.com, Janice Chang , Dan Maslowski Message-id: <4BAA1589.5040105@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4B7C1092.1050505@sun.com> <4BAA0980.2010103@sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1.7) Gecko/20100214 Lightning/1.0b1 Thunderbird/3.0.1 Status: RO Content-Length: 675 On 24/03/2010 12:45, Mark A. Carlson wrote: > This case, as you recall, already had it's inception review and has > now updated the case directory with the final materials: > > drwxrwsr-x 2 markcarl sac 5 Mar 24 05:36 final.materials > -rw-r--r-- 1 markcarl staff 35126 Mar 24 05:34 1pagerfinal.txt > -rw-r--r-- 1 markcarl staff 35126 Mar 24 05:34 ndmpd-20final.txt > -rw-r--r-- 1 markcarl staff 28802 Mar 24 05:34 zfs-ndmpd-4.3-official.odt > > I have started the timer as a Fast Track, but if folks have time to review > the update to these materials, we could do an ARC business vote at > today's Closed meeting. Case looks fine to me it gets my +1. -- Darren J Moffat From sacadmin Wed Mar 24 10:22:59 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o2OHMxsP001259 for ; Wed, 24 Mar 2010 10:22:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o2OHMrjj004606 for <@sunmail2sca.sfbay.sun.com:PSARC@sun.com>; Wed, 24 Mar 2010 12:22:58 -0500 (CDT) 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 <0KZS0070TQY9U400@nwk-avmta-2.sfbay.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 24 Mar 2010 10:22:57 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KZS000M5QXQBKB0@nwk-avmta-2.sfbay.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 24 Mar 2010 10:22:38 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o2OHMbpr011435 for ; Wed, 24 Mar 2010 17:22:37 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0KZS00800Q13MD00@mail-amer.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 24 Mar 2010 11:22:37 -0600 (MDT) Received: from Macintosh-335.local ([unknown] [67.166.17.211]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0KZS00CKHQXPK740@mail-amer.sun.com> for PSARC@sun.com (ORCPT PSARC@sun.com); Wed, 24 Mar 2010 11:22:37 -0600 (MDT) Date: Wed, 24 Mar 2010 11:22:53 -0600 From: "Mark A. Carlson" Subject: Re: zfs-based ndmpd backup [PSARC 2010/048 Fast Track timeout 03/31/2010] In-reply-to: <4BAA0980.2010103@sun.com> Sender: Mark.Carlson@Sun.COM To: "Mark A. Carlson" Cc: PSARC@Sun.COM, Janice Chang , Dan Maslowski Message-id: <4BAA4A6D.7010600@sun.com> Organization: Oracle MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6OLIac9SRDVP236/hcdVrA)" X-PMX-Version: 5.4.1.325704 References: <4B7C1092.1050505@sun.com> <4BAA0980.2010103@sun.com> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 Status: RO Content-Length: 2593 This is a multi-part message in MIME format. --Boundary_(ID_6OLIac9SRDVP236/hcdVrA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT This case was approved in PSARC today. IAM file has been updated. -- mark On 3/24/10 6:45 AM, Mark A. Carlson wrote: > This case, as you recall, already had it's inception review and has > now updated the case directory with the final materials: > > drwxrwsr-x 2 markcarl sac 5 Mar 24 05:36 final.materials > -rw-r--r-- 1 markcarl staff 35126 Mar 24 05:34 1pagerfinal.txt > -rw-r--r-- 1 markcarl staff 35126 Mar 24 05:34 > ndmpd-20final.txt > -rw-r--r-- 1 markcarl staff 28802 Mar 24 05:34 > zfs-ndmpd-4.3-official.odt > > I have started the timer as a Fast Track, but if folks have time to review > the update to these materials, we could do an ARC business vote at > today's Closed meeting. > > Thanks, > > -- mark > > > --Boundary_(ID_6OLIac9SRDVP236/hcdVrA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT This case was approved in PSARC today.

IAM file has been updated.

-- mark

On 3/24/10 6:45 AM, Mark A. Carlson wrote:

This case, as you recall, already had it's inception review and has
now updated the case directory with the final materials:

drwxrwsr-x   2 markcarl sac            5 Mar 24 05:36 final.materials
    -rw-r--r--   1 markcarl staff      35126 Mar 24 05:34 1pagerfinal.txt
    -rw-r--r--   1 markcarl staff      35126 Mar 24 05:34 ndmpd-20final.txt
    -rw-r--r--   1 markcarl staff      28802 Mar 24 05:34 zfs-ndmpd-4.3-official.odt

I have started the timer as a Fast Track, but if folks have time to review
the update to these materials, we could do an ARC business vote at
today's Closed meeting.

Thanks,

-- mark

--Boundary_(ID_6OLIac9SRDVP236/hcdVrA)--