From nfs4-wg-request@sunroof.eng.sun.com Wed Aug 1 16:56:23 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04790
for ; Wed, 1 Aug 2001 16:56:23 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20113;
Wed, 1 Aug 2001 14:55:50 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18930;
Wed, 1 Aug 2001 13:55:04 -0700 (PDT)
Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71KscD15174
for ; Wed, 1 Aug 2001 13:54:38 -0700 (PDT)
Received: from dhcp-aus08-189.central.sun.com (dhcp-aus08-189.Central.Sun.COM [129.153.128.189])
by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08363;
Wed, 1 Aug 2001 14:54:50 -0600 (MDT)
Received: (from shepler@localhost)
by dhcp-aus08-189.central.sun.com (8.11.3+Sun/8.11.3) id f71Kse500576;
Wed, 1 Aug 2001 15:54:40 -0500 (CDT)
Date: Wed, 1 Aug 2001 15:54:40 -0500
From: Spencer Shepler
To: Ramesh Shankar
Cc: nfsv4
Subject: Re: A few clarifications ...
Message-ID: <20010801155440.B521@dhcp-aus08-189.eng.sun.com>
Reply-To: shepler@eng.sun.com
Mail-Followup-To: Spencer Shepler ,
Ramesh Shankar ,
nfsv4
References: <3B659D96.3070000@Novell.COM> <3B673F85.1030505@Novell.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3B673F85.1030505@Novell.COM>
User-Agent: Mutt/1.3.19i
On Tue, Ramesh Shankar wrote:
> >
> > > 3. Section 9.4.4 and section 9.5 (Page 84) are *totally* confusing.
> > > While it makes it appear in earlier sections (9.4.3, forexample) as if a
> > > client can continue to keep a file for which delegation has been opened
> > > by applying buffered opens and obtaining the correct stateids for use
> > > with READ/WRITE after the delegation is revoked, these sections seem to
> > > imply that such a case cannot be handled. I would assume that when a
> > > client loses delegation, it is to be interpreted to mean that the file
> > > is shared by other clients and it must not attempt to cache data for
> > > reading and writing without using cache validation techniques or
> > > explicit byte range locks.
> >
> > I think you're confusing delegation recall and revocation.
> >
>
> After seeing the cryptic :-# remark by Brent, I found out that the terms
> "recall" and "revocation" are used differently in the NFSv4 RFC. It
Do by "differently" do you mean inconsistently within RFC3010? In any
case, I will put an item on my list to make any necessary additions to
section 9.4 to clarify the usage of recall and revoke in the context
of delegations.
> would be useful if this is made more obvious than being hidden in some
> para. Interestingly, the NetApp technical report TR3085 "The NFS Version
> 4 protocol" (also available from the www.nfsv4.org) uses the term
> "revoke" in the way the RFC uses the term "recall".
>
> Thanks,
>
> S.R.
>
--
- Spencer -
From nfs4-wg-request@sunroof.eng.sun.com Wed Aug 1 17:19:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05470
for ; Wed, 1 Aug 2001 17:19:28 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07786;
Wed, 1 Aug 2001 15:19:35 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24796;
Wed, 1 Aug 2001 14:18:35 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71LICD15602
for ; Wed, 1 Aug 2001 14:18:12 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29347
for ; Wed, 1 Aug 2001 14:18:27 -0700 (PDT)
Received: from prv-mail21.provo.novell.com (PRV-MAIL21.PROVO.NOVELL.COM [137.65.81.126])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07005
for ; Wed, 1 Aug 2001 15:18:24 -0600 (MDT)
Received: from Novell.COM
(hema.dnsdhcp.provo.novell.com [137.65.57.24])
by prv-mail21.provo.novell.com; Wed, 01 Aug 2001 15:18:14 -0600
Message-ID: <3B68721C.1050300@Novell.COM>
Date: Wed, 01 Aug 2001 15:18:20 -0600
From: Ramesh Shankar
Organization: Novell Inc.
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20010131 Netscape6/6.01
X-Accept-Language: en
MIME-Version: 1.0
To: nfsv4
Subject: Re: A few clarifications ...
References: <3B659D96.3070000@Novell.COM> <3B673F85.1030505@Novell.COM> <20010801155440.B521@dhcp-aus08-189.eng.sun.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Spencer Shepler wrote:
> On Tue, Ramesh Shankar wrote:
>
>>>> 3. Section 9.4.4 and section 9.5 (Page 84) are *totally* confusing.
>>>> While it makes it appear in earlier sections (9.4.3, forexample) as if a
>>>> client can continue to keep a file for which delegation has been opened
>>>> by applying buffered opens and obtaining the correct stateids for use
>>>> with READ/WRITE after the delegation is revoked, these sections seem to
>>>> imply that such a case cannot be handled. I would assume that when a
>>>> client loses delegation, it is to be interpreted to mean that the file
>>>> is shared by other clients and it must not attempt to cache data for
>>>> reading and writing without using cache validation techniques or
>>>> explicit byte range locks.
>>>
>>> I think you're confusing delegation recall and revocation.
>>>
>>
>> After seeing the cryptic :-# remark by Brent, I found out that the terms
>> "recall" and "revocation" are used differently in the NFSv4 RFC. It
>
>
> Do by "differently" do you mean inconsistently within RFC3010? In any
> case, I will put an item on my list to make any necessary additions to
> section 9.4 to clarify the usage of recall and revoke in the context
> of delegations.
Well I thought the terms "revoke" and "recall" have been used
interchangeably in the RFC. Only when Brent pointed it out, did I find
this difference hidden in one of the paras on pp. 72 (last para of
section 9.2).
>> would be useful if this is made more obvious than being hidden in some
>> para. Interestingly, the NetApp technical report TR3085 "The NFS Version
>> 4 protocol" (also available from the www.nfsv4.org) uses the term
>> "revoke" in the way the RFC uses the term "recall".
The above paper was also partly responsible for my confusion :-)).
Thanks,
S.R.
From nfs4-wg-request@sunroof.eng.sun.com Wed Aug 1 18:45:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08353
for ; Wed, 1 Aug 2001 18:45:04 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09676;
Wed, 1 Aug 2001 16:44:30 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04707;
Wed, 1 Aug 2001 15:43:42 -0700 (PDT)
Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f71MhMD16015
for ; Wed, 1 Aug 2001 15:43:22 -0700 (PDT)
Received: from dhcp-aus08-189.central.sun.com (dhcp-aus08-189.Central.Sun.COM [129.153.128.189])
by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29266;
Wed, 1 Aug 2001 16:43:35 -0600 (MDT)
Received: (from shepler@localhost)
by dhcp-aus08-189.central.sun.com (8.11.3+Sun/8.11.3) id f71MhQF00744;
Wed, 1 Aug 2001 17:43:26 -0500 (CDT)
Date: Wed, 1 Aug 2001 17:43:26 -0500
From: Spencer Shepler
To: Ramesh Shankar
Cc: nfsv4
Subject: Re: A few clarifications ...
Message-ID: <20010801174326.K521@dhcp-aus08-189.eng.sun.com>
Reply-To: shepler@eng.sun.com
Mail-Followup-To: Spencer Shepler ,
Ramesh Shankar ,
nfsv4
References: <3B659D96.3070000@Novell.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3B659D96.3070000@Novell.COM>
User-Agent: Mutt/1.3.19i
On Mon, Ramesh Shankar wrote:
<...>
>
> ------------------------------
> Mail #1:
> ---------------------------------
>
> Hi Ramesh,
>
>
> > 1. Am I correct in understanding that while a delegation is granted to a
> > client at OPEN time, it is not automatically revoked when the client
> > performs a CLOSE? i.e. the delegation is revoked only in one of the
> > following ways:
> > > - Client doesn't renew lease
This would result in the delegation being revoked.
> > - Server revokes lease and client finally makes a DELEGRETURN call.
As you have pointed out in other email, this should be that the server
"recalls" the delegation and the client returns it with DELEGRETURN.
> > - Client volutanrily surrenders lease using DELEGRETURN call.
>
> The protocol makes it clear that DELEGRETURN allows a client to
> end an delegation, though there is no mention of CLOSE returning
> a delegation. I agree, some clarification required here.
Yes. I agree. Will add it to the list of todos.
> > 2. Related to the above. THere is a difference (I think) between NFS v4
> > delegation and CIFS oplocks. With NFS, since there is no per open
> > (stateful) file handle, client can buffer OPEN operations and then apply
> > them to the server at revocation time. However, CIFS uses stateful
> > handles and client cannot apply buffered open calls at lock
> revocation time.
>
> Yes, I recall that there's a "Type 2" oplock that behaves differently.
>
> > 3. Section 9.4.4 and section 9.5 (Page 84) are *totally* confusing.
> > While it makes it appear in earlier sections (9.4.3, forexample) as if a
> > client can continue to keep a file for which delegation has been opened
> > by applying buffered opens and obtaining the correct stateids for use
> > with READ/WRITE after the delegation is revoked, these sections seem to
> > imply that such a case cannot be handled. I would assume that when a
> > client loses delegation, it is to be interpreted to mean that the file
> > is shared by other clients and it must not attempt to cache data for
> > reading and writing without using cache validation techniques or
> > explicit byte range locks.
>
> I think you're confusing delegation recall and revocation.
>
> > 4. Is NFS locking mandatory or advisory? This is really obscure in the
> > RFC. While it talks explicitly about mandatory locking and how the
> > stateids are useful in enforcing them, the following make it confusing:
> > > - OPEN call returns information on whether mandatory locking is in
> place
> > on the file. This is not clear. Is this supposed to mean whether someone
> > already has a mandatory lock on the file or is this the UNIX world "file
> > enabled for mandatory locking via the file permission bits overloading"
> > scheme? In case of the former, what if the file gets a mandatory lock by
> > another client *after* one client has already opened it. In the latter
> > case, what happens if the file is not enabled for mandatory locking?
> > - Wording on pp76 makes it appear as if what is used by NFS is really
> > advisory locking.
> > > Any clarifications would be greatly appreciated.
>
> Locking is mandatory, though there are some "special" stateids
> for the benefit of UNIX users who are not used to being denied
> access this way. There's been some discussion on the mailing
> list on this topic recently.
Yes. This is another area that needs to be clarified. Will add it to
the list.
> Ramesh, I recommend you post these questions to the mailing list,
> nfsv4-wg@sunroof.eng.sun.com so that the group as a whole can
> see your comments and discuss them. In addition, document editor,
> Spencer Shepler, will read it too.
>
> Cheers
> Brent
> --------------
> Mail #2:
>
> Sorry to bug you Brent, but would appreciate if you could clarify this
> point as well, which is not discussed in the RFC 3010 clearly.
>
> OPEN takes nfs_lockowner and returns a stateid. This stateid serves as a
> shorthand for the tuple represented by
> nfs_lockowner. This is what must be passed to READ/WRITE. Will this
> stateid be always returned by the server or will it be returned only
> when a share mode restriction ( one of deny read, deny write, deny all)
> is specified? Specifically, if I had OPENed the file with deny none,
> will the server still give me a stateid?
Server will always return a stateid.
> LOCK (and so does UNLOCK!) takes a stateid and returns a stateid. Are
> these supposed to be same? Can they be different? I am assuming that
> once I do a LOCK, I have to use the state id returned by it for
> READ/WRITE and not the one returned by OPEN. This is not mentioned
> anywhere in the RFC BTW. If I do an unlock, then what happens? Which
> stateid am I supposed to use now for subsequent READ/WRITEs performed
> without holding any locks? The one returned by unlock? What if my server
> supported partial byte range locks? Should I have to differentiate
> between reading the locked range and unlocked range and send the correct
> stateids? THere is some wording on the last para of pp 54 which kind of
> gives some hints on how things are supposed to be, but it is a bit obscure.
The stateid represents the current, shared state between client and
server. When a stateid is returned, the client is to use that stateid
for subsequent operations that require it as a parameter. The state
discussions in the RFC will be updated and I will make sure to provide
the appropriate overview for this point.
--
- Spencer -
From nfs4-wg-request@sunroof.eng.sun.com Thu Aug 2 02:01:32 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00694
for ; Thu, 2 Aug 2001 02:01:31 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA04807;
Wed, 1 Aug 2001 23:02:01 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA11613;
Wed, 1 Aug 2001 23:00:54 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7260WD16867
for ; Wed, 1 Aug 2001 23:00:33 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13123
for ; Wed, 1 Aug 2001 23:00:43 -0700 (PDT)
From: boxtop1@altavista.com
Received: from rogerj ([216.64.140.59])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA04525
for ; Wed, 1 Aug 2001 23:00:38 -0700 (PDT)
Message-Id: <200108020600.XAA04525@mercury.Sun.COM>
To:
Subject: Heart attack victims needed for new business
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Wed, 1 Aug 2001 23:00:42
250,000 lives saved so far and this is just the beginning!
If you are like me, when you had your heart attack you
were so grateful to be alive, you thought your
doctor was a god. It was not until later, when he had
been back inside my heart twice more and was going in again for the third time, that I
called time-out.
I began my own research program. I found the scientific formula that saved my life. That
doctor sure misses my money, but I don't miss the pain or the mental anguish, and my family
doesn't
either.
We are starting a program to inform the world about the
most advanced heart disease prevention on earth. All of
us who have had these things don't want any more of
them, and don't want anyone else to have one either. We
invite you to share the information with us, and with
the world. As a team, we can save a lot of lives and
earn a lot of money in so doing.
Our personal experiences are available as are the
scientists extensive results and a $1 million proof
guarantee challenge. Look forward to helping you and
many more.
For your Free Information send an e-mail to: moreinfo1us@yahoo.com
with More Info in the Subject Line and your name and phon# starting with erea code in the
body of the email.
This message is in full compliance with U.S. Federal requirements for commercial email
under
bill S.1618 Title lll, Section 301, Paragraph (a)(2)(C) passed by the 105th U.S. Congress
and cannot be considered SPAM since it includes a remove mechanism. Further
transmissions
by the sender may be stopped at no cost to you by replying to the email address
keylen@altavista.com and placing remove in the subject line.
We practice responsible mailing by honoring all remove requests, following all U.S. laws,
and oppose spamming. If you complain and have the remove address closed you are doing
a disservice
to other receivers of this message since they will have no mechanism to be removed from
future mailings. In addition, this message is in strict compliance with U.S. law so if you flame
the "remove
mailbox" we will report you to your ISP as a SPAMMER, which will result in your account
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 3 01:00:51 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17945
for ; Fri, 3 Aug 2001 01:00:51 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA06353;
Thu, 2 Aug 2001 22:01:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA12901;
Thu, 2 Aug 2001 22:00:58 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7350oD23491
for ; Thu, 2 Aug 2001 22:00:50 -0700 (PDT)
Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA29943
for ; Thu, 2 Aug 2001 22:00:52 -0700 (PDT)
Received: from mercury.Sun.COM ([61.142.168.88])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA06232
for ; Thu, 2 Aug 2001 22:00:51 -0700 (PDT)
Date: Thu, 2 Aug 2001 22:00:51 -0700 (PDT)
Message-Id: <200108030500.WAA06232@mercury.Sun.COM>
Received: by gaoming.gd.cn(EasyMail 2.0.0.0) http://easymail.yeah.net
Fri, 3 Aug 2001 12:58:21 -0000
From: "mary90230@angelfire.com"
To: "4649@aemail.com" <4649@aemail.com>
Subject: Get the word out about your business.
Content-Type: text/plain; charset="us-ascii";format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Triple Your Business in 60 Days or Less !!
Generate traffic to your website by the thousands!!!
Have complete control on who receives your ad.
Get thousands of Targeted visitors!!!
Why it Works.
Because you can deliver your message to millions of people for a fraction of the
cost of conventional advertising. That's right it's less than a classified ad that
would only reach a fraction of the audience.
What we offer you.
A complete turn-key operation for you.
* Total Control- We can expose your product to hundreds of millions of
people of your choosing.
* Full Marketing Team - Our marketing team will help you create an effective
marketing piece for your campaign .
* FREE use of software - we will provide you with state of the art software
specifcally designed to contact all the prospects you need.
* 100% customer service and tech support - Your success is our success !!
EASY As 1...2...3...
It's easy to get started simply reply today and we will set you up with
this fantastic system, specifically designed for "Your success on The Net"
Call 702-252-4626
To Unsubscribe to this email list, please go to delete@eurosport.com and type
"ELIMINATE" in the subject line. Thank you.
From nfs4-wg-request@sunroof.eng.sun.com Sat Aug 4 05:06:17 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24052
for ; Sat, 4 Aug 2001 05:06:16 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA13193;
Sat, 4 Aug 2001 02:06:35 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01301;
Sat, 4 Aug 2001 02:05:00 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7494pD27369;
Sat, 4 Aug 2001 02:04:51 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01293;
Sat, 4 Aug 2001 02:04:52 -0700 (PDT)
Received: from server01.brisbane.tradetech.com.au ([202.139.187.41])
by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11895;
Sat, 4 Aug 2001 03:04:50 -0600 (MDT)
Message-Id: <200108040904.DAA11895@lukla.Sun.COM>
Received: from host (02-104.044.popsite.net [64.24.247.104]) by server01.brisbane.tradetech.com.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
id PQZGK60H; Sat, 4 Aug 2001 12:40:24 +1000
From: "Steven Brock"
Subject: Many Others Have #51DF
To: join39f@lukla.Sun.COM
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Fri, 03 Aug 2001 21:32:33 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
This is a MIME Message
------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"
------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
***** This is an HTML Message ! *****
------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Executive Guild Membership
ApplicationResponse-O-Matic Form
Dear Candidate,=A0
You have been selected as a potential candidate for a free listing in=A0<=
br>
the 2001 Edition of the International Executive Guild Registry=2E=A0 =
Please accept our congratulations for this coveted honor=2E=A0
As this edition is so important in view of the new millennium, the=A0 =
International Executive Guild Registry will be published in two different=
=A0
formats; the searchable CD-ROM and the Online Registry=2E=A0
Since inclusion can be considered recognition of your career position=A0<=
br>
and professionalism, each candidate is evaluated in keeping with high=A0<=
br>
standards of individual achievement=2E In light of this, the Internationa=
l Executive
Guild thinks that you may make an interesting biographical subject=2E=A0<=
br>
We look forward to your inclusion and appearance in the International=A0<=
br>
Executive Guild's Registry=2E Best wishes for your continued success=2E=A0=
International Executive Guild=A0
Listing Dept=2E=A0
If you
wish to be removed from our list, please submit
your request at the
bottom of this email=2E
International Executive Guild Registration Form (US and Canada
Only)
Please
fill out this form if you would like to be
included on The International
Executive Guild, For accuracy and
publication purposes, please
complete and send this form at the earliest
opportunity=2E There is no
charge or obligation to be listed
on The International Executive Guild=2E
Your
Name
Your
Company
Title
Address
City
State
or Province
Country
ZIP/Postal
Code
Day
Time Telephone
Home
Phone
(Not
To Be Published)
Email
TO
HELP US IN CONSIDERING YOUR APPLICATION, PLEASE
TELL US A LITTLE ABOUT
YOURSELF=2E=2E=2E
(M=
fg,
Dist/Wholesaler, Retailer, Law Firm,
Investment
Bank, Commercial Bank, University,
Financial
Consultants, Ad Agency, Contractor, Broker,
etc=2E)
Note: Submitting this form=
will
be made by email, not by use of www=2E Confirmation of its de=
livery
is made by browsing your outgoing mail=2E Thank
you for filling in this form, we will contact you with more
information=2E List
Removal Click
Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0--
------=_NextPart_000_007F_01BDF6C7.FABAC1B0--
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 6 10:01:25 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23607
for ; Mon, 6 Aug 2001 10:01:24 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17424;
Mon, 6 Aug 2001 07:01:55 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14805;
Mon, 6 Aug 2001 06:27:04 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76DQqD03217
for ; Mon, 6 Aug 2001 06:26:52 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14793
for ; Mon, 6 Aug 2001 06:26:59 -0700 (PDT)
Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53])
by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14070
for ; Mon, 6 Aug 2001 06:26:59 -0700 (PDT)
Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91])
by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f76DQsX20020
for ; Mon, 6 Aug 2001 06:26:54 -0700 (PDT)
Received: from orbit-fe.eng.netapp.com (localhost [127.0.0.1])
by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f76DQrF06577
for ; Mon, 6 Aug 2001 06:26:54 -0700 (PDT)
Received: (from beepy@localhost)
by orbit-fe.eng.netapp.com (8.8.8+Sun/8.8.8) id GAA26504
for nfsv4-wg@sunroof.eng.sun.com; Mon, 6 Aug 2001 06:26:53 -0700 (PDT)
From: Brian Pawlowski
Message-Id: <200108061326.GAA26504@orbit-fe.eng.netapp.com>
Subject: Final comments on recharter of work group
To: nfsv4-wg@sunroof.eng.sun.com
Date: Mon, 6 Aug 2001 06:26:53 -0700 (PDT)
X-Mailer: ELM [version 2.4ME++ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Last comments requested before recharter. Several people have been
involved with implementation and evaluation of RFC 3010 and
certainly have not wanted to detract from that focus.
Say yes or no for the new charter - I'll be asking same question in our
working group meeting in London shortly.
-----------------------------------------------------------------------
There has been some discussion within the workgroup and with
our area directors about future directions for the workgroup.
Some obvious work was left undone (back-end protocol for
migrtion/replication), others have been discussed recently
on the WG alias.
The feedback we got from "the IETF" was to pursue a recharter
of the existing working group to pursue additional activities
in the future.
Below is a stab at a new charter for the working group - comments
are requested.
The last item on minor versioning is weak. Mark Wittle put forth
some suggestions for possible areas where minor versioning can
be used to enhance the the current specification. I suspect as
people review RFC 3010, that certain limitations in the protocol
may lend themselves to fixing via a minor rev. I just can't
convince myself how to put this down. It may be that specific
proposals for content of a minor revision will be dealt with
as another recharter effort.
Roughly, the working group needs to reach consensus on
a new charter and submit it to the IESG (I believe) for review
and comment. I have not thought hard on the exact timing.
What I want now are comments from you:-)
beepy
----------- proposed new charter for NFS V4 WG ----------
Description of Working Group:
The objective of this working group is to advance the state of NFS
technology by producing specifications to extend the original NFS
Version 4 work (RFC 3010) to provide additional capabilities.
o NFS version 4
Advance the protocol along the standards track, coordinating the
development of test suites to provide a high level of implementation
quality. The ONCRPC standards that NFSv4 references must also be
advanced. This includes work to make NFSv4 and the underlying ONCRPC
protocol compatible with IPv6.
o Replication and Migration
The original working group defined a mechanism for NFS clients and
servers to support replication and migration of data transparently
to an application. Left undefined in the initial work was the
server back end migration and replication mechanism. A
heterogeneous common solution is desirable for maximum
interoperability in a variety of configurations. This work will
focus on the protocols needed to create and maintain replicated
filesystems as well as migrating filesystems from one location to
another.
o Management
Work is needed to provide better management and administration
capabilities for NFS via a management MIB.
o Minor Versions
NFS Version 4 contains within it the capability for minor
versioning. Some discussions within the working group suggest
addressing additional requirements over the original charter. The
WG will work to identify additional requirements for NFSv4 and
determine if they are appropriate and worthwhile for a minor
version. This work may lead to additional work items and if they do
the charter of the WG will be revisited.
----- End of forwarded message from beepy -----
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 6 10:36:50 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24087
for ; Mon, 6 Aug 2001 10:36:49 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00330;
Mon, 6 Aug 2001 07:35:19 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02708;
Mon, 6 Aug 2001 07:34:50 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76EYdD03312
for ; Mon, 6 Aug 2001 07:34:39 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04004
for ; Mon, 6 Aug 2001 07:34:44 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA23131
for ; Mon, 6 Aug 2001 08:34:15 -0600 (MDT)
Received: from mosquito.inet.org (rja-laptop [10.30.34.139])
by gnat.inet.org (Postfix) with ESMTP id 8E1ED8266F
for ; Mon, 6 Aug 2001 10:30:09 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010806101818.00a32b00@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 06 Aug 2001 10:25:16 -0400
To: nfsv4-wg@sunroof.eng.sun.com
From: RJ Atkinson
Subject: Re: Final comments on recharter of work group
In-Reply-To: <200108061326.GAA26504@orbit-fe.eng.netapp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 09:26 06/08/01, Brian Pawlowski wrote:
> o Management
>
> Work is needed to provide better management and administration
> capabilities for NFS via a management MIB.
The WG shall consider undertaking development of MIBs for
NFS and for related protocols (e.g. ONC RPC). Any MIBs
developed will be modular rather than monolithic (e.g.
any NFS MIB will be separate from any ONC RPC MIB, so that
someone using ONC RPC but not NFS can still gain value
from the work).
I'd also like to see any re-charter stress the importance of
not breaking interoperability with the installed base of
pre-NFSv4 implementations and also stress the WG's need to more
seriously consider the operational implications of the protocol
changes and additions. This WG has had a real tendency of late
for "feature creep" with a result that the current protocol is
extremely difficult to deploy and maintain operationally. Continuing
the current approach creates real incentives for users to NOT
deploy NFS (or to un-deploy NFS) and instead deploy SMB/CIFS or AFS
(on grounds of operational simplicity of either of the latter
protocols as compared with current NFSv4). This is a bit of a
heretical view among the protocol designers, but I'm speaking
as one of the (very) few actual users/operators that participate
in the NFS WG. Frankly put, I do NOT want any more features.
I want a protocol spec that is stable and I want more focus on
operational considerations. I know I'm not alone in this in
the user/operator community.
Yours,
Ran
rja@inet.org
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 6 10:42:46 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24316
for ; Mon, 6 Aug 2001 10:42:46 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16554;
Mon, 6 Aug 2001 08:43:22 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03794;
Mon, 6 Aug 2001 07:42:35 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76EgPD03323
for ; Mon, 6 Aug 2001 07:42:25 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23190
for ; Mon, 6 Aug 2001 07:42:30 -0700 (PDT)
Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53])
by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29207
for ; Mon, 6 Aug 2001 08:42:32 -0600 (MDT)
Received: from hawk.corp.netapp.com (hawk.corp.netapp.com [10.10.20.101])
by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f76EgRX23729
for ; Mon, 6 Aug 2001 07:42:27 -0700 (PDT)
Received: from ussvlexc06.corp.netapp.com (localhost [127.0.0.1])
by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f76EgQQ21724;
Mon, 6 Aug 2001 07:42:26 -0700 (PDT)
Received: by ussvlexc06.corp.netapp.com with Internet Mail Service (5.5.2653.19)
id ; Mon, 6 Aug 2001 07:42:25 -0700
Message-ID: <8C610D86AF6CD4119C9800B0D0499E33335554@red.nane.netapp.com>
From: "Noveck, Dave"
To: "'Brian Pawlowski'" , nfsv4-wg@sunroof.eng.sun.com
Subject: RE: Final comments on recharter of work group
Date: Mon, 6 Aug 2001 07:42:24 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
My major comment is that, as written, it seems to assume
that RFC 3010 == NFS-v4, and we know that that is not
the case. There will be at least one (I *hope* it is
also at most one) follow-on RFC to address the problems
that have been found in RFC 3010. I expect that for
a while, getting to that final RFC for NFS-v4 will be
one of our major activities.
I don't think the item on minor versioning is weak. It is
vague, but I don't think that is a bad thing, under the
circumstances. Minor versioning gives us a lot of options
to deal with situations that come up (e.g. problems that
are real but not big enough to hold up v4.0, things that
the main protocol could provide to make the migration
protocol easier, etc.) as well as new features and it
would be nice if the re-charter didn't pose problems for
any of these.
-----Original Message-----
From: Brian Pawlowski [mailto:beepy@netapp.com]
Sent: Monday, August 06, 2001 9:27 AM
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Final comments on recharter of work group
Last comments requested before recharter. Several people have been
involved with implementation and evaluation of RFC 3010 and
certainly have not wanted to detract from that focus.
Say yes or no for the new charter - I'll be asking same question in our
working group meeting in London shortly.
-----------------------------------------------------------------------
There has been some discussion within the workgroup and with
our area directors about future directions for the workgroup.
Some obvious work was left undone (back-end protocol for
migrtion/replication), others have been discussed recently
on the WG alias.
The feedback we got from "the IETF" was to pursue a recharter
of the existing working group to pursue additional activities
in the future.
Below is a stab at a new charter for the working group - comments
are requested.
The last item on minor versioning is weak. Mark Wittle put forth
some suggestions for possible areas where minor versioning can
be used to enhance the the current specification. I suspect as
people review RFC 3010, that certain limitations in the protocol
may lend themselves to fixing via a minor rev. I just can't
convince myself how to put this down. It may be that specific
proposals for content of a minor revision will be dealt with
as another recharter effort.
Roughly, the working group needs to reach consensus on
a new charter and submit it to the IESG (I believe) for review
and comment. I have not thought hard on the exact timing.
What I want now are comments from you:-)
beepy
----------- proposed new charter for NFS V4 WG ----------
Description of Working Group:
The objective of this working group is to advance the state of NFS
technology by producing specifications to extend the original NFS
Version 4 work (RFC 3010) to provide additional capabilities.
o NFS version 4
Advance the protocol along the standards track, coordinating the
development of test suites to provide a high level of implementation
quality. The ONCRPC standards that NFSv4 references must also be
advanced. This includes work to make NFSv4 and the underlying ONCRPC
protocol compatible with IPv6.
o Replication and Migration
The original working group defined a mechanism for NFS clients and
servers to support replication and migration of data transparently
to an application. Left undefined in the initial work was the
server back end migration and replication mechanism. A
heterogeneous common solution is desirable for maximum
interoperability in a variety of configurations. This work will
focus on the protocols needed to create and maintain replicated
filesystems as well as migrating filesystems from one location to
another.
o Management
Work is needed to provide better management and administration
capabilities for NFS via a management MIB.
o Minor Versions
NFS Version 4 contains within it the capability for minor
versioning. Some discussions within the working group suggest
addressing additional requirements over the original charter. The
WG will work to identify additional requirements for NFSv4 and
determine if they are appropriate and worthwhile for a minor
version. This work may lead to additional work items and if they do
the charter of the WG will be revisited.
----- End of forwarded message from beepy -----
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 6 10:43:34 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24337
for ; Mon, 6 Aug 2001 10:43:33 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17286;
Mon, 6 Aug 2001 08:44:13 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03939;
Mon, 6 Aug 2001 07:43:56 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76EhlD03327
for ; Mon, 6 Aug 2001 07:43:47 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03927
for ; Mon, 6 Aug 2001 07:43:52 -0700 (PDT)
Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16965
for ; Mon, 6 Aug 2001 08:43:50 -0600 (MDT)
Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91])
by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f76EhkX23799
for ; Mon, 6 Aug 2001 07:43:46 -0700 (PDT)
Received: from orbit-fe.eng.netapp.com (localhost [127.0.0.1])
by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f76EhkD20093;
Mon, 6 Aug 2001 07:43:46 -0700 (PDT)
Received: (from beepy@localhost)
by orbit-fe.eng.netapp.com (8.8.8+Sun/8.8.8) id HAA29167;
Mon, 6 Aug 2001 07:43:45 -0700 (PDT)
From: Brian Pawlowski
Message-Id: <200108061443.HAA29167@orbit-fe.eng.netapp.com>
Subject: Re: Final comments on recharter of work group
In-Reply-To: <8C610D86AF6CD4119C9800B0D0499E33335554@red.nane.netapp.com> from "Noveck, Dave" at "Aug 6, 1 07:42:24 am"
To: Dave.Noveck@netapp.com (Noveck, Dave)
Date: Mon, 6 Aug 2001 07:43:45 -0700 (PDT)
Cc: beepy@netapp.com, nfsv4-wg@sunroof.eng.sun.com
X-Mailer: ELM [version 2.4ME++ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sorry, yes.
I meant to do RFC XXXX - due to the resubmission.
> My major comment is that, as written, it seems to assume
> that RFC 3010 == NFS-v4, and we know that that is not
> the case. There will be at least one (I *hope* it is
> also at most one) follow-on RFC to address the problems
> that have been found in RFC 3010. I expect that for
> a while, getting to that final RFC for NFS-v4 will be
> one of our major activities.
>
> I don't think the item on minor versioning is weak. It is
> vague, but I don't think that is a bad thing, under the
> circumstances. Minor versioning gives us a lot of options
> to deal with situations that come up (e.g. problems that
> are real but not big enough to hold up v4.0, things that
> the main protocol could provide to make the migration
> protocol easier, etc.) as well as new features and it
> would be nice if the re-charter didn't pose problems for
> any of these.
>
> -----Original Message-----
> From: Brian Pawlowski [mailto:beepy@netapp.com]
> Sent: Monday, August 06, 2001 9:27 AM
> To: nfsv4-wg@sunroof.eng.sun.com
> Subject: Final comments on recharter of work group
>
>
> Last comments requested before recharter. Several people have been
> involved with implementation and evaluation of RFC 3010 and
> certainly have not wanted to detract from that focus.
>
> Say yes or no for the new charter - I'll be asking same question in our
> working group meeting in London shortly.
>
> -----------------------------------------------------------------------
>
> There has been some discussion within the workgroup and with
> our area directors about future directions for the workgroup.
> Some obvious work was left undone (back-end protocol for
> migrtion/replication), others have been discussed recently
> on the WG alias.
>
> The feedback we got from "the IETF" was to pursue a recharter
> of the existing working group to pursue additional activities
> in the future.
>
> Below is a stab at a new charter for the working group - comments
> are requested.
>
> The last item on minor versioning is weak. Mark Wittle put forth
> some suggestions for possible areas where minor versioning can
> be used to enhance the the current specification. I suspect as
> people review RFC 3010, that certain limitations in the protocol
> may lend themselves to fixing via a minor rev. I just can't
> convince myself how to put this down. It may be that specific
> proposals for content of a minor revision will be dealt with
> as another recharter effort.
>
> Roughly, the working group needs to reach consensus on
> a new charter and submit it to the IESG (I believe) for review
> and comment. I have not thought hard on the exact timing.
>
> What I want now are comments from you:-)
>
> beepy
>
> ----------- proposed new charter for NFS V4 WG ----------
>
> Description of Working Group:
>
> The objective of this working group is to advance the state of NFS
> technology by producing specifications to extend the original NFS
> Version 4 work (RFC 3010) to provide additional capabilities.
>
> o NFS version 4
>
> Advance the protocol along the standards track, coordinating the
> development of test suites to provide a high level of implementation
> quality. The ONCRPC standards that NFSv4 references must also be
> advanced. This includes work to make NFSv4 and the underlying ONCRPC
> protocol compatible with IPv6.
>
> o Replication and Migration
>
> The original working group defined a mechanism for NFS clients and
> servers to support replication and migration of data transparently
> to an application. Left undefined in the initial work was the
> server back end migration and replication mechanism. A
> heterogeneous common solution is desirable for maximum
> interoperability in a variety of configurations. This work will
> focus on the protocols needed to create and maintain replicated
> filesystems as well as migrating filesystems from one location to
> another.
>
> o Management
>
> Work is needed to provide better management and administration
> capabilities for NFS via a management MIB.
>
> o Minor Versions
>
> NFS Version 4 contains within it the capability for minor
> versioning. Some discussions within the working group suggest
> addressing additional requirements over the original charter. The
> WG will work to identify additional requirements for NFSv4 and
> determine if they are appropriate and worthwhile for a minor
> version. This work may lead to additional work items and if they do
> the charter of the WG will be revisited.
>
>
> ----- End of forwarded message from beepy -----
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 6 13:10:36 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27762
for ; Mon, 6 Aug 2001 13:10:35 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06453;
Mon, 6 Aug 2001 11:09:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21505;
Mon, 6 Aug 2001 10:09:21 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f76H97D04042
for ; Mon, 6 Aug 2001 10:09:07 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08246
for ; Mon, 6 Aug 2001 10:09:14 -0700 (PDT)
Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53])
by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22849
for ; Mon, 6 Aug 2001 10:09:13 -0700 (PDT)
Received: from hawk.corp.netapp.com (hawk.corp.netapp.com [10.10.20.101])
by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f76H9DX06523;
Mon, 6 Aug 2001 10:09:13 -0700 (PDT)
Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1])
by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f76H9DC04003;
Mon, 6 Aug 2001 10:09:13 -0700 (PDT)
Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19)
id ; Mon, 6 Aug 2001 10:07:22 -0700
Message-ID: <8C610D86AF6CD4119C9800B0D0499E33335557@red.nane.netapp.com>
From: "Noveck, Dave"
To: "'Ramesh Shankar'" ,
nfsv4
Subject: RE: A few clarifications ...
Date: Mon, 6 Aug 2001 10:09:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
It looks like TR-3085 was based on an a pre-RFC draft, before
we clarified things by distinguishing recall and revocation.
Sorry about that.
-----Original Message-----
From: Ramesh Shankar [mailto:RShankar@Novell.COM]
Sent: Tuesday, July 31, 2001 7:30 PM
To: nfsv4
Subject: Re: A few clarifications ...
>
> > 3. Section 9.4.4 and section 9.5 (Page 84) are *totally* confusing.
> > While it makes it appear in earlier sections (9.4.3, forexample) as if a
> > client can continue to keep a file for which delegation has been opened
> > by applying buffered opens and obtaining the correct stateids for use
> > with READ/WRITE after the delegation is revoked, these sections seem to
> > imply that such a case cannot be handled. I would assume that when a
> > client loses delegation, it is to be interpreted to mean that the file
> > is shared by other clients and it must not attempt to cache data for
> > reading and writing without using cache validation techniques or
> > explicit byte range locks.
>
> I think you're confusing delegation recall and revocation.
>
After seeing the cryptic :-# remark by Brent, I found out that the terms
"recall" and "revocation" are used differently in the NFSv4 RFC. It
would be useful if this is made more obvious than being hidden in some
para. Interestingly, the NetApp technical report TR3085 "The NFS Version
4 protocol" (also available from the www.nfsv4.org) uses the term
"revoke" in the way the RFC uses the term "recall".
Thanks,
S.R.
From nfs4-wg-request@sunroof.eng.sun.com Tue Aug 7 07:24:50 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01012
for ; Tue, 7 Aug 2001 07:24:49 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15907;
Tue, 7 Aug 2001 04:25:18 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA04153;
Tue, 7 Aug 2001 04:24:26 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f77BOED08242;
Tue, 7 Aug 2001 04:24:14 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA04149;
Tue, 7 Aug 2001 04:24:19 -0700 (PDT)
Received: from uzphost1.uzp.gov.pl ([195.136.122.226])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27284;
Tue, 7 Aug 2001 05:24:15 -0600 (MDT)
Received: from host (06-107.081.popsite.net [64.24.246.107])
by uzphost1.uzp.gov.pl (2.0 Build 2119 (Berkeley 8.8.4)/8.8.4) with ESMTP
id NAA03133; Tue, 07 Aug 2001 13:10:36 +0200
Message-Id: <200108071110.NAA03133@uzphost1.uzp.gov.pl>
From: "Charles T. Miller"
Subject: Been Chosen #1F58
To: lis49r@uzphost1.uzp.gov.pl
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3
Mime-Version: 1.0
Date: Tue, 07 Aug 2001 06:57:13 -0500
Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0"
Content-Transfer-Encoding: 7bit
This is a MIME Message
------=_NextPart_000_007F_01BDF6C7.FABAC1B0
Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0"
------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
***** This is an HTML Message ! *****
------=_NextPart_001_0080_01BDF6C7.FABAC1B0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Executive Guild Membership
ApplicationResponse-O-Matic Form
Dear Candidate,=A0
You have been selected as a potential candidate for a free listing in=A0<=
br>
the 2001 Edition of the International Executive Guild Registry=2E=A0 =
Please accept our congratulations for this coveted honor=2E=A0
As this edition is so important in view of the new millennium, the=A0 =
International Executive Guild Registry will be published in two different=
=A0
formats; the searchable CD-ROM and the Online Registry=2E=A0
Since inclusion can be considered recognition of your career position=A0<=
br>
and professionalism, each candidate is evaluated in keeping with high=A0<=
br>
standards of individual achievement=2E In light of this, the Internationa=
l Executive
Guild thinks that you may make an interesting biographical subject=2E=A0<=
br>
We look forward to your inclusion and appearance in the International=A0<=
br>
Executive Guild's Registry=2E Best wishes for your continued success=2E=A0=
International Executive Guild=A0
Listing Dept=2E=A0
If you
wish to be removed from our list, please submit
your request at the
bottom of this email=2E
International Executive Guild Registration Form (US and Canada
Only)
Please
fill out this form if you would like to be
included on The International
Executive Guild, For accuracy and
publication purposes, please
complete and send this form at the earliest
opportunity=2E There is no
charge or obligation to be listed
on The International Executive Guild=2E
Your
Name
Your
Company
Title
Address
City
State
or Province
Country
ZIP/Postal
Code
Day
Time Telephone
Home
Phone
(Not
To Be Published)
Email
TO
HELP US IN CONSIDERING YOUR APPLICATION, PLEASE
TELL US A LITTLE ABOUT
YOURSELF=2E=2E=2E
(M=
fg,
Dist/Wholesaler, Retailer, Law Firm,
Investment
Bank, Commercial Bank, University,
Financial
Consultants, Ad Agency, Contractor, Broker,
etc=2E)
Note: Submitting this form=
will
be made by email, not by use of www=2E Confirmation of its de=
livery
is made by browsing your outgoing mail=2E Thank
you for filling in this form, we will contact you with more
information=2E List
Removal Click
Here
------=_NextPart_001_0080_01BDF6C7.FABAC1B0--
------=_NextPart_000_007F_01BDF6C7.FABAC1B0--
From nfs4-wg-request@sunroof.eng.sun.com Sun Aug 12 13:43:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17584
for ; Sun, 12 Aug 2001 13:43:47 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12889;
Sun, 12 Aug 2001 11:44:03 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29940;
Sun, 12 Aug 2001 10:43:37 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7CHhKD29476;
Sun, 12 Aug 2001 10:43:20 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23703;
Sun, 12 Aug 2001 10:43:31 -0700 (PDT)
From: bbngg@safe-mail.net
Received: from host02.mishima.co.jp (host02.mishima.co.jp [210.155.105.178])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12787;
Sun, 12 Aug 2001 11:43:24 -0600 (MDT)
Received: from 210.155.105.178 (04-190.044.popsite.net [64.24.247.190])
by host02.mishima.co.jp (8.9.3+3.2W/3.7W) with SMTP id CAA28551;
Mon, 13 Aug 2001 02:39:57 +0900
Message-Id: <200108121739.CAA28551@host02.mishima.co.jp>
Date: Sun, 12 Aug 01 13:17:06 EST
To: il3y42d8h@2efkyq0.com
Subject: They all said it can't Work
The Program
-------------------------------------------------------------------------------------------------------
AS SEEN ON NATIONAL TV --- INCREDIBLE $0 to $50,000 in
90 days!!!
-------------------------------------------------------------------------------------------------------
You can earn $50,000 or more in next the 90 days
sending e-mail. Seem impossible? Read on for details.
This is the letter you've been
reading about in the news lately. Due to the popularity of this
letter on the Internet, a major nightly news program recently devoted
an entire show to the investigation of the program described below to
see if it really can make people money.
The show also investigated whether or not the program was legal.
Their findings proved once and for all that there are absolutely no
laws prohibiting the participation in the program. This has helped
to show people that this is a simple, harmless and fun way to make
some extra money at home.
The results of this show have been truly remarkable. So many people
are participating that those involved are doing much better than ever
before. Since everyone makes more as more people try it out, its
been very exciting to be a part of lately. You will understand once you
experience it.
HERE IT IS BELOW:
*** Print This Now For Future Reference ***
The following income opportunity is one you may be interested in
taking a look at. It can be started with VERY LITTLE investment and
the income return is TREMENDOUS!!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
If you would like to make at least $50,000 in less than 90 days !
Please read the enclosed program...THEN READ IT AGAIN!!!
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY.It does
not require you to come into contact with people, do any hard work,
and best of all, you never have to leave the house except to get the
mail. If you believe that someday you'll get that big break that you
'vebeen waiting for, THIS IS IT! Simply follow the instructions,
andyour dreams will come true. This multi-level e-mail order
marketingprogram works perfectly...100% EVERY TIME.
E-mail is the sales tool of the future. Take advantage of this
non-commercialized method of advertising NOW!!! The longer you
wait, the more people will be doing business using e-mail. Get
your piece of this action!!!
MULTI-LEVEL MARKETING (MLM) has finally gained respectability.
It is being taught in the Harvard Business School, and both Stanford
Research and the Wall Street Journal have stated that between 50%
and 65% of all goods and services will be sold through multi-level
methods by the mid to late 1990's. This is a Multi-Billion Dollar
industry and of the 500,000 millionaires in the U.S., 20% (100,000)
made their fortune in the last several years in MLM. Moreover,
statistics show 45 people become millionaires everyday through
Multi-Level Marketing.
You may have heard this story before, but over the summer Donald
Trump made an appearance on the David Letterman show. Dave asked
him what he would do if he lost everything and had to start over from
scratch. Without hesitating, Trump said he would find a good network
marketing company and get to work. The audience started to hoot and
boo him. He looked out at the audience and dead-panned his response:
"That's why I'm sitting up here and you are all sitting out there!"
The enclosed information is something I almost let slip through my
fingers. Fortunately, sometime later I re-read everything and gave
somethought and study to it. My name is Johnathon Rourke. Two years
ago, the corporation I worked at for the past twelve years down-sized and my
position was eliminated. After unproductive job interviews, I decided
to open my own business. Over the past year, I incurred many
unforeseen financial problems. I owed my family, friends and
creditors over $35,000.
The economy was taking a toll on my business and I just couldn't seem
to make ends meet. I had to refinance and borrow against my home to
support my family and struggling business. AT THAT MOMENT something
significant happened in my life and I am writing to share the
experience in hopes that this will change your life FOREVER
FINANCIALLY!!!
In mid December, I received this program via e-mail. Six month's
prior to receiving this program I had been sending away for
information on various business opportunities. All of the programs I
received, in my opinion, were not cost effective. They were either
too difficult for me to comprehend or the initial investment was too much
for me to risk to see if they would work or not. One claimed that I would
make a million dollars in one year...it didn't tell me I'd have to write a
book to make it!
But like I was saying, in December of 1997 I received this program. I
didn't send for it, or ask for it, they just got my name off a
mailing list.THANK GOODNESS FOR THAT!!! After reading it several times, to make
sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY
MAKING PHENOMENON. I could invest as much as I wanted to start,
without putting me further into debt. After I got a pencil and paper
and figured it out, I would at least get my money back. But like most
of you I was still a little skeptical and a little worried about the
legal aspects of it all. So I checked it out with the U.S. Post Office
(1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After
determining the program was LEGAL and NOT A CHAIN LETTER, I decided
"WHY NOT."
Initially I sent out 10,000 e-mails. It cost me about $15 for my time
on-line. The great thing about e-mail is that I don't need any money
for printing to send out the program, and because all of my orders
are fulfilled via e-mail, my only expense is my time. I am telling
you like it is I hope it doesn't turn you off, but I promised myself that I would not
"rip-off" anyone, no matter how much money it made me.
In less than one week, I was starting to receive orders for REPORT #1
By January 13, I had received 26 orders for REPORT #1. Your goal is to
"RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF
YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first
step in making $50,000 in 90 days was done. By January 30, I had received
196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS
FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS
UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS,
THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I
had 196 orders for REPORT #2, 96 more than I needed. So I sat back
and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with
more coming in every day.
I paid off ALL my debts and bought a much needed new car. Please take
time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!!
! Remember, it won't work if you don't try it. This program does work
, but you must follow it EXACTLY! Especially the rules of not trying
to place your name in a different place. It won't work and you'll
lose out on a lot of money!
In order for this program to work, you must meet your goal of 20+
orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000
or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!!
If you choose not to participate in this program, I am sorry. It
really is a great opportunity with little cost or risk to you. If you
choose to participate, follow the program and you will be on your way
to financial security. If you are a fellow business owner and are in
financial trouble like I was, or you want to start your own business, consider
this a sign. I DID!
Sincerely,
Johnathon Rourke
A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM:
By the time you have read the enclosed program and reports, you
should have concluded that such a program, and one that is legal,
could not have been created by an amateur.
Let me tell you a little about myself. I had a profitable business
for 10 years. Then in 1979 my business began falling off. I was doing
the same things that were previously successful for me, but it wasn't
working. Finally, I figured it out. It wasn't me, it was the economy.
Inflation and recession had replaced the stable economy that had been
with us since 1945.I don't have to tell you what happened to the
unemployment rate... because many of you know from first hand
experience. There were more failures and bankruptcies than ever before.
The middle class was vanishing. Those who knew what they were doing
invested wisely and moved up. Those who did not, including those who
never had anything to save or invest, were moving down into the ranks
of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR
GET POORER." The traditional methods of making money will never allow
you to "move up" or "get rich", inflation will see to that.
You have just received information that can give you financial
freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE
BIT OF EFFORT." You can make more money in the next few months than you
have ever imagined. I should also point out that I will not see a penny of this
money, nor anyone else who has provided a testimonial for this
program. I have already made over 4 MILLION DOLLARS!I have retired
from the program after sending thousands and thousands of programs.
Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way
. It works exceedingly well as it is now. Remember to e-mail a copy
of this exciting report to everyone you can think of. One of the
people you send this to may send out 50,000...and your name will be on everyone of
them!
Remember though, the more you send out the more potential customers
you will reach.
So my friend, I have given you the ideas, information, materials and
opportunity to become financially independent. IT IS UP TO YOU NOW!
"THINK ABOUT IT"
Before you delete this program from your mailbox, as I almost did,
take a little time to read it and REALLY THINK ABOUT IT. Get a pencil
and figure out what could happen when YOU participate. Figure out the
worst possible response and no matter how you calculate it, you will
still make a lot of money! You will definitely get back what you
invested. Any doubts you have will vanish when your first orders come
in. IT WORKS!
Jody Jacobs, Richmond, VA
HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF
DOLLAR$
INSTRUCTIONS:
This method of raising capital REALLY WORKS 100% EVERY TIME.
I am sure that you could use up to $50,000 or more in the next 90
days. Before you say "BULL... ", please read this program carefully.
This is not a chain letter, but a perfectly legal money making
opportunity. Basically, this is what you do: As with all multi-level
businesses, we build our business by recruiting new partners and
selling our products. Every state in the USA allows you to recruit
new multi-level business partners,
and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY
MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal
selling. You do it privately in your own home, store or office. This
is the GREATEST Multi-Level Mail Order Marketing anywhere.
This is what you MUST do:
1. Order all 4 reports shown on the list below (you can't sell them
if youdon't order them).
-- For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT
YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN
ADDRESS (in case of a problem) to the person whose name appears on
the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON
YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS!
-- When you place your order, make sure you order each of the four
reports. You will need all four reports so that you can save them on
your computer and resell them.
-- Within a few days you will receive, via e-mail, each of the four
reports. Save them on your computer so they will be accessible for you to send
to the 1,000's of people who will order them from you.
2. IMPORTANT DO NOT alter the names of the people who are listed next
to each report, or their sequence on the list, in any way other than
is instructed below in steps "a" through "f" or you will lose out on
the majority of your profits. Once you understand the way this works,
you'll also see how it doesn't work if you change it. Remember, this
method has been tested,and if you alter it, it will not work.
a. Look below for the listing of available reports.
b. After you've ordered the four reports, take this advertisement and
remove the name and address under REPORT #4. This person has
made it through the cycle and is no doubt counting their $50,000!
c. Move the name and address under REPORT #3 down to REPORT #4.
d. Move the name and address under REPORT #2 down to REPORT #3.
e. Move the name and address under REPORT #1 down to REPORT #2.
f. Insert your name/address in the REPORT #1 position.
Please make sure you COPY ALL INFORMATION, every name and
address,
ACCURATELY!
3. Take this entire letter, including the modified list of names, and
save it to your computer. Make NO changes to the instruction portion
of this letter.
Your cost to participate in this is practically nothing (surely
you can afford $20). You obviously already have an Internet
connection and e-mail is FREE!
There are two primary methods of building your downline:
METHOD #1: SENDING BULK E-MAIL
Let's say that you decide to start small, just to see how it goes,
and we'll assume you and all those involved send out only 2,000
programs each. Let's also assume that the mailing receives a 0.5%
response. Using a good list the response could be much better. Also,
many people will send out hundreds of
thousands of programs instead of 2,000. But continuing with this
example, you send out only 2,000 programs. With a 0.5% response, that
is only 10 orders for REPORT #1. Those 10 people respond by sending
out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100
people respond and order REPORT #2. Those 100 mail out 2,000 programs
each for a total of 200,000.
The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000
send out 2,000 programs each for a 2,000,000 total. The 0.5% response
to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for
you. CASH!!! Your total income in this example is $50 + $500 + $5,000
+ $50,000 for a total of
$55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000
PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS
PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF
EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000.
Believe me, many people will do justthat, and more! By the way, your cost to
participate in this is practically nothing. You obviously already have an Internet
connection and e-mail is FREE!!! REPORT #2 will show you the best
methods for bulk e-mailing, tell you where
to obtain free bulk e-mail software and where to obtain e-mail lists.
METHOD #2 - PLACING FREE ADS ON THE INTERNET
Advertising on the internet is very, very inexpensive, and there are
HUNDREDS of FREE places to advertise. Let's say you decide to start
small just to see how well it works. Assume your goal is to get ONLY
10 people to participate on your first level. (Placing a lot of FREE
ads on the Internet will EASILY get a larger response.) Also assume that
everyone else in YOUR ORGANIZATION gets ONLY 10 downline members.
Follow this example to achieve the STAGGERING results below:
1st level--your 10 members with $5.......................................$50
2nd level--10 members from those 10 ($5 x 100)..................$500
3rd level--10 members from those 100 ($5 x 1,000)...........$5,000
4th level--10 members from those 1,000 ($5 x 10,000).....$50,000
THIS TOTALS ---------->$55,550
Remember friends, this assumes that the people who participate only
recruit 10 people each. Think for a moment what would happen if they
got 20 people to participate! Most people get 100's of participants!
THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them
the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE
ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR
name and address on it will be prompt because they can't advertise
until they receive the report!
AVAILABLE REPORTS
*** Order Each REPORT by NUMBER and NAME ***
Notes:
-- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT
ACCEPTED.
-- ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL.
-- Make sure the cash is concealed by wrapping it in at least two
sheets of paper. On one of those sheets of paper, include:
(a) the number & name of the report you are ordering, (b) your
e-mail address, and (c) your name & postal address.
PLACE YOUR ORDER FOR THESE REPORTS NOW:
REPORT #1 "The Insider's Guide to Advertising for Free on the
Internet"
ORDER REPORT #1 FROM:
J. Hogston
P.O. Box 241357
Apple Valley, MN 55124-1357
REPORT #2 "The Insider's Guide to Sending Bulk E-Mail on the Internet"
ORDER REPORT #2 FROM:
E- Solutions 101
PO Box 6411
Providence, RI 02940
REPORT #3 ""The Secrets to Multi-level Marketing on the Internet"
ORDER REPORT #3 FROM:
D.Vasicak
479 Bennett street
Luzerne, PA 18709
REPORT #4 "How to Become a Millionaire Utilizing the Power of Multi-level
Marketing and the Internet"
ORDER REPORT #4 FROM:
L. Daehlin
3208 Wellington Ct. Suite P
Raleigh, NC 27615
About 50,000 new people get online every month!
******* TIPS FOR SUCCESS *******
-- TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow
the directions accurately.
-- Send for the four reports IMMEDIATELY so you will have them when
the orders start coming in because: When you receive a $5 order, you
MUST send out the requested product/report.
-- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE.
-- Be patient and persistent with this program. If you follow the
instructions exactly, your results WILL BE SUCCESSFUL!
-- ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED!
******* YOUR SUCCESS GUIDELINES *******
Follow these guidelines to guarantee your success:
If you don't receive 20 orders for REPORT #1 within two weeks,
continue
advertising or sending e-mails until you do. Then, a couple of weeks
later you should receive at least 100 orders for REPORT#2. If you don
't, continue advertising or sending e-mails until you do. Once you
have received 100 or more orders for REPORT #2, YOU CAN RELAX,
because the system is already working for you, and the cash will
continue to roll in!
THIS IS IMPORTANT TO REMEMBER:
Every time your name is moved down on the list, you are placed in
front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by
watching which report people are ordering from you. If you want to
generate more income, send another batch of e-mails or continue
placing ads and start the whole process again! There is no limit to
the income you will generate from this business!
Before you make your decision as to whether or not you participate in
this program. Please answer one question. DO YOU WANT TO CHANGE YOUR
LIFE? If the answer is yes, please look at the following facts about
this program:
1. You are selling a product which does not Cost anything to PRODUCE,
SHIP OR ADVERTISE.
2. All of your customers pay you in CASH!
3. E-mail is without question the most powerful method of
distributing information on earth. This program combines the
distribution power of e-mail together with the revenue generating
power of multi-level marketing.
4. Your only expense--other than your initial $20 investment--is your
time!
5. Virtually all of the income you generate from this program is PURE
PROFIT!
6. This program will change your LIFE FOREVER.
ACT NOW!Take your first step toward achieving financial independence.
Orderthe reports and follow the program outlined above--SUCCESSwill
be yourreward.
Thank you for your time and consideration.
PLEASE NOTE: If you need help with starting a business, registering a
business name, learning how income tax is handled, etc., contact your
localoffice of the Small Business Administration (a Federal Agency)
1-800-827-5722 for free help and answers to questions. Also, the
InternalRevenue Service offers free help via telephone and free
seminars aboutbusiness tax requirements. Your earnings are highly
dependant on youractivities and advertising. The information
contained on this site and in the report constitutes no guarantees
stated nor implied. In the event that it is determined that this site
or report constitutes a guarantee of any kind, that guarantee is now
void. The earnings amounts listed on this site and in the report are
estimates only. If you have any questions of the legality of this
program, contact the Office of Associate Director for Marketing
Practices, Federal Trade Commission, Bureau of Consumer Protection in
Washington, DC.
/////////////////////////////////////////////////////////////////
Remove at bbnggs@netscape.net
/////////////////////////////////////////////////////////////////
From nfs4-wg-request@sunroof.eng.sun.com Sun Aug 12 15:51:05 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18335
for ; Sun, 12 Aug 2001 15:51:05 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02384;
Sun, 12 Aug 2001 13:50:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17088;
Sun, 12 Aug 2001 12:50:11 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7CJnqD29647;
Sun, 12 Aug 2001 12:49:52 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29021;
Sun, 12 Aug 2001 12:50:02 -0700 (PDT)
From: dirtlyslut@ozemail.com.au
Received: from mta03.mail.mel.aone.net.au (mta03.mail.au.uu.net [203.2.192.83])
by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19504;
Sun, 12 Aug 2001 12:50:01 -0700 (PDT)
Received: from ozemail.com.au ([203.108.68.160])
by mta03.mail.mel.aone.net.au with SMTP
id <20010812194958.OQDO23992.mta03.mail.mel.aone.net.au@ozemail.com.au>;
Mon, 13 Aug 2001 05:49:58 +1000
Subject: Decisions Decisions Decisions
Date: Mon, 13 Aug 2001 05:49:59
Message-Id: <506.358721.579240@ozemail.com.au>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
To: undisclosed-recipients:;
_
ADULTS ONLY! PICK YOUR PLEASURE FOR INSTANT ACCESS!
ANAL
INTRUDERS
Hardcore back-door action that will blow your
mind!
TEEN
GANGBANG
These nasty teen sluts think one is just not enough when
it comes to sex!!
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 13 20:57:01 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01018
for ; Mon, 13 Aug 2001 20:57:00 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA18213;
Mon, 13 Aug 2001 18:57:35 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18282;
Mon, 13 Aug 2001 17:56:00 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E0tFD04694;
Mon, 13 Aug 2001 17:55:15 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA21878;
Mon, 13 Aug 2001 17:55:25 -0700 (PDT)
Received: from server.huidar.com.tw ([211.22.237.123])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17340;
Mon, 13 Aug 2001 18:55:07 -0600 (MDT)
Date: Mon, 13 Aug 2001 18:55:07 -0600 (MDT)
Message-Id: <200108140055.SAA17340@patan.sun.com>
Received: from all-life.com by server.huidar.com.tw with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1458.49)
id QT7TC1K3; Fri, 10 Aug 2001 14:23:16 +0800
Reply-To:
From: "cosmo@asean-mail.com"
To: "0192@cosmo@asean-mail.com" <0192@cosmo@asean-mail.com>
Subject: mammoth website promtion
Content-Type: text/plain; charset="us-ascii";format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Triple Your Business in 60 Days or Less !!!
Generate traffic to your website by the thousands!!!
Have complete control on who receives your ad.
Get thousands of Targeted visitors!!!
Why it Works.
Because you can deliver your message to millions of people
for a fraction of the cost of conventional advertising.
That's right it's less than a classified ad that
would only reach a fraction of the audience.
What we offer you.
A complete turn-key operation for you.
* Total Control- We can expose your product to hundreds of
millions of people of your choosing.
* Full Marketing Team - Our marketing team will help you
create an effective marketing piece for your campaign .
* FREE use of software - we will provide you with state
of the art software specifcally designed to contact all
the prospects you need.
* 100% customer service and tech support -
Your success is our success !!!
EASY As 1...2...3...
It's easy to get started simply reply today and we will set
you up with this fantastic system, specifically designed for
"Your success on The Net."
Call 702-252-0285
To Unsubscribe to this email list, please go to:
deletes@eurosport.com
and type "deletes" in the subject line. Thank you.
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 13 21:03:53 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01110
for ; Mon, 13 Aug 2001 21:03:52 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA24606;
Mon, 13 Aug 2001 18:04:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19268;
Mon, 13 Aug 2001 18:04:07 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E13oD04785;
Mon, 13 Aug 2001 18:03:50 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23123;
Mon, 13 Aug 2001 18:04:00 -0700 (PDT)
Received: from mail.neoline.com ([211.45.136.2])
by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA18850;
Mon, 13 Aug 2001 19:04:07 -0600 (MDT)
Received: from plastic1 (slip-12-64-24-215.mis.prserv.net [12.64.24.215])
by mail.neoline.com (8.9.3/8.9.3) with ESMTP id JAA21297;
Tue, 14 Aug 2001 09:51:28 +0900
Message-Id: <200108140051.JAA21297@mail.neoline.com>
From: "Ted Perry"
Reply-To: crcleads1@yahoo.com
Subject: Great Mortgage Rates!!!
To: <#field0#@mail.neoline.com>
Date: Mon, 13 Aug 2001 17:27:02 -0700
X-Mailer: diffondi V4,0,1,0 (W95/NT) (Build: Feb 20 2001)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA01110
Whether a new home loan is what you seek or to refinance
your current home loan at a lower interest rate, we can help!
Mortgage rates haven't been this low in the last 12 months,
take action now!
Refinance your home with us and include all of those pesky
credit card bills or use the extra cash for that pool you've
always wanted...
Where others say NO, we say YES!!!
Even if you have been turned down elsewhere, we can help!
Easy terms! Our mortgage referral service combines the
highest quality loans with the most economical rates and
the easiest qualifications!
Take just 2 minutes to complete the following form.
There is no obligation, all information is kept strictly
confidential, and you must be at least 18 years of age.
Service is available within the United States only.
This service is fast and free.
Free information request form:
PLEASE VISIT
http://www.1xin.net/mortgagezone
****************************************************************
Since you have received this message you have either responded
to one of our offers in the past or your address has been
registered with us. If you wish to be removed please reply to:
mailto:crcleads2@yahoo.com?subject=remove
****************************************************************
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 13 21:07:32 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01135
for ; Mon, 13 Aug 2001 21:07:32 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA25446;
Mon, 13 Aug 2001 18:08:13 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19659;
Mon, 13 Aug 2001 18:07:56 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7E17cD04804;
Mon, 13 Aug 2001 18:07:38 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23544;
Mon, 13 Aug 2001 18:07:49 -0700 (PDT)
Received: from www.hitel.net ([211.39.201.4])
by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12964;
Mon, 13 Aug 2001 18:07:47 -0700 (PDT)
Received: from plastic1 (slip-12-64-24-215.mis.prserv.net [12.64.24.215])
by www.hitel.net (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with ESMTP
id KAA06020; Tue, 14 Aug 2001 10:01:54 +0900
Message-Id: <200108140101.KAA06020@www.hitel.net>
From: "Ted Perry"
Reply-To: crcleads1@yahoo.com
Subject: Great Mortgage Rates!!!
To: <#field0#@www.hitel.net>
Date: Mon, 13 Aug 2001 17:27:02 -0700
X-Mailer: diffondi V4,0,1,0 (W95/NT) (Build: Feb 20 2001)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA01135
Whether a new home loan is what you seek or to refinance
your current home loan at a lower interest rate, we can help!
Mortgage rates haven't been this low in the last 12 months,
take action now!
Refinance your home with us and include all of those pesky
credit card bills or use the extra cash for that pool you've
always wanted...
Where others say NO, we say YES!!!
Even if you have been turned down elsewhere, we can help!
Easy terms! Our mortgage referral service combines the
highest quality loans with the most economical rates and
the easiest qualifications!
Take just 2 minutes to complete the following form.
There is no obligation, all information is kept strictly
confidential, and you must be at least 18 years of age.
Service is available within the United States only.
This service is fast and free.
Free information request form:
PLEASE VISIT
http://www.1xin.net/mortgagezone
****************************************************************
Since you have received this message you have either responded
to one of our offers in the past or your address has been
registered with us. If you wish to be removed please reply to:
mailto:crcleads2@yahoo.com?subject=remove
****************************************************************
From nfs4-wg-request@sunroof.eng.sun.com Wed Aug 15 02:32:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10063
for ; Wed, 15 Aug 2001 02:32:53 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28956;
Wed, 15 Aug 2001 00:33:36 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA14773;
Tue, 14 Aug 2001 23:32:16 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7F6W8D11739
for ; Tue, 14 Aug 2001 23:32:08 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA06682
for ; Tue, 14 Aug 2001 23:32:11 -0700 (PDT)
From: OnLineCasino101@yahoo.com
Received: from bolet ([213.56.82.242])
by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA07862
for ; Wed, 15 Aug 2001 00:32:18 -0600 (MDT)
Received: from 300{72.0.00}Car (sdn-ar-002riprovP288.dialsprint.net [168.191.126.218]) by bolet (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id SAA19420; Tue, 14 Aug 2001 18:15:43 -0700
Message-ID: <0000459e7858$00006a86$000029d5@300{72.0.00}Car>
To:
Subject: Win a Brand New Ferrari Spider 360
Date: Wed, 15 Aug 2001 00:36:44 -0400
MIME-Version: 1.0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Priority: 1
X-MSMail-Priority: High
Reply-To: No_Life@uole.com
Content-Transfer-Encoding: quoted-printable
Welcome to Vegas on the Internet
We are giving away aBrand
New Ferrari Spider 360worth <=
font
color=3D"#008000">$240,000.00, also aHonda Acc=
ord EX-V6 worth$28,000.00and muc=
h more!
Open 24-7 with the BES=
T pay outs
of ALL online casino's! Play now win BIG!=
strong>
From nfs4-wg-request@sunroof.eng.sun.com Wed Aug 15 19:01:34 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02551
for ; Wed, 15 Aug 2001 19:01:33 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA16793;
Wed, 15 Aug 2001 16:01:30 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15750;
Wed, 15 Aug 2001 15:38:17 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.84.45] (may be forged))
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FMc9D15423
for ; Wed, 15 Aug 2001 15:38:09 -0700 (PDT)
Received: from eng.sun.com (terra.Eng.Sun.COM [129.146.86.99])
by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7FMc9g390703;
Wed, 15 Aug 2001 15:38:09 -0700 (PDT)
Sender: Brent.Callaghan@eng.sun.com
Message-ID: <3B7AF9C9.7529A4B6@eng.sun.com>
Date: Wed, 15 Aug 2001 15:38:01 -0700
From: Brent
Organization: NFS Whackers
X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: minutes@ietf.org
CC: nfsv4-wg@sunroof.eng.sun.com
Subject: Minutes of nfsv4 WG meeting in London
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
NFSv4 Working Group Meeting @ 51st IETF, London
-----------------------------------------------
Reported by Brent Callaghan
After welcoming the participants and presenting the meeting
agenda, Brent Callaghan gave an update on the status of the RPC
standards that NFSv4 depends upon. Currently, RFC 1832 (XDR) is
at Draft and RFC's 1831 (RPC), 1833 (Binding) and 2203
(RPCSEC_GSS) are all at Proposed. RFC 1831 is pending the
addition of an "IANA Considerations" (RFC 2434) section for
administration of the program number space. RFC 2203
(RPCSEC_GSS) still awaits movement of the GSS-API standard (RFC
2743) to Draft.
Document editor, Spencer Shepler, described the "bakeoff" at the
University of Michigan/CITI as a success. The protocol was
tested between 5 implementations and no major issues were found.
He then went on to describe some updates to the protocol state
model, beginning with an pictorial explanation of the NFSv4
state hierarchy and its relationship to various threading models
(see slides). The state hierarchy begins with the clientID which
is established by the client with a SETCLIENTID call and
confirmed by the server. Associated with the clientID is a
lockowner, which corresponds to the PID on a POSIX client. The
server has a stateid which changes after any change in status of
file locking or file open. File delegation has its own
delegation-stateid.
One problem with the file open state has come to light as the
result of implementation experience. When a UNIX process forks,
the parent and child processes share a file descriptor to the
open file. This condition is not accurately reflected by the
file open state on the server. A proposed solution is to add
another level of indirection via an entity called a "openowner"
that can represent multiple processes on a client. Spencer plans
to incorporate the openowner into the pending updates to the
spec if the WG approves. From feedback at the bakeoff, the
implementors support this proposal.
Brian Pawlowski summarized the proposal for working group
re-charter to include on-going NFSv4 work for test suite
development, a management MIB, and a Replication and Migration
protocol. Brian agreed to submit the Re-charter text to the Area
Directors who will have the IESG consider it.
Brian summarized the aims of the replication and migration work:
Transparent, client failover for read-only replicas, good
performance across low bandwidth links, and security as good as
v4. He will work with Rob Thurlow to draft a requirements
document and publish it as an individual submission
Internet-Draft pending re-chartering the work group and since
the requirements described in this document may not be specific
to NFSv4, it will be circulated to other groups for comment.
The meeting concluded at 5:00pm.
-------------------------------
The slides from the meeting can be viewed at:
http://playground.sun.com/pub/nfsv4/presentations/ietf51
------------------------
From nfs4-wg-request@sunroof.eng.sun.com Thu Aug 16 05:42:30 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26877
for ; Thu, 16 Aug 2001 05:42:29 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA24260;
Thu, 16 Aug 2001 02:43:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29050;
Thu, 16 Aug 2001 02:42:28 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7G9gJD16361
for ; Thu, 16 Aug 2001 02:42:19 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29046
for ; Thu, 16 Aug 2001 02:42:22 -0700 (PDT)
From: agatha@drop.mydewdrop.com
Received: from dns.linkage.fr ([195.115.134.196])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA08053
for ; Thu, 16 Aug 2001 03:42:17 -0600 (MDT)
Received: from poste80.linkage.fr ([195.115.134.237])
by dns.linkage.fr with esmtp (Exim 3.12 #1 (Debian))
id 15XERw-00088f-00; Thu, 16 Aug 2001 06:08:04 +0200
Received: from 193.51.216.44 ([194.8.177.67])
by poste80.linkage.fr (Lotus Domino Build 166.1)
with SMTP id 2001081505084644:1404 ;
Wed, 15 Aug 2001 05:08:46 +0200
To:
Subject: Life Insurance
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-MIMETrack: Itemize by SMTP Server on poste80/Linkage/fr(Version 5.0 (Intl)|14 avril
1999) at 15/08/2001 05:08:53,
Serialize by Router on poste80/Linkage/fr(Version 5.0 (Intl)|14 avril 1999) at
16/08/2001 06:08:01,
Serialize complete at 16/08/2001 06:08:01
Date: Wed, 15 Aug 2001 03:08:53 GMT
Message-ID: <000073e72246$00001551$000065de@195.115.55.129>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
LIFEQUOTE SAVE UP TO 70% ON LIFE INSURANCE PREMIUMS
Protect Your Family In Case Of Death
Plan For Your Childs Education
Protect Your Estate
The LEADING source for Life Insurance Companies!
The BEST Agents!
And The FRIENDLIEST Staff!
CLICK HERE For a FREE Quote!
It's
QUICK , EASY and COMPLETE
If you would like to be removed from any further mailings just click here =
Remove Me and hi=
t send and you will automatically be removed from any other mailings.
From nfs4-wg-request@sunroof.eng.sun.com Thu Aug 16 09:52:53 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07008
for ; Thu, 16 Aug 2001 09:52:52 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01436;
Thu, 16 Aug 2001 06:53:06 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15369;
Thu, 16 Aug 2001 06:52:40 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GDqMD17713
for ; Thu, 16 Aug 2001 06:52:23 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18507
for ; Thu, 16 Aug 2001 06:52:26 -0700 (PDT)
Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26157
for ; Thu, 16 Aug 2001 07:52:22 -0600 (MDT)
Received: from hawk.corp.netapp.com (hawk.corp.netapp.com [10.10.20.101])
by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f7GDqLX28730;
Thu, 16 Aug 2001 06:52:21 -0700 (PDT)
Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1])
by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f7GDqLr04234;
Thu, 16 Aug 2001 06:52:21 -0700 (PDT)
Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19)
id ; Thu, 16 Aug 2001 06:53:04 -0700
Message-ID: <8C610D86AF6CD4119C9800B0D0499E3333558E@red.nane.netapp.com>
From: "Noveck, Dave"
To: "'Mike Kupfer'" ,
"Noveck, Dave"
Cc: "'nfsv4-wg@sunroof.eng.sun.com'" ,
"Roa, Guillermo"
Subject: RE: special stateids (was "LOOKUP vs OPEN in NFSV4")
Date: Thu, 16 Aug 2001 06:52:19 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Mike Kupfer wrote:
> [Dave Noveck wrote:]
> > This leaves,
> ...
> > all-ones-stateid on write -- about which the spec is unclear
> > (or I'm confused, or both).
> >
> > As not accounted for.
>
> Section 8.1.4 says this case does not bypass record locking checks.
>
> > Reading 8.1.4 closely, the first paragraph says that zero-stateids
> > are subject to conflicting locks and I assume that includes both
> > share reservations and byte-range locks (I assume the latter only
> > if they are mandatory but the spec doesn't say). Also, in the
> > penultimate sentence of the first paragraph, it says an error is
> > returned if there is a conflict with an "explicit lock". What's
> > an implicit lock?
>
> I believe "implicit lock" refers to the server's wrapping a READ or
> WRITE in a lock to insure atomicity. See the very last sentence of
> Section 8.1.4.
OK.
>
> > To top it off the last sentence of the paragraph
> > reads "This allows 'mandatory locking' to be implemented."
> > Any guess on what the referrent for "this" is in that sentence?
>
> I assumed it refers to the lock checking that happens when an all-0
> stateid is used.
Ok, Maybe. It just seems odd.
The server is implementing mandatory locking (for all files or for
particular files, such as those with some mode bit set). I guess
you could say that the fact that it doesn't completely ignore
mandatory locking on such IO requests "allows mandatory locking
to be implemented" but that just seems an odd way to describe the
fact that this form of IO, like others, obeys the constraints of
mandatory locking.
> > The next paragraph talks about stateid of all ones. It says that
> > READ operations bypass *record* locking checks on the server (my
> > emphasis). So do they bypass share reservations locks? The
> > implication is that they don't. But why? Generally, the poeple
> > who complain about Windows locks stopping them from accessing a
> > file are complaining about share reservations rather than record
> > (i.e. byte-range) locks.
>
> I dug through my archives, including some 1998 Sun-internal mail that
> led up to David Robinson's locking proposal, which is the basis for
> the current scheme.
>
> It looks like the idea was that Windows clients would use an all-0
> stateid, which would mean "I don't have any locks, I want to do I/O,
> please honor record locks and share reservations", since Windows apps
> expect mandatory locking semantics.
But that expectation means that they want (and expect) that their locks
will prevent others, including UNIX others, from doing IO with inconsistent
locks held. The exclusion is *mandatory*. The thing about mandatory
locking is it applies even when you do something incosistent, even
if you don't politely ask for it to.
As I understand the spec now, if we leave aside special stateid's
(and non-V4 clients and local access...), share locks are inherently
mandatory while it is up to the server to decide whether byte-range
locks have mandatory effect (and the server could do it for some files
based on mode bits or whatever). Is that everybody else's understanding?
Except for this all-ones/all-zeros stuff, there is no way for *clients*
to choose their locking semantics. Not that I think there should be.
> Unix clients would use an all-1
> stateid, which would mean "I don't have any locks, I want to do I/O,
> please don't honor any locks or share reservations", since Unix apps
> expect advisory locking semantics.
It would be possible to implement advisory lock semantics by allowing
byte-range locks to be created that don't have this property of excluding
inconsistent IO's, but the protocol doesn't allow any way for the client
to specify that on a per-lock basis.
But providing a way a for one client to ignore another client's mandatory
locks isn't advisory locking. It's something different and kind of
scary.
> We then modified the all-1 stateid
> so that reads could bypass locks, but writes couldn't.
Allowing mandatory locking to be bypassed on reads is harmless
(since the requestor knows he might get inconsistent data and
implicitly assents to that). On writes, it's anything but
harmless.
The issue with the lock bypass on reads is that all servers may
not be able to provide it. I'm pretty sure NT-based servers
would have problems with this.
> And at some point during the life of the spec we tried to tighten up
> the locking-related language, to clearly distinguish share
> reservations from record locking. In a few places I suspect we
> (accidentally) changed the meaning from "shares and record locks" to
> "record locks only".
>
> So, to answer Dave's question, I think that the current text in
> Section 8.1.4 should be changed. A READ with an all-1 stateid should
> bypass both record locks and share reservations, and a WRITE with an
> all-1 stateid is equivalent to a WRITE with an all-0 stateid.
"should bypass" as opposed to "must bypass"!
That's OK, but my preference would be to avoid two different ways
of doing the same thing. I would rather allow:
Read with all-0: Normal READ with no locks or opens. Subject
(of course) to mandatory locking.
Write with all-0: Normal WRITE with no locks or opens. Subject
(of course) to mandatory locking.
Read with all-1: Special READ which bypasses locking checks, and
thus an exception to mandatory locking, if the server supports the
exception.
And make invalid:
Write with all-1: Invalid since a WRITE which bypasses locking checks
is too horrible to contemplate (for long).
> > Finally (for those who haven't hit delete yet), there is the
> > issue of special stateid's and the grace period.
> >
> > "During the grace period, the server must reject READ and
> > WRITE operations".
> >
> > It doesn't seem to make an exception for special stateid's.
>
> I suspect the logic here is that the server has to recover
> delegations. So rejecting all I/Os, independent of the stateid, is
> the safest course.
Right. I think it would help if we added the following text at
the end of the fifth paragraph of section 8.5.2.
READs with a stateid of all-ones, must also return NFS4ERR_GRACE,
even though such READs bypass locking checks, unless the server
can determine that no reclaims of delegations can possibly occur.
From nfs4-wg-request@sunroof.eng.sun.com Thu Aug 16 13:26:37 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16598
for ; Thu, 16 Aug 2001 13:26:37 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25268;
Thu, 16 Aug 2001 11:26:16 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24883;
Thu, 16 Aug 2001 10:24:26 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.82.37] (may be forged))
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GHOFD19493
for ; Thu, 16 Aug 2001 10:24:15 -0700 (PDT)
Received: from peyto (vpn-129-147-152-146.Central.Sun.COM [129.147.152.146])
by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with SMTP id f7GHOJg619249
for ; Thu, 16 Aug 2001 10:24:20 -0700 (PDT)
Date: Thu, 16 Aug 2001 11:24:45 -0600 (MDT)
From: Robert Thurlow
Reply-To: Robert Thurlow
Subject: Replication and migration requirements
To: nfsv4-wg@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3B7AF9C9.7529A4B6@eng.sun.com>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
In his minutes from the NFSv4 WG at IETF 51, Brent Callaghan wrote:
> Brian summarized the aims of the replication and migration work:
> Transparent, client failover for read-only replicas, good
> performance across low bandwidth links, and security as good as v4.
I'd like to spark some discussion about the requirements for
replication and migration. Here are the requirements Brian
Pawlowski presented at IETF 49, lifted from:
http://playground.sun.com/pub/nfsv4/presentations/ietf49/beepy2.pdf
They're a fairly large set, and I'd like to find out who cares
about which parts. For that matter, I'd like to find out who
cares about replication and migration; this topic has not drawn
a lot of comments on the alias in quite a long time. I'll also
include Brian's listing of issues.
Requirements
o Transparent client failover
o For read-only replicas and migrated writable volumes
o Performance
o Bandwidth conservative
o Differences propagated
o Restartable
o Client lockout time minimized
o Security
o As good as V4
o Scalable
o Huge file systems
o Small file s ystems
o Capability negotiation between "peers"(?)
o I believe this referred to things like attribute differences
o Efficient multi-way replication (propagation)
o Correctness
o "Atomic" propagation of file system from client view
o Failover to a correct replica version
o TCP/ IP based
o No legacy UDP requirement
Issues
o Replica versioning non-existent
o Failing over to "correct" version of replica impossible?
o Base V4 protocol change?
o Proposal: Investigate versioning requirement
o Single vs. multi-master
o Multi-master entails conflict resolution
o Proposal: Single master copy sufficient - objections?
o Disconnected operation irrelevant
o Corollary to above
o Proposal: Disconnected operation for clients not required - objections?
o File oriented
o Fits with NFS model, and heterogeneous
o Efficiency concerns
o Block-oriented not heterogeneous
o Proposal: Draft proposal for comments.
o Replicating "opaque" (to NFS) local file system attributes
o Proposal: NFS Version 4 named attributes propagated - unsupported
attributes not
o Migration/replication only for V4
o Not a general (rdist) mechanism
o Lock and delegation propagation
o Certainly a requirement, but ouch!
o Proposal: Locking and delegation state propagated, acceptable
that it resembles a server reboot.
o We pushed need for reliable name/location service from clients to
servers
o Proposal: Investigate how far to tie back end protocol to name
sevice
Rob T
From nfs4-wg-request@sunroof.eng.sun.com Thu Aug 16 13:26:49 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16612
for ; Thu, 16 Aug 2001 13:26:48 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26316;
Thu, 16 Aug 2001 11:27:32 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25332;
Thu, 16 Aug 2001 10:26:01 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.82.37] (may be forged))
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GHPqD19565
for ; Thu, 16 Aug 2001 10:25:52 -0700 (PDT)
Received: from peyto (vpn-129-147-152-146.Central.Sun.COM [129.147.152.146])
by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with SMTP id f7GHPug619902
for ; Thu, 16 Aug 2001 10:25:56 -0700 (PDT)
Date: Thu, 16 Aug 2001 11:26:21 -0600 (MDT)
From: Robert Thurlow
Reply-To: Robert Thurlow
Subject: Re: Replication and migration requirements
To: nfsv4-wg@sunroof.eng.sun.com
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
I wrote:
> They're a fairly large set, and I'd like to find out who cares
> about which parts.
Here are my thoughts on this. Since we did NFS client failover
in Solaris 2.6, it's been an occasional issue that we didn't
provide a good tool to create replicas. When we look at the
geographical diversity of our customers, a good way to create
replicas is important, so we have a block-based replication
tool as other vendors do. With NFSv4, I think our customers
will want something more standard between different types of
servers, and something more useful than 'cp -r' or 'rdist'.
> o Transparent client failover
> o For read-only replicas and migrated writable volumes
This is summarizing the holy grail. For read-only replication,
this does not seem too hard. For migration, things are harder.
I like the idea of trying to transfer lock and delegation state
and forcing some reboot-like recovery effort onto the client.
But I am willing to punt if need be.
> o Performance
> o Bandwidth conservative
> o Differences propagated
> o Restartable
> o Client lockout time minimized
This seems important; if the performance is not good especially
for incremental updates of replicas, we have a problem. I've
been thinking about transaction logs and snapshots to get the
minimum set of changes, and I've also been looking at Andrew
Tridgell's rsync algorithm, which could help when a log is not
available. This might be one of the first forks in the road
for deciding how the protocol operates.
> o Security
> o As good as V4
This is very important; fortunately, we do have NFSv4 potentially
providing a lot of infrastructure. I say 'potentially' because I
do not at this point assume that the wire protocol will be an RPC
based application; we might do better to stuff XDR'd data down a
TCP socket. This choice is another fork in the road.
> o Scalable
> o Huge file systems
> o Small file s ystems
This is important, but also seems linked to performance to me.
I don't know how this requirement guides our design.
> o Capability negotiation between "peers"(?)
> o I believe this referred to things like attribute differences
This does have to do with whether your filesystem will look
the same in all respects after a migration. I think the right
way to do this is to try to inform the sys admin about potential
loss of data before the migration or replication begins, to give
them the choice of how to handle it. If a database relies on
named attributes to operate, you must not transfer its files to
a server that does not support named attributes, but if you know
you don't care, you might proceed.
> o Efficient multi-way replication (propagation)
This is good, but if multiple connections are used for propagation
it's not obvious how this would affect the server-to-server protocol.
If we were to choose a multicast protocol instead, this would be
relevant.
> o Correctness
> o "Atomic" propagation of file system from client view
> o Failover to a correct replica version
As Brian's issues pointed out, we have no basis for tracking a
replica version in NFSv4. In practice, I don't think this is
necessary. Here at Sun, our internal network has a large-scale
replica set of binaries and support files, and uses no version
number. If an application needs a version of a data set, the
application should create one.
> o TCP/ IP based
> o No legacy UDP requirement
This seems obviously correct (and implies not using multicast).
> Issues
>
> o Single vs. multi-master
> o Multi-master entails conflict resolution
> o Proposal: Single master copy sufficient - objections?
> o Disconnected operation irrelevant
> o Corollary to above
> o Proposal: Disconnected operation for clients not required - objections?
I agree that multi-master and disconnected use are out of scope.
One thing this leaves open is the possibility of having both a
read-write master and a number of read-only replicas. AFS did
this by just having separate mount points; DCS/DFS did a better
job via the token manager. If the namespace can inform clients
where the read-write master is, it should be possible to have
clients forget about alternate replicas while a process on the
client is modifying to a file. This is mostly work done by the
client, and likely has no bearing on the server-to-server protocol.
> o Migration/replication only for V4
> o Not a general (rdist) mechanism
I think this server-to-server protocol should not stand alone
from NFSv4, but clearly if you have managed to move a filesystem
coherently and correctly between servers, any other protocol
can share the data with clients. I do believe people will use
this to move filesystems to be used by NFSv2, NFSv3 and CIFS
clients, and I think that's good. I do not want requirements
of those protocols affecting what we design here, though.
Comments?
Rob T
From nfs4-wg-request@sunroof.eng.sun.com Thu Aug 16 14:40:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18920
for ; Thu, 16 Aug 2001 14:40:33 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04858;
Thu, 16 Aug 2001 12:40:51 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13070;
Thu, 16 Aug 2001 11:40:28 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GIeJD20099
for ; Thu, 16 Aug 2001 11:40:19 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13650
for ; Thu, 16 Aug 2001 11:40:22 -0700 (PDT)
Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53])
by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28585
for ; Thu, 16 Aug 2001 11:40:21 -0700 (PDT)
Received: from hawk.corp.netapp.com (hawk.corp.netapp.com [10.10.20.101])
by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f7GIeLX12757;
Thu, 16 Aug 2001 11:40:21 -0700 (PDT)
Received: from ussvlexc06.corp.netapp.com (localhost [127.0.0.1])
by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f7GIeKR20884;
Thu, 16 Aug 2001 11:40:20 -0700 (PDT)
Received: by ussvlexc06.corp.netapp.com with Internet Mail Service (5.5.2653.19)
id ; Thu, 16 Aug 2001 11:40:19 -0700
Message-ID: <8C610D86AF6CD4119C9800B0D0499E33335594@red.nane.netapp.com>
From: "Noveck, Dave"
To: "'shepler@eng.sun.com'" ,
nfsv4-wg@sunroof.eng.sun.com
Subject: RE: RFC3010's state model with a unix/posix client
Date: Thu, 16 Aug 2001 11:40:18 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
High-level comment: I think this is basically the right approch
(although I couldn't avoid disagreeing on a few details). Over the
past few months I've tried any number of alternatives which
simply don't work or seem afflicted by terminal complexity.
If there is something wrong with this, I think we're only going
to find it during implementation. I'd like to at least get this into
the form of a .x file, independent of the process of getting all the
explanations into a spec-worthy form. I'd like to nail down the
.x file for the upcoming bakeoff as soon as we can so all the
participants can implement this change (since it's the biggest one)
in time for the October bakeoff.
Spencer Shepler:
> There is an outstanding issue with respect to the support of POSIX
> locking requirements and the corresponding state management in
> RFC3010.
>
> To restate the problem, with a Posix client in the event of a fork(),
> the child process has a file descriptor set that matches that of the
> parent process. The child is then able to read/write and more
> importantly lock byte ranges of those file descriptors. With the
> current definition/interpretation of the stateid, a client
> implementation can not properly provide the Posix locking
> functionality for the child process. The reason for this is that the
> lock_owner represents a process at the client and that lock_owner is
> associated at OPEN time.
>
> There have been a couple of suggestions to enable posix locking at the
> client. The first was to have the client interpret the lock_owner more
> broadly and therefore arbitrate locking interaction at the client
> first (between processes that share heritage) and then move requests
> to the server for final arbitration. The second suggestion was to
> introduce a OPENFH (for lack of a better operation pneumonic) that
> would take a filehandle and be used to associate a new lock_owner with
> what was to be an active or open file at the client.
>
> The first of these suggestions places additional implementation burden
> at the client. One can argue that this implementation burden will be
> present in support of delegations.
One can argue that, but I don't think it is the case.
It is one thing for a client to arbitrate among it's
processes when a delegation guarantees that there are no
processes on other clients contending. When you have to
do that arbitration when other clients may be actively accessing
the file, it is much more difficult.
There are major fairness issues that arise since processes
on one client could capture a lock and trade it among themsleves
indefinitely.
Another set of issues arise because of our old friend POSIX
locking semantics. If one process requests a lock which
spans multiple existing locks, some of which are held by
processing on the current client (inlcuding the issuing
process) and some not, things get real interesting.
> However, if the client
> implementation does not provide support for delegations then this work
> will not be present. Also, it is unclear if there are implementation
> or protocol problems with this particular interpretation.
I say, "Don't go there".
>
> The second suggestion of using OPENFH also does not solve some
> implementation issues. For example, the Solaris API for filesystems
> does not provide a reference to the "file descriptor" returned to a
> process as a result of open(). The Solaris filesystem API passes the
> vnode or underlying filesystem data structure. This vnode represents
> the file on that client filesystem for all processes who hold an
> open() reference. Therefore, the NFSv4 client on Solaris has the
> pointer to the shared filesystem data structure and the process-id of
> the requestor to use as keys to find related data structures. In the
> case of a child process making a reference to a file descriptor that
> was inherited from the parent, the Solaris NFSv4 client would not be
> able to reliably find the data structure that contains the stateid.
> Therefore, the presence of the OPENFH operation does not resolve how
> the Solaris NFSv4 client would keep from having dangling references to
> an OPEN file at the server.
>
> At the bakeoff, we had some discussions about these issues and
> formulated a possible solution that would allow for the model that
> most Unix/Posix clients implement while offering a solution that would
> satisfy a Windows client as well.
>
>
> The Ideas/Proposal:
>
> The first major change is to move to a two-level state model in
> NFSv4. Yes, this is a major change but builds on the existing
> experience in NFSv4 of using stateids and sequence numbers to handle
> the various cases of retransmissions, etc. This model is similar to
> the Unix/Posix model for open files that are shared between parent and
> child and file locking which is not.
>
> With this new model, there is what we will refer to as an OPEN state
> stream that is represented by an open_owner/open_stateid. This
> open_owner/open_stateid is the "parent" of any locking state that is
> instantiated at the client for the open file. The open_owner
> generally represents a parent process and its children since they
> share file descriptors. The client implementation may choose to
> expand that interpretation to include all processes that open() the
> file and that share credentials (as an example).
>
> >From this open_owner/open_stateid, the client can then instantiate a
> "traditional" lock_owner by referring to the open_stateid. The
> lock_owner then can be used for a file locking state stream (which
> would include read/write requests).
reads and writes aren't really part of a stream since they are not
serialized (and that's a good thing). But perhaps you are implying
that the stateid in reads and writes must be one that you got from
lock/unlock. That wasn't my understanding and I think it would be
better if reads and write could use one obtained from either OPEN
or LOCK. (see below).
> Generally, this lock_owner would
> be initiated when a file lock request is made and would represent the
> process.
>
> Both open_owner and lock_owner would have their own sequence_ids so
> that related requests are ordered at the server. The rules that exist
> today for replay would remain in place.
>
> The OPEN operation would look something like this (a lot of existing
> detail has been left out to simplify the discussion):
>
> OPEN
>
> (cfh), name, open_owner, open_seqid -> (cfh), open_stateid
>
> LOCK
> (cfh), open_stateid, lock_owner, lock_seqid -> (cfh), lock_stateid
>
>
Here I'm assuming that you're just omitting the range, lock-type, etc. in the iinterest of simplicity.
> There would still be an OPEN_CONFIRM call to be used when the server
> first encounters an open_owner/seqid. We would also introduce a
> LOCK_CONFIRM to establish the lock_owner/seqid as well
>
> Because we are introducing an open_owner that potentially represents
> multiple processes at the client and the OPEN call uses a name for the
> OPEN, it is difficult or burdensome for the client to serialize OPEN
> operations to the server. This introduces the problem that the client
> may generate two OPEN requests to the server that use the same
> open_owner. This would be the case where hardlinks are present or the
> client chooses not to serialize OPENs.
>
> If this occurs, the server will return two open_stateid values to the
> client but the client will not know which one to use. To address this
> problem and the outstanding request that stateid values be enlarged in
> the protocol, the stateid will become a little less opaque and look
> something like this:
>
> stateid4 {
> uint32_t seqid;
> opaque serverstuff<12>;
> };
>
>
> The server will use the seqid to indicate the order in which the
> stateids for the related *_owner value are created.
>
> In the case of simultaneous OPENs, the client will inspect
> open_stateid.seqid to determine which stateid is the most recent. The
> client will then use that stateid for subsequent operations.
With the 32-bit seqid here, you can't exclude the possiblity of
wraparound. This means that you have to be a little careful
specifying and implementing the test to see which is "most
recent". I don't think it's worth going to a 64-bit sequence
since you are not going to have anything like 2 billion
simultaneous outstanding opens for a given lockowner, but
we do have to be careful.
>
>
> For the Windows client that does not require the ability to have
> multiple lock_owners associated with an open_owner, there will be a
> one lock_owner per open_owner.
>
> As an optimization, the OPEN operation can also be augmented to handle
> the general case of one open_owner to one lock_owner with something
> like:
>
> OPEN
>
> (cfh), name, open_owner, open_seqid, lock_owner, lock_seqid ->
> (cfh), open_stateid, lock_stateid
>
This is what I don't understand, or, if I understand it, I don't think
it is required.
This OPEN is not doing a LOCK (or is it and the lock parameters are
just omitted)?
It seems to me that you should just do the open and present the stateid
that the open gives to reads and writes, until and unless that process
does a lock. The server is capable of assigning opaque stateid's so
it can distiguish between those returned by open and those returned
by lock/unlock.
When it receives an IO, the server needs to use the stateid to
determine whether, for any putatively conflicting lock (either
byte-range or share reservation), whether the issuer is in fact
the owner (which vitiates the conflict) or is distinct from that
owner (which causes the conflict to be recognized). So, if the
server receives a an open-stateid, the issuer is the owner for
share reservations made by the same open-owner but is not the
owner for any byte-range locks. Essentially an open stateid
can be coerced on the server to serve as lock stateid for that
open stateid with a null locking sequence appended, independent
of what the lock_owner for each (i.e. none) of those lcoking
request would be.
-----Original Message-----
From: Spencer Shepler [mailto:shepler@eng.sun.com]
Sent: Tuesday, July 31, 2001 3:57 PM
To: nfsv4-wg@sunroof.eng.sun.com
Subject: RFC3010's state model with a unix/posix client
There is an outstanding issue with respect to the support of POSIX
locking requirements and the corresponding state management in
RFC3010.
To restate the problem, with a Posix client in the event of a fork(),
the child process has a file descriptor set that matches that of the
parent process. The child is then able to read/write and more
importantly lock byte ranges of those file descriptors. With the
current definition/interpretation of the stateid, a client
implementation can not properly provide the Posix locking
functionality for the child process. The reason for this is that the
lock_owner represents a process at the client and that lock_owner is
associated at OPEN time.
There have been a couple of suggestions to enable posix locking at the
client. The first was to have the client interpret the lock_owner more
broadly and therefore arbitrate locking interaction at the client
first (between processes that share heritage) and then move requests
to the server for final arbitration. The second suggestion was to
introduce a OPENFH (for lack of a better operation pneumonic) that
would take a filehandle and be used to associate a new lock_owner with
what was to be an active or open file at the client.
The first of these suggestions places additional implementation burden
at the client. One can argue that this implementation burden will be
present in support of delegations. However, if the client
implementation does not provide support for delegations then this work
will not be present. Also, it is unclear if there are implementation
or protocol problems with this particular interpretation.
The second suggestion of using OPENFH also does not solve some
implementation issues. For example, the Solaris API for filesystems
does not provide a reference to the "file descriptor" returned to a
process as a result of open(). The Solaris filesystem API passes the
vnode or underlying filesystem data structure. This vnode represents
the file on that client filesystem for all processes who hold an
open() reference. Therefore, the NFSv4 client on Solaris has the
pointer to the shared filesystem data structure and the process-id of
the requestor to use as keys to find related data structures. In the
case of a child process making a reference to a file descriptor that
was inherited from the parent, the Solaris NFSv4 client would not be
able to reliably find the data structure that contains the stateid.
Therefore, the presence of the OPENFH operation does not resolve how
the Solaris NFSv4 client would keep from having dangling references to
an OPEN file at the server.
At the bakeoff, we had some discussions about these issues and
formulated a possible solution that would allow for the model that
most Unix/Posix clients implement while offering a solution that would
satisfy a Windows client as well.
The Ideas/Proposal:
The first major change is to move to a two-level state model in
NFSv4. Yes, this is a major change but builds on the existing
experience in NFSv4 of using stateids and sequence numbers to handle
the various cases of retransmissions, etc. This model is similar to
the Unix/Posix model for open files that are shared between parent and
child and file locking which is not.
With this new model, there is what we will refer to as an OPEN state
stream that is represented by an open_owner/open_stateid. This
open_owner/open_stateid is the "parent" of any locking state that is
instantiated at the client for the open file. The open_owner
generally represents a parent process and its children since they
share file descriptors. The client implementation may choose to
expand that interpretation to include all processes that open() the
file and that share credentials (as an example).
>From this open_owner/open_stateid, the client can then instantiate a
"traditional" lock_owner by referring to the open_stateid. The
lock_owner then can be used for a file locking state stream (which
would include read/write requests). Generally, this lock_owner would
be initiated when a file lock request is made and would represent the
process.
Both open_owner and lock_owner would have their own sequence_ids so
that related requests are ordered at the server. The rules that exist
today for replay would remain in place.
The OPEN operation would look something like this (a lot of existing
detail has been left out to simplify the discussion):
OPEN
(cfh), name, open_owner, open_seqid -> (cfh), open_stateid
LOCK
(cfh), open_stateid, lock_owner, lock_seqid -> (cfh), lock_stateid
There would still be an OPEN_CONFIRM call to be used when the server
first encounters an open_owner/seqid. We would also introduce a
LOCK_CONFIRM to establish the lock_owner/seqid as well
Because we are introducing an open_owner that potentially represents
multiple processes at the client and the OPEN call uses a name for the
OPEN, it is difficult or burdensome for the client to serialize OPEN
operations to the server. This introduces the problem that the client
may generate two OPEN requests to the server that use the same
open_owner. This would be the case where hardlinks are present or the
client chooses not to serialize OPENs.
If this occurs, the server will return two open_stateid values to the
client but the client will not know which one to use. To address this
problem and the outstanding request that stateid values be enlarged in
the protocol, the stateid will become a little less opaque and look
something like this:
stateid4 {
uint32_t seqid;
opaque serverstuff<12>;
};
The server will use the seqid to indicate the order in which the
stateids for the related *_owner value are created.
In the case of simultaneous OPENs, the client will inspect
open_stateid.seqid to determine which stateid is the most recent. The
client will then use that stateid for subsequent operations.
For the Windows client that does not require the ability to have
multiple lock_owners associated with an open_owner, there will be a
one lock_owner per open_owner.
As an optimization, the OPEN operation can also be augmented to handle
the general case of one open_owner to one lock_owner with something
like:
OPEN
(cfh), name, open_owner, open_seqid, lock_owner, lock_seqid ->
(cfh), open_stateid, lock_stateid
From nfs4-wg-request@sunroof.eng.sun.com Thu Aug 16 18:01:23 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26149
for ; Thu, 16 Aug 2001 18:01:22 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15051;
Thu, 16 Aug 2001 15:02:07 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24295;
Thu, 16 Aug 2001 15:01:34 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.89.50] (may be forged))
by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GM1MD20811
for ; Thu, 16 Aug 2001 15:01:22 -0700 (PDT)
Received: from eng.sun.com (terra.Eng.Sun.COM [129.146.86.99])
by jurassic.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GM1Pg711414
for ; Thu, 16 Aug 2001 15:01:25 -0700 (PDT)
Sender: Brent.Callaghan@eng.sun.com
Message-ID: <3B7C42AE.69FCEA7B@eng.sun.com>
Date: Thu, 16 Aug 2001 15:01:18 -0700
From: Brent
Organization: NFS Whackers
X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Robert Thurlow wrote:
> > o Transparent client failover
> > o For read-only replicas and migrated writable volumes
>
> This is summarizing the holy grail. For read-only replication,
> this does not seem too hard. For migration, things are harder.
> I like the idea of trying to transfer lock and delegation state
> and forcing some reboot-like recovery effort onto the client.
> But I am willing to punt if need be.
Migration of data/metadata is one thing, but transient state
like locks/delegations seems terribly fragile and complex.
I recommend the punt.
> > o Performance
> > o Bandwidth conservative
> > o Differences propagated
> > o Restartable
> > o Client lockout time minimized
>
> This seems important; if the performance is not good especially
> for incremental updates of replicas, we have a problem. I've
> been thinking about transaction logs and snapshots to get the
> minimum set of changes, and I've also been looking at Andrew
> Tridgell's rsync algorithm, which could help when a log is not
> available. This might be one of the first forks in the road
> for deciding how the protocol operates.
Yes, rsync is good for small, informal replication efforts. But it
won't scale to truly huge filesystems with millions of files.
It may be that there is no single algorithm for determining a
list of deltas.
> > o Security
> > o As good as V4
>
> This is very important; fortunately, we do have NFSv4 potentially
> providing a lot of infrastructure. I say 'potentially' because I
> do not at this point assume that the wire protocol will be an RPC
> based application; we might do better to stuff XDR'd data down a
> TCP socket. This choice is another fork in the road.
Yep. I think Legato's backup protocol works this way: XDR'ed
data on a TCP stream. As far as security goes, I think some
kind of connection-based security might be better than the
transaction-based of RPC protocols, e.g. TLS.
> > o Scalable
> > o Huge file systems
> > o Small file s ystems
>
> This is important, but also seems linked to performance to me.
> I don't know how this requirement guides our design.
This might be where a split between an rsync-like algorithm
(small file systems) and transaction-log algorithm (large
file systems) is appropriate.
> > o Capability negotiation between "peers"(?)
> > o I believe this referred to things like attribute differences
>
> This does have to do with whether your filesystem will look
> the same in all respects after a migration. I think the right
> way to do this is to try to inform the sys admin about potential
> loss of data before the migration or replication begins, to give
> them the choice of how to handle it. If a database relies on
> named attributes to operate, you must not transfer its files to
> a server that does not support named attributes, but if you know
> you don't care, you might proceed.
I'd hope that this compatibility function not be overly
chatty or interactive. It might be implemented as
a separate query command that a sysadmin can use when
setting up a new replica. Then the replica sync can
(perhaps via cron script) can be run with appropriate settings.
> > o Migration/replication only for V4
> > o Not a general (rdist) mechanism
>
> I think this server-to-server protocol should not stand alone
> from NFSv4, but clearly if you have managed to move a filesystem
> coherently and correctly between servers, any other protocol
> can share the data with clients. I do believe people will use
> this to move filesystems to be used by NFSv2, NFSv3 and CIFS
> clients, and I think that's good. I do not want requirements
> of those protocols affecting what we design here, though.
I think we should try to keep this protocol independent of v4
and make it a general protocol that's independent of the
data access protocol. I'd hate to see this protocol get larded
up with requirements unusual to any single file access protocol,
e.g. replication of filehandles or file open state.
Brent
From nfs4-wg-request@sunroof.eng.sun.com Thu Aug 16 19:26:17 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27495
for ; Thu, 16 Aug 2001 19:26:17 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15862;
Thu, 16 Aug 2001 17:26:51 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13334;
Thu, 16 Aug 2001 16:26:22 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7GNQDL21267
for ; Thu, 16 Aug 2001 16:26:13 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09473;
Thu, 16 Aug 2001 16:26:16 -0700 (PDT)
Received: from eagle.professionals.com (eagle.professionals.com [206.127.192.10])
by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23614;
Thu, 16 Aug 2001 16:26:14 -0700 (PDT)
Received: from eisler.com ([206.27.132.50])
(authenticated)
by eagle.professionals.com (8.10.2/8.10.2) with ESMTP id f7GNNme11861;
Thu, 16 Aug 2001 16:23:48 -0700 (PDT)
Sender: mre@eagle.professionals.com
Message-ID: <3B7C56B2.A05405F4@eisler.com>
Date: Thu, 16 Aug 2001 16:26:42 -0700
From: Mike Eisler
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Brent
CC: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References: <3B7C42AE.69FCEA7B@eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
> Migration of data/metadata is one thing, but transient state
> like locks/delegations seems terribly fragile and complex.
> I recommend the punt.
...
> I think we should try to keep this protocol independent of v4
> and make it a general protocol that's independent of the
> data access protocol. I'd hate to see this protocol get larded
> up with requirements unusual to any single file access protocol,
> e.g. replication of filehandles or file open state.
If these end up being requirements, I suspect that
it will means a replication/migration protocol for only
read-only filesets. The client side failover
experiment is 2.6+ is read-only, and yet has been very successful.
This is because we know from half a decade of
operational experience that locking and preservation of metadata like
filehandles, fileids on read-only
filesets is not needed.
It is easy for me to imagine that with writeable filesets, there will
be many problems without migratable locking and metadata.
-mre
From nfs4-wg-request@sunroof.eng.sun.com Thu Aug 16 19:39:13 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27712
for ; Thu, 16 Aug 2001 19:39:12 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22565;
Thu, 16 Aug 2001 17:39:26 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15987;
Thu, 16 Aug 2001 16:39:03 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7GNcrL21375
for ; Thu, 16 Aug 2001 16:38:53 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15955;
Thu, 16 Aug 2001 16:38:56 -0700 (PDT)
Received: from emc.com (emcmail.lss.emc.com [168.159.48.78])
by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06857;
Thu, 16 Aug 2001 16:38:56 -0700 (PDT)
Received: from emc.com ([168.159.45.11])
by emc.com (8.10.1/8.10.1) with ESMTP id f7GNctL20935;
Thu, 16 Aug 2001 19:38:55 -0400 (EDT)
Message-ID: <3B7C5A18.56E6E357@emc.com>
Date: Thu, 16 Aug 2001 19:41:12 -0400
From: Uresh Vahalia
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Thurlow
CC: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
We should define the objectives for protocol support of replication/migration.
Do we want to:
1. Define a standard way for a server to replicate/migrate data to another,
possibly heterogenous, server?
2. Provide useful mechanisms for servers to send/receive file data and
attributes to each other so that server vendors can build effective
replication/migration solutions?
3. Provide ways for clients to control what gets replicated/migrated (whole file
systems, directory trees, individual files), when, and where?
4. Allow clients to recognize the existence of replicas or be informed that some
data has been migrated elsewhere, and to optimize their data access accordingly
(load balance among replicas, for instance)?
5. All of the above.
Since most servers support multiple protocols (at least, multiple versions of
NFS), it seems impractical to tie this stuff too closely to replication.
Uresh
=====================
Robert Thurlow wrote:
> I wrote:
>
> > They're a fairly large set, and I'd like to find out who cares
> > about which parts.
>
> Here are my thoughts on this. Since we did NFS client failover
> in Solaris 2.6, it's been an occasional issue that we didn't
> provide a good tool to create replicas. When we look at the
> geographical diversity of our customers, a good way to create
> replicas is important, so we have a block-based replication
> tool as other vendors do. With NFSv4, I think our customers
> will want something more standard between different types of
> servers, and something more useful than 'cp -r' or 'rdist'.
>
> > o Transparent client failover
> > o For read-only replicas and migrated writable volumes
>
> This is summarizing the holy grail. For read-only replication,
> this does not seem too hard. For migration, things are harder.
> I like the idea of trying to transfer lock and delegation state
> and forcing some reboot-like recovery effort onto the client.
> But I am willing to punt if need be.
>
> > o Performance
> > o Bandwidth conservative
> > o Differences propagated
> > o Restartable
> > o Client lockout time minimized
>
> This seems important; if the performance is not good especially
> for incremental updates of replicas, we have a problem. I've
> been thinking about transaction logs and snapshots to get the
> minimum set of changes, and I've also been looking at Andrew
> Tridgell's rsync algorithm, which could help when a log is not
> available. This might be one of the first forks in the road
> for deciding how the protocol operates.
>
> > o Security
> > o As good as V4
>
> This is very important; fortunately, we do have NFSv4 potentially
> providing a lot of infrastructure. I say 'potentially' because I
> do not at this point assume that the wire protocol will be an RPC
> based application; we might do better to stuff XDR'd data down a
> TCP socket. This choice is another fork in the road.
>
> > o Scalable
> > o Huge file systems
> > o Small file s ystems
>
> This is important, but also seems linked to performance to me.
> I don't know how this requirement guides our design.
>
> > o Capability negotiation between "peers"(?)
> > o I believe this referred to things like attribute differences
>
> This does have to do with whether your filesystem will look
> the same in all respects after a migration. I think the right
> way to do this is to try to inform the sys admin about potential
> loss of data before the migration or replication begins, to give
> them the choice of how to handle it. If a database relies on
> named attributes to operate, you must not transfer its files to
> a server that does not support named attributes, but if you know
> you don't care, you might proceed.
>
> > o Efficient multi-way replication (propagation)
>
> This is good, but if multiple connections are used for propagation
> it's not obvious how this would affect the server-to-server protocol.
> If we were to choose a multicast protocol instead, this would be
> relevant.
>
> > o Correctness
> > o "Atomic" propagation of file system from client view
> > o Failover to a correct replica version
>
> As Brian's issues pointed out, we have no basis for tracking a
> replica version in NFSv4. In practice, I don't think this is
> necessary. Here at Sun, our internal network has a large-scale
> replica set of binaries and support files, and uses no version
> number. If an application needs a version of a data set, the
> application should create one.
>
> > o TCP/ IP based
> > o No legacy UDP requirement
>
> This seems obviously correct (and implies not using multicast).
>
> > Issues
> >
> > o Single vs. multi-master
> > o Multi-master entails conflict resolution
> > o Proposal: Single master copy sufficient - objections?
> > o Disconnected operation irrelevant
> > o Corollary to above
> > o Proposal: Disconnected operation for clients not required - objections?
>
> I agree that multi-master and disconnected use are out of scope.
> One thing this leaves open is the possibility of having both a
> read-write master and a number of read-only replicas. AFS did
> this by just having separate mount points; DCS/DFS did a better
> job via the token manager. If the namespace can inform clients
> where the read-write master is, it should be possible to have
> clients forget about alternate replicas while a process on the
> client is modifying to a file. This is mostly work done by the
> client, and likely has no bearing on the server-to-server protocol.
>
> > o Migration/replication only for V4
> > o Not a general (rdist) mechanism
>
> I think this server-to-server protocol should not stand alone
> from NFSv4, but clearly if you have managed to move a filesystem
> coherently and correctly between servers, any other protocol
> can share the data with clients. I do believe people will use
> this to move filesystems to be used by NFSv2, NFSv3 and CIFS
> clients, and I think that's good. I do not want requirements
> of those protocols affecting what we design here, though.
>
> Comments?
>
> Rob T
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 11:32:04 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05348
for ; Fri, 17 Aug 2001 11:32:04 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02135;
Fri, 17 Aug 2001 09:32:46 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09872;
Fri, 17 Aug 2001 08:30:37 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HFUUL24130
for ; Fri, 17 Aug 2001 08:30:30 -0700 (PDT)
Received: from peyto (vpn-129-147-152-135.Central.Sun.COM [129.147.152.135])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with SMTP id f7HFUOe932848;
Fri, 17 Aug 2001 08:30:24 -0700 (PDT)
Date: Fri, 17 Aug 2001 09:30:53 -0600 (MDT)
From: Robert Thurlow
Reply-To: Robert Thurlow
Subject: Re: Replication and migration requirements
To: Mike Eisler
Cc: nfsv4-wg@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3B7C56B2.A05405F4@eisler.com>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> If these end up being requirements, I suspect that it will means a
> replication/migration protocol for only read-only filesets.
...
> It is easy for me to imagine that with writeable filesets, there will
> be many problems without migratable locking and metadata.
I hear you; if we talk about NFSv4's improved stateful model
and migration support, but have to add the footnote that the
customer has to choose between these features, will migration
be considered useful, or just a source of bugs we can't fix
because of the protocol definitions? It does seem to me that
with proper handling, migrating state should be possible.
Practical? I don't yet know.
Rob T
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 12:04:21 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06560
for ; Fri, 17 Aug 2001 12:04:21 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29396;
Fri, 17 Aug 2001 10:05:01 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09883;
Fri, 17 Aug 2001 08:30:50 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.86.38] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HFUNL24127
for ; Fri, 17 Aug 2001 08:30:23 -0700 (PDT)
Received: from peyto (vpn-129-147-152-135.Central.Sun.COM [129.147.152.135])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with SMTP id f7HFULe932839;
Fri, 17 Aug 2001 08:30:21 -0700 (PDT)
Date: Fri, 17 Aug 2001 09:30:50 -0600 (MDT)
From: Robert Thurlow
Reply-To: Robert Thurlow
Subject: Re: Replication and migration requirements
To: Brent
Cc: nfsv4-wg@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3B7C42AE.69FCEA7B@eng.sun.com>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> I'd hope that this compatibility function not be overly
> chatty or interactive. It might be implemented as
> a separate query command that a sysadmin can use when
> setting up a new replica. Then the replica sync can
> (perhaps via cron script) can be run with appropriate settings.
Clearly, you only want to know this kind of information when
you initially set up the replica, not when you're propagating
changes to the same set of servers.
> I think we should try to keep this protocol independent of v4
> and make it a general protocol that's independent of the
> data access protocol. I'd hate to see this protocol get larded
> up with requirements unusual to any single file access protocol,
> e.g. replication of filehandles or file open state.
The problem with making it independant of NFSv4 is that I think
we want correct replication of ALL of the NFSv4 attributes when
possible; I expected to re-use the nfsv4.x file to be able to
express these attributes in the server-to-server protocol. If
this is the generic effort of an separate WG, can we do this?
And if we can't do this, can we achieve correct replication and
migration?
Rob T
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 12:06:19 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06634
for ; Fri, 17 Aug 2001 12:06:18 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01414;
Fri, 17 Aug 2001 10:06:53 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26131;
Fri, 17 Aug 2001 08:55:51 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HFtiL24307
for ; Fri, 17 Aug 2001 08:55:44 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22568
for ; Fri, 17 Aug 2001 08:55:44 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12988
for ; Fri, 17 Aug 2001 08:55:43 -0700 (PDT)
Received: from mosquito.inet.org (mosquito [10.30.20.240])
by gnat.inet.org (Postfix) with ESMTP
id 831628266E; Fri, 17 Aug 2001 11:52:45 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010817114615.00a03ec0@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 17 Aug 2001 11:47:29 -0400
To: Robert Thurlow
From: RJ Atkinson
Subject: Re: Replication and migration requirements
Cc: nfsv4-wg@sunroof.eng.sun.com
In-Reply-To:
References: <"Your message with ID" <3B7C56B2.A05405F4@eisler.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 11:30 17/08/01, Robert Thurlow wrote:
>will migration be considered useful, or just a source of bugs
>we can't fix because of the protocol definitions?
As I've noted before, I think it is needless complexity
that's just going to cause me operational problems.
However, user input doesn't seem to carry very much weight
in this WG...
Ran
rja@inet.org
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 12:07:58 2001
Received: from saturn.sun.com (saturn.Sun.COM [192.9.25.2])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06691
for ; Fri, 17 Aug 2001 12:07:57 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19312;
Fri, 17 Aug 2001 09:08:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27045;
Fri, 17 Aug 2001 09:00:09 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.85.105] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HG01L24343
for ; Fri, 17 Aug 2001 09:00:01 -0700 (PDT)
Received: from peyto (vpn-129-147-152-135.Central.Sun.COM [129.147.152.135])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with SMTP id f7HFxxe940788;
Fri, 17 Aug 2001 08:59:59 -0700 (PDT)
Date: Fri, 17 Aug 2001 10:00:21 -0600 (MDT)
From: Robert Thurlow
Reply-To: Robert Thurlow
Subject: Re: Replication and migration requirements
To: Uresh Vahalia
Cc: nfsv4-wg@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3B7C5A18.56E6E357@emc.com>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> We should define the objectives for protocol support of
> replication/migration.
I think we should mainly be focused on defining a protocol
which permits a server to contact another server to initiate
and complete a data transfer to create or maintain filesystem
replicas, or to move a filesystem.
> Do we want to:
>
> 1. Define a standard way for a server to replicate/migrate data to another,
> possibly heterogenous, server?
I believe this should be our priority here, with "heterogeneous"
being the key word. Sun has a block-level replication product
which is good, so does NetApp - but they're only capable of doing
that with the same brand of machines. Islands of functionality
like this do not meet customer needs.
> 2. Provide useful mechanisms for servers to send/receive file data and
> attributes to each other so that server vendors can build effective
> replication/migration solutions?
I may be misunderstanding this, but I don't think we're interested
in building a "toolkit" - we want a protocol servers can speak to
transfer entire filesystems and then propagate updates to replicas.
The IETF does protocols and not APIs, so this seems necessary.
> 3. Provide ways for clients to control what gets replicated/migrated (whole
> file systems, directory trees, individual files), when, and where?
I don't think we are standardizing how an administrator at her
desk communicates her desire to have servers achieve a migration
or replication activity, but perhaps we should be doing that.
> 4. Allow clients to recognize the existence of replicas or be informed that
> some data has been migrated elsewhere, and to optimize their data access
> accordingly (load balance among replicas, for instance)?
Right now, we haven't been talking much about how resource info
is "published" so that clients can know about it. It is clearly
important, and customers have BIG complaints that this is not
standardized, leaving them to manage more islands of functionality.
But replication only adds a couple of requirements to this issue
("give me multiple names" and "permit this info to be mutable"),
so I would think this is not a goal for this work. If we wanted
to discuss doing NFS resource discovery in a standard way, I'd
think that would be a useful effort, but not tied to replication
and migration.
Rob T
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 12:14:54 2001
Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06975
for ; Fri, 17 Aug 2001 12:14:53 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11402;
Fri, 17 Aug 2001 10:10:17 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28247;
Fri, 17 Aug 2001 09:05:57 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.85.105] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HG5oL24386
for ; Fri, 17 Aug 2001 09:05:50 -0700 (PDT)
Received: from peyto (vpn-129-147-152-135.Central.Sun.COM [129.147.152.135])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with SMTP id f7HG5ie944066;
Fri, 17 Aug 2001 09:05:44 -0700 (PDT)
Date: Fri, 17 Aug 2001 10:06:13 -0600 (MDT)
From: Robert Thurlow
Reply-To: Robert Thurlow
Subject: Re: Replication and migration requirements
To: RJ Atkinson
Cc: nfsv4-wg@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <5.1.0.14.2.20010817114615.00a03ec0@10.30.15.2>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> At 11:30 17/08/01, Robert Thurlow wrote:
> >will migration be considered useful, or just a source of bugs
> >we can't fix because of the protocol definitions?
>
> As I've noted before, I think it is needless complexity
> that's just going to cause me operational problems.
So Ran, as a user, do you want to use replication? Migration?
Do you favor tough restrictions (e.g. quiescence) on what can be
migrated so that that can be done safely? Also, since we're so
far talking about a separate protocol, it's hard to see what
you're reacting to.
> However, user input doesn't seem to carry very much weight
> in this WG...
IMO, clear and constructive commentary always carries weight.
Rob T
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 12:15:08 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06989
for ; Fri, 17 Aug 2001 12:15:07 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13247;
Fri, 17 Aug 2001 10:15:39 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29957;
Fri, 17 Aug 2001 09:15:20 -0700 (PDT)
Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HGFFL24524
for ; Fri, 17 Aug 2001 09:15:15 -0700 (PDT)
Received: from dhcp-aus08-183.central.sun.com (dhcp-aus08-183.Central.Sun.COM [129.153.128.183])
by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09832
for ; Fri, 17 Aug 2001 10:15:16 -0600 (MDT)
Received: (from shepler@localhost)
by dhcp-aus08-183.central.sun.com (8.11.3+Sun/8.11.3) id f7HGF5G00556
for nfsv4-wg@sunroof.eng.sun.com; Fri, 17 Aug 2001 11:15:05 -0500 (CDT)
Date: Fri, 17 Aug 2001 11:15:05 -0500
From: Spencer Shepler
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
Message-ID: <20010817111505.B519@dhcp-aus08-183.central.sun.com>
Reply-To: shepler@eng.sun.com
Mail-Followup-To: Spencer Shepler ,
nfsv4-wg@sunroof.eng.sun.com
References: <"Your <3B7C56B2.A05405F4@eisler.com> <5.1.0.14.2.20010817114615.00a03ec0@10.30.15.2>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5.1.0.14.2.20010817114615.00a03ec0@10.30.15.2>
User-Agent: Mutt/1.3.19i
On Fri, RJ Atkinson wrote:
> At 11:30 17/08/01, Robert Thurlow wrote:
> >will migration be considered useful, or just a source of bugs
> >we can't fix because of the protocol definitions?
>
> As I've noted before, I think it is needless complexity
> that's just going to cause me operational problems.
> However, user input doesn't seem to carry very much weight
> in this WG...
Ran,
Are you saying that you don't need any replication or migration
backend protocol to support data management or that you don't want
those types of hooks/features in the NFSv4 protocol itself.
--
- Spencer -
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 12:53:14 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08247
for ; Fri, 17 Aug 2001 12:53:14 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19917;
Fri, 17 Aug 2001 10:53:52 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25942;
Fri, 17 Aug 2001 09:52:47 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HGqeL24804
for ; Fri, 17 Aug 2001 09:52:40 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25919;
Fri, 17 Aug 2001 09:52:40 -0700 (PDT)
Received: from medlicott.panasas.com ([65.194.57.194])
by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11801;
Fri, 17 Aug 2001 09:52:39 -0700 (PDT)
Received: from medlicott.panasas.com (IDENT:welch@localhost.localdomain [127.0.0.1])
by medlicott.panasas.com (8.9.3/8.9.3) with ESMTP id JAA16252;
Fri, 17 Aug 2001 09:52:37 -0700
Message-Id: <200108171652.JAA16252@medlicott.panasas.com>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0
To: Robert Thurlow
cc: Uresh Vahalia , nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
In-reply-to:
References:
Comments: In-reply-to Robert Thurlow
message dated "Fri, 17 Aug 2001 10:00:21 -0600."
From: Brent Welch
X-URL: http://www.panasas.com/
X-Face: "HxE|?EnC9fVMV8f70H83&{fgLE.|FZ^$>@Q(yb#N,Eh~N]e&]=>r5~UnRml1:4EglY{9B+
:'wJq$@c_C!l8@<$t,{YUr4K,QJGHSvS~U]H`<+L*x?eGzSk>XH\W:AK\j?@?c1o>>Robert Thurlow said:
> > We should define the objectives for protocol support of
> > replication/migration.
>
> I think we should mainly be focused on defining a protocol
> which permits a server to contact another server to initiate
> and complete a data transfer to create or maintain filesystem
> replicas, or to move a filesystem.
>
> > Do we want to:
> >
> > 1. Define a standard way for a server to replicate/migrate data to anothe
r,
> > possibly heterogenous, server?
>
> I believe this should be our priority here, with "heterogeneous"
> being the key word. Sun has a block-level replication product
> which is good, so does NetApp - but they're only capable of doing
> that with the same brand of machines. Islands of functionality
> like this do not meet customer needs.
>
> > 2. Provide useful mechanisms for servers to send/receive file data and
> > attributes to each other so that server vendors can build effective
> > replication/migration solutions?
>
> I may be misunderstanding this, but I don't think we're interested
> in building a "toolkit" - we want a protocol servers can speak to
> transfer entire filesystems and then propagate updates to replicas.
> The IETF does protocols and not APIs, so this seems necessary.
>
> > 3. Provide ways for clients to control what gets replicated/migrated (who
le
> > file systems, directory trees, individual files), when, and where?
>
> I don't think we are standardizing how an administrator at her
> desk communicates her desire to have servers achieve a migration
> or replication activity, but perhaps we should be doing that.
>
> > 4. Allow clients to recognize the existence of replicas or be informed th
at
> > some data has been migrated elsewhere, and to optimize their data access
> > accordingly (load balance among replicas, for instance)?
>
> Right now, we haven't been talking much about how resource info
> is "published" so that clients can know about it. It is clearly
> important, and customers have BIG complaints that this is not
> standardized, leaving them to manage more islands of functionality.
>
> But replication only adds a couple of requirements to this issue
> ("give me multiple names" and "permit this info to be mutable"),
> so I would think this is not a goal for this work. If we wanted
> to discuss doing NFS resource discovery in a standard way, I'd
> think that would be a useful effort, but not tied to replication
> and migration.
>
> Rob T
>
--
Brent Welch
Software Architect, Panasas Inc
Pioneering Smart and Infinitely Scalable Storage Networks
www.panasas.com
welch@panasas.com
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 13:12:38 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08744
for ; Fri, 17 Aug 2001 13:12:36 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01111;
Fri, 17 Aug 2001 11:08:12 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28945;
Fri, 17 Aug 2001 10:07:31 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HH7OL24830
for ; Fri, 17 Aug 2001 10:07:24 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14278
for ; Fri, 17 Aug 2001 10:07:25 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09307
for ; Fri, 17 Aug 2001 10:07:24 -0700 (PDT)
Received: from mosquito.inet.org (mosquito [10.30.20.240])
by gnat.inet.org (Postfix) with ESMTP
id 215068266E; Fri, 17 Aug 2001 13:02:40 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010817125240.01d8dec0@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 17 Aug 2001 12:57:23 -0400
To: shepler@eng.sun.com
From: RJ Atkinson
Subject: Re: Replication and migration requirements
Cc: nfsv4-wg@sunroof.eng.sun.com
In-Reply-To: <20010817111505.B519@dhcp-aus08-183.central.sun.com>
References: <5.1.0.14.2.20010817114615.00a03ec0@10.30.15.2>
<"Your <3B7C56B2.A05405F4@eisler.com>
<5.1.0.14.2.20010817114615.00a03ec0@10.30.15.2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 12:15 17/08/01, Spencer Shepler wrote:
> Are you saying that you don't need any replication or migration
>backend protocol to support data management or that you don't want
>those types of hooks/features in the NFSv4 protocol itself ?
Good question. Myself, I don't need a replication or
migration backend protocol. I accept that some other users
probably do want the ability to replicate/migrate stuff
between/among servers.
So my main concern is that we don't do this inside NFSv4,
which already appears to be more complex than necessary and
already is an operational concern. If replication (etc) were
done in a totally decoupled way so that no additional gorp
gets added to NFSv4, that would be OK with me.
It has not been clear to me (I couldn't be in London due
to serious illness so am a bit out of sync) that this work was
being undertaken in such a totally decoupled manner. Are folks
intending to undertake this as a separate protocol, decoupled
from NFSv4 ? If yes, kindly pardon my confusion.
Regards,
Ran
rja@inet.org
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 13:14:42 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08790
for ; Fri, 17 Aug 2001 13:14:41 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08401;
Fri, 17 Aug 2001 10:15:08 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00309;
Fri, 17 Aug 2001 10:13:42 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HHDaL24841
for ; Fri, 17 Aug 2001 10:13:36 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12401
for ; Fri, 17 Aug 2001 10:13:38 -0700 (PDT)
Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53])
by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21094
for ; Fri, 17 Aug 2001 10:13:37 -0700 (PDT)
Received: from frejya.corp.netapp.com (frejya.corp.netapp.com [10.10.20.91])
by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f7HHCxX26979;
Fri, 17 Aug 2001 10:12:59 -0700 (PDT)
Received: from tooting-fe.eng.netapp.com (localhost [127.0.0.1])
by frejya.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f7HHCwj27112;
Fri, 17 Aug 2001 10:12:59 -0700 (PDT)
Received: (from beepy@localhost)
by tooting-fe.eng.netapp.com (8.8.8+Sun/8.8.8) id KAA18585;
Fri, 17 Aug 2001 10:12:58 -0700 (PDT)
From: Brian Pawlowski
Message-Id: <200108171712.KAA18585@tooting-fe.eng.netapp.com>
Subject: Re: Replication and migration requirements
In-Reply-To: <5.1.0.14.2.20010817125240.01d8dec0@10.30.15.2> from RJ Atkinson at "Aug 17, 1 12:57:23 pm"
To: rja@inet.org (RJ Atkinson)
Date: Fri, 17 Aug 2001 10:12:57 -0700 (PDT)
Cc: shepler@eng.sun.com, nfsv4-wg@sunroof.eng.sun.com
X-Mailer: ELM [version 2.4ME++ PL40 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
NFS V4 as it stands includes some info to support client to server
interactions for client failover in a migration or replication
situation.
The work being proposed is a separate protocol to support
the feature defined for NFS V4.
Not adding anything new - only a server-to-server protocol to support
what is there.
> At 12:15 17/08/01, Spencer Shepler wrote:
> > Are you saying that you don't need any replication or migration
> >backend protocol to support data management or that you don't want
> >those types of hooks/features in the NFSv4 protocol itself ?
>
> Good question. Myself, I don't need a replication or
> migration backend protocol. I accept that some other users
> probably do want the ability to replicate/migrate stuff
> between/among servers.
>
> So my main concern is that we don't do this inside NFSv4,
> which already appears to be more complex than necessary and
> already is an operational concern. If replication (etc) were
> done in a totally decoupled way so that no additional gorp
> gets added to NFSv4, that would be OK with me.
>
> It has not been clear to me (I couldn't be in London due
> to serious illness so am a bit out of sync) that this work was
> being undertaken in such a totally decoupled manner. Are folks
> intending to undertake this as a separate protocol, decoupled
> from NFSv4 ? If yes, kindly pardon my confusion.
>
> Regards,
>
> Ran
> rja@inet.org
>
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 13:26:29 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09110
for ; Fri, 17 Aug 2001 13:26:28 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15614;
Fri, 17 Aug 2001 11:27:08 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03129;
Fri, 17 Aug 2001 10:26:16 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HHQ7L24872
for ; Fri, 17 Aug 2001 10:26:07 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03093
for ; Fri, 17 Aug 2001 10:26:08 -0700 (PDT)
Received: from eagle.professionals.com (eagle.professionals.com [206.127.192.10])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14625
for ; Fri, 17 Aug 2001 11:26:03 -0600 (MDT)
Received: from eisler.com ([206.27.132.50])
(authenticated)
by eagle.professionals.com (8.10.2/8.10.2) with ESMTP id f7HHNde06388
for ; Fri, 17 Aug 2001 10:23:40 -0700 (PDT)
Sender: mre@eagle.professionals.com
Message-ID: <3B7D53CB.165FAEC2@eisler.com>
Date: Fri, 17 Aug 2001 10:26:35 -0700
From: Mike Eisler
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References: <"Your message with ID" <3B7C56B2.A05405F4@eisler.com> <5.1.0.14.2.20010817114615.00a03ec0@10.30.15.2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
RJ Atkinson wrote:
>
> At 11:30 17/08/01, Robert Thurlow wrote:
> >will migration be considered useful, or just a source of bugs
> >we can't fix because of the protocol definitions?
>
> As I've noted before, I think it is needless complexity
> that's just going to cause me operational problems.
> However, user input doesn't seem to carry very much weight
> in this WG...
That AFS persists, and the users who persist it list
fileset migration as a major reason suggests to me that user
input is carrying weight.
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 13:50:19 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09900
for ; Fri, 17 Aug 2001 13:50:18 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04361;
Fri, 17 Aug 2001 11:51:09 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21325;
Fri, 17 Aug 2001 10:50:43 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HHoZL25096
for ; Fri, 17 Aug 2001 10:50:35 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09035
for ; Fri, 17 Aug 2001 10:50:36 -0700 (PDT)
Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged))
by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02414
for ; Fri, 17 Aug 2001 10:50:35 -0700 (PDT)
Received: from mosquito.inet.org (mosquito [10.30.20.240])
by gnat.inet.org (Postfix) with ESMTP
id 58C688266E; Fri, 17 Aug 2001 13:48:22 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010817133717.00a130b0@10.30.15.2>
X-Sender: rja@10.30.15.2
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 17 Aug 2001 13:43:04 -0400
To: Mike Eisler
From: RJ Atkinson
Subject: Re: Replication and migration requirements
Cc: nfsv4-wg@sunroof.eng.sun.com
In-Reply-To: <3B7D53CB.165FAEC2@eisler.com>
References: <"Your message with ID" <3B7C56B2.A05405F4@eisler.com>
<5.1.0.14.2.20010817114615.00a03ec0@10.30.15.2>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
At 13:26 17/08/01, Mike Eisler wrote:
>That AFS persists, and the users who persist it list
>fileset migration as a major reason suggests to me that user
>input is carrying weight.
Mike,
I haven't seen that input on this mailing list or at any
meetings I've been at. I must have been asleep that week.
I know I'm not the only user on this list, though I do seem to
be the main user who comments on stuff (sigh; I wish other users
on the list would comment more on the list).
I have worked at sites that used AFS. At the sites I am
familiar with, the primary reasons for AFS were (in priority order):
1) Perceived better security through Kerberos integration
2) Global filesystem namespace so that files have the
same absolute path no matter where one accesses
them from (e.g. same path from one's work desktop
or from one's university account)
3) Enhanced central administrative control of things
because of the "AFS cell controller" design choice
Note well that those aren't my own views on AFS, just the views
of folks at the sites I've worked at that happened to use AFS
(in addition to NFS).
Cheers,
Ran
rja@inet.org
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 14:53:18 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12644
for ; Fri, 17 Aug 2001 14:53:18 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19194;
Fri, 17 Aug 2001 11:53:39 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04377;
Fri, 17 Aug 2001 11:50:18 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HIoBL25342
for ; Fri, 17 Aug 2001 11:50:12 -0700 (PDT)
Received: from peyto (vpn-129-147-152-135.Central.Sun.COM [129.147.152.135])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with SMTP id f7HIo9e121657;
Fri, 17 Aug 2001 11:50:09 -0700 (PDT)
Date: Fri, 17 Aug 2001 12:50:33 -0600 (MDT)
From: Robert Thurlow
Reply-To: Robert Thurlow
Subject: Re: Replication and migration requirements
To: RJ Atkinson
Cc: nfsv4-wg@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <5.1.0.14.2.20010817133717.00a130b0@10.30.15.2>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> At 13:26 17/08/01, Mike Eisler wrote:
> >That AFS persists, and the users who persist it list
> >fileset migration as a major reason suggests to me that user
> >input is carrying weight.
>
> Mike,
>
> I haven't seen that input on this mailing list or at any
> meetings I've been at. I must have been asleep that week.
I tend to think that this is not a forum where many AFS users
would coalesce, which is too bad - I think we'd benefit from
more familiarity with it.
> I have worked at sites that used AFS. At the sites I am
> familiar with, the primary reasons for AFS were (in priority order):
> 1) Perceived better security through Kerberos integration
> 2) Global filesystem namespace so that files have the
> same absolute path no matter where one accesses
> them from (e.g. same path from one's work desktop
> or from one's university account)
> 3) Enhanced central administrative control of things
> because of the "AFS cell controller" design choice
I like AFS; I worked on a port to a new platform in a previous
position. The security model is good, and it does things like
replication, migration and backup (at least architecturally!) very
well. I find my thoughts very much guided by some of what AFS
does well. I always shook my head at what they left out, though -
byte-range locking and ability to support HSM, for example.
Rob T
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 15:55:41 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14170
for ; Fri, 17 Aug 2001 15:55:41 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04013;
Fri, 17 Aug 2001 13:55:41 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05134;
Fri, 17 Aug 2001 12:54:27 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HJrpL25768
for ; Fri, 17 Aug 2001 12:53:51 -0700 (PDT)
Received: from eng.sun.com (terra.Eng.Sun.COM [129.146.86.99])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HJroe143833
for ; Fri, 17 Aug 2001 12:53:50 -0700 (PDT)
Sender: Brent.Callaghan@eng.sun.com
Message-ID: <3B7D7649.FD8ADB58@eng.sun.com>
Date: Fri, 17 Aug 2001 12:53:45 -0700
From: Brent
Organization: NFS Whackers
X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References: <200108171652.JAA16252@medlicott.panasas.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Brent Welch wrote:
>
> Regarding points 1 and 2 below, one candidate for a server-to-server
> protocol is NDMP, which is used to copy file systems from filers to
> tape servers, or from filers to filers.
Isn't NDMP used just to coordinate an over-the-wire dump/restore
as in NDMPcopy ?
I don't see anything in the protocol that makes it a good basis
for a more general or efficient replica sync protocol.
Brent
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 16:22:30 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14608
for ; Fri, 17 Aug 2001 16:22:30 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA24901;
Fri, 17 Aug 2001 13:22:24 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17652;
Fri, 17 Aug 2001 13:18:57 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.89.50] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HKImL25851
for ; Fri, 17 Aug 2001 13:18:48 -0700 (PDT)
Received: from eng.sun.com (terra.Eng.Sun.COM [129.146.86.99])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HKIle151432
for ; Fri, 17 Aug 2001 13:18:47 -0700 (PDT)
Sender: Brent.Callaghan@eng.sun.com
Message-ID: <3B7D7C22.7A393AB@eng.sun.com>
Date: Fri, 17 Aug 2001 13:18:42 -0700
From: Brent
Organization: NFS Whackers
X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References: <3B7C42AE.69FCEA7B@eng.sun.com> <3B7C56B2.A05405F4@eisler.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Mike Eisler wrote:
>
> > Migration of data/metadata is one thing, but transient state
> > like locks/delegations seems terribly fragile and complex.
> > I recommend the punt.
> :
> :
> It is easy for me to imagine that with writeable filesets, there will
> be many problems without migratable locking and metadata.
I thought NFSv4 was designed so that clients wouldn't be noticeably
affected if the server crashed, lost their state, and recovered.
The clients are ultimately responsible for re-establishing state.
So, switching to another writable copy shouldn't be any worse
than a server reboot should it ?
Brent
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 16:39:09 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14875
for ; Fri, 17 Aug 2001 16:39:08 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03306;
Fri, 17 Aug 2001 14:39:43 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21267;
Fri, 17 Aug 2001 13:39:08 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HKd1L25953
for ; Fri, 17 Aug 2001 13:39:01 -0700 (PDT)
Received: from eng.sun.com (terra.Eng.Sun.COM [129.146.86.99])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HKd0e157432
for ; Fri, 17 Aug 2001 13:39:00 -0700 (PDT)
Sender: Brent.Callaghan@eng.sun.com
Message-ID: <3B7D80DF.2C6D2638@eng.sun.com>
Date: Fri, 17 Aug 2001 13:38:55 -0700
From: Brent
Organization: NFS Whackers
X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Robert Thurlow wrote:
>> I think we should try to keep this protocol independent of v4
>> and make it a general protocol that's independent of the
>> up with requirements unusual to any single file access protocol,
>> e.g. replication of filehandles or file open state.
>
> The problem with making it independant of NFSv4 is that I think
> we want correct replication of ALL of the NFSv4 attributes when
> possible; I expected to re-use the nfsv4.x file to be able to
> express these attributes in the server-to-server protocol. If
> this is the generic effort of an separate WG, can we do this?
> And if we can't do this, can we achieve correct replication and
> migration?
Realistically, we won't ever have correct replication/migration
unless it's across homogeneous filesystems. I think we'll be
happy with something that mostly works, even if it's not 100%
perfect.
As for the NFSv4 attributes. Yes, the NFSv4 attribute set is
a good guide to the kind of attributes that a replication
protocol might support, though there are a few virtual attributes
in there that may not be appropriate, e.g. the "changed" attribute
is an opaque thingy that cannot easily be represented physically
in any filesystem.
Brent
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 17:53:31 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15771
for ; Fri, 17 Aug 2001 17:53:30 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA27162;
Fri, 17 Aug 2001 14:52:02 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08753;
Fri, 17 Aug 2001 14:49:27 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HLnIL26089
for ; Fri, 17 Aug 2001 14:49:18 -0700 (PDT)
Received: from peyto (vpn-129-147-152-74.Central.Sun.COM [129.147.152.74])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with SMTP id f7HLnIe180996;
Fri, 17 Aug 2001 14:49:18 -0700 (PDT)
Date: Fri, 17 Aug 2001 15:49:46 -0600 (MDT)
From: Robert Thurlow
Reply-To: Robert Thurlow
Subject: Re: Replication and migration requirements
To: Brent
Cc: nfsv4-wg@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3B7D80DF.2C6D2638@eng.sun.com>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> As for the NFSv4 attributes. Yes, the NFSv4 attribute set is
> a good guide to the kind of attributes that a replication
> protocol might support, though there are a few virtual attributes
> in there that may not be appropriate, e.g. the "changed" attribute
> is an opaque thingy that cannot easily be represented physically
> in any filesystem.
I think you missed my point - if the IETF work is done in a separate
working group, will that working group be permitted to use or refer
to parts of the nfsv4.x protocol definition to specify the server-
to-server protocol? If not, don't we have an issue?
Rob T
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 18:04:16 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15926
for ; Fri, 17 Aug 2001 18:04:16 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00519;
Fri, 17 Aug 2001 15:00:04 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16010;
Fri, 17 Aug 2001 14:58:02 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HLvtL26108
for ; Fri, 17 Aug 2001 14:57:55 -0700 (PDT)
Received: from eng.sun.com (terra.Eng.Sun.COM [129.146.86.99])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HLvte183319
for ; Fri, 17 Aug 2001 14:57:55 -0700 (PDT)
Sender: Brent.Callaghan@eng.sun.com
Message-ID: <3B7D935E.7BBC6B58@eng.sun.com>
Date: Fri, 17 Aug 2001 14:57:50 -0700
From: Brent
Organization: NFS Whackers
X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Robert Thurlow wrote:
>
> > As for the NFSv4 attributes. Yes, the NFSv4 attribute set is
> > a good guide to the kind of attributes that a replication
> > protocol might support, though there are a few virtual attributes
> > in there that may not be appropriate, e.g. the "changed" attribute
> > is an opaque thingy that cannot easily be represented physically
> > in any filesystem.
>
> I think you missed my point - if the IETF work is done in a separate
> working group, will that working group be permitted to use or refer
> to parts of the nfsv4.x protocol definition to specify the server-
> to-server protocol? If not, don't we have an issue?
Depends whether a repl/mig protocol is inspired by some feature
of v4, or whether it uses some piece of the protocol verbatim
and becomes dependent on NFSv4 RFC's.
I prefer inspiration.
Brent
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 18:48:10 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16618
for ; Fri, 17 Aug 2001 18:48:09 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26067;
Fri, 17 Aug 2001 16:48:38 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10447;
Fri, 17 Aug 2001 15:47:56 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HMlmL26169
for ; Fri, 17 Aug 2001 15:47:48 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10431;
Fri, 17 Aug 2001 15:47:47 -0700 (PDT)
Received: from eagle.professionals.com (eagle.professionals.com [206.127.192.10])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25670;
Fri, 17 Aug 2001 16:47:42 -0600 (MDT)
Received: from eisler.com ([206.27.132.50])
(authenticated)
by eagle.professionals.com (8.10.2/8.10.2) with ESMTP id f7HMjJe14897;
Fri, 17 Aug 2001 15:45:19 -0700 (PDT)
Sender: mre@eagle.professionals.com
Message-ID: <3B7D9F2C.5FCB1BB7@eisler.com>
Date: Fri, 17 Aug 2001 15:48:12 -0700
From: Mike Eisler
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Brent
CC: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References: <3B7C42AE.69FCEA7B@eng.sun.com> <3B7C56B2.A05405F4@eisler.com> <3B7D7C22.7A393AB@eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Brent wrote:
>
> Mike Eisler wrote:
> >
> > > Migration of data/metadata is one thing, but transient state
> > > like locks/delegations seems terribly fragile and complex.
> > > I recommend the punt.
> > :
> > :
> > It is easy for me to imagine that with writeable filesets, there will
> > be many problems without migratable locking and metadata.
>
> I thought NFSv4 was designed so that clients wouldn't be noticeably
> affected if the server crashed, lost their state, and recovered.
> The clients are ultimately responsible for re-establishing state.
>
> So, switching to another writable copy shouldn't be any worse
> than a server reboot should it ?
Except that servers for mission critical applications are
rarely rebooted, whereas if fileset migration is useful, it won't
be rare.
These is lease state and meta-data state.
lease state. The existing NFsv4 protocol allows server to
avoid grace periods after server reboots
if they records lease state in persistent
storage. If the fileset transfer protocol punts on
transfering lock state, then this cuts into the
availability of the fileset, because the receiving server will
have to return NFS4ERR_GRACE for the duration of the grace period
to re-establish leases.
Let's say a server is rated at 99.99 per cent availability,
and lets say you can market the server such that the 99.99
refers to per-fileset availablility.
This works out to around 3000 seconds of downtime per fileset
year. I've certainly seen systems up for years at time; 99.99 is not
even state of the art these days.
If you've got a grace period of 60 seconds, you can migrate a
filesystem 50 times per year, among such systems; probably
ok. Add another 9, and you can migrate it 5 times per year.
That's starting
to push it. 99.9999 percent availability and you can migrate one
every couple years. So for some users, migration of
writeable filesets is useless without migratable lock state.
meta-data state. State like persistent file handles, fileids, etc.,
if not handled in the server-to-server
protocol is going to cause obvious problems.
-mre
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 19:03:06 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16791
for ; Fri, 17 Aug 2001 19:03:06 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04143;
Fri, 17 Aug 2001 17:03:33 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13229;
Fri, 17 Aug 2001 16:02:39 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.81.36] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HN2WL26190
for ; Fri, 17 Aug 2001 16:02:32 -0700 (PDT)
Received: from eng.sun.com (pil.Eng.Sun.COM [129.146.86.124])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HN2Ve205620;
Fri, 17 Aug 2001 16:02:31 -0700 (PDT)
Sender: Salit.Levy-Gazit@eng.sun.com
Message-ID: <3B7DA2B0.F884617@eng.sun.com>
Date: Fri, 17 Aug 2001 16:03:12 -0700
From: salit gazit
Organization: Sun Microsystems
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.9 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Brent
CC: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References: <3B7D80DF.2C6D2638@eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Brent wrote:
>
> As for the NFSv4 attributes. Yes, the NFSv4 attribute set is
> a good guide to the kind of attributes that a replication
> protocol might support, though there are a few virtual attributes
> in there that may not be appropriate, e.g. the "changed" attribute
> is an opaque thingy that cannot easily be represented physically
> in any filesystem.
Is there a need for replication of nfsv4 attributes?
The mandatory and recommended attributes are derived from filesystem
or server internal attributes that may differ between the filesystems
(e.g. fileid, fsid, expire type, etc.). The named attributes
will be implemented as a directory in the filesystem (right, Jeff?),
so they will be replicated as part of the filesystem by default.
Salit
--
Standard disclaimers apply.
MailTo:salit@eng.sun.com
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 19:13:54 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16914
for ; Fri, 17 Aug 2001 19:13:53 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09781;
Fri, 17 Aug 2001 17:14:44 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15282;
Fri, 17 Aug 2001 16:13:51 -0700 (PDT)
Received: from centralmail2.Central.Sun.COM (centralmail2.Central.Sun.COM [129.147.62.11])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HNDhL26218
for ; Fri, 17 Aug 2001 16:13:43 -0700 (PDT)
Received: from dhcp-aus08-183.central.sun.com (dhcp-aus08-183.Central.Sun.COM [129.153.128.183])
by centralmail2.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA07270
for ; Fri, 17 Aug 2001 17:13:44 -0600 (MDT)
Received: (from shepler@localhost)
by dhcp-aus08-183.central.sun.com (8.11.3+Sun/8.11.3) id f7HNDX800567
for nfsv4-wg@sunroof.eng.sun.com; Fri, 17 Aug 2001 18:13:33 -0500 (CDT)
Date: Fri, 17 Aug 2001 18:13:33 -0500
From: Spencer Shepler
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
Message-ID: <20010817181333.B520@dhcp-aus08-183.central.sun.com>
Reply-To: shepler@eng.sun.com
Mail-Followup-To: Spencer Shepler ,
nfsv4-wg@sunroof.eng.sun.com
References: <3B7D80DF.2C6D2638@eng.sun.com> <3B7DA2B0.F884617@eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3B7DA2B0.F884617@eng.sun.com>
User-Agent: Mutt/1.3.19i
On Fri, salit gazit wrote:
> Brent wrote:
> >
> > As for the NFSv4 attributes. Yes, the NFSv4 attribute set is
> > a good guide to the kind of attributes that a replication
> > protocol might support, though there are a few virtual attributes
> > in there that may not be appropriate, e.g. the "changed" attribute
> > is an opaque thingy that cannot easily be represented physically
> > in any filesystem.
>
> Is there a need for replication of nfsv4 attributes?
> The mandatory and recommended attributes are derived from filesystem
> or server internal attributes that may differ between the filesystems
> (e.g. fileid, fsid, expire type, etc.). The named attributes
Or the attribute capabilities may be the same and being able to
replicate them is a desired feature.
> will be implemented as a directory in the filesystem (right, Jeff?),
> so they will be replicated as part of the filesystem by default.
That is an implementation detail that a replication/migration can not
rely upon. Native filesystems may be implemented in varying ways that
may allow for transfer via a well-defined mechanism but not as part of
what would be considered "normal" filesystem access.
--
- Spencer -
From nfs4-wg-request@sunroof.eng.sun.com Fri Aug 17 19:49:22 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17242
for ; Fri, 17 Aug 2001 19:49:22 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA03212;
Fri, 17 Aug 2001 16:46:00 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06807;
Fri, 17 Aug 2001 16:45:33 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7HNjOL26315;
Fri, 17 Aug 2001 16:45:24 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27246;
Fri, 17 Aug 2001 16:45:25 -0700 (PDT)
Received: from intfly.co.kr ([211.105.34.80])
by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11996;
Fri, 17 Aug 2001 16:45:23 -0700 (PDT)
Received: from gerrgdww2 (10-082.024.popsite.net [66.19.6.82])
by intfly.co.kr (8.11.0/8.11.0) with ESMTP id f7HNXCB26992;
Sat, 18 Aug 2001 08:33:12 +0900
Message-Id: <200108172333.f7HNXCB26992@intfly.co.kr>
From: "Greg Thomas"
Subject: Stay Home Every Day #7398
To: today94dw@intfly.co.kr
X-Mailer: Microsoft Outlook Express 4.72.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3
Mime-Version: 1.0
Date: Fri, 17 Aug 2001 17:49:56 -0500
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA17242
NEW COMPANY SEEKS REPS!
NEW Women's Product Mentioned On Oprah
CALL NOW...1-800-266-7240 ext. 2714
Leave Your Info After The 3 Minute SIZZLE Message
Dear Opportunity Seeker,
They say that two genuine opportunities come to us in a lifetime.
Well...Here is one of them. Back in 1999 when a major pharmaceutical
company developed the little blue pill...it left many sexually
unsatisfied women asking..."Where's Mine?". A well known OBGYN of
22+ years has developed a product that is Sexy, Profitable, Discreet
and actually works on the majority of women.
"Did you know that the Sexual Dysfunction Product industry did over
$1 BILLION in sales last year with the little blue pill alone?" Do
YOU
Want A Piece?
Here is why we feel this opportunity is HUGE!
* 43% of Adult women could use it.
* Its a BILLION Dollar Industry
* Product is all natural
* Product is gaining BRAND Recognition by being mentioned on
shows such as Oprah, EXTRA, and many many local evening NEWS
reports as we speak. All of
which had POSITIVE feedback to
report back to their viewers
* Highly Profitable...Many REPS are making $750 to $5000 a week
!
Some are already making a consistent 5 figure check each and
every week.
* Low startup cost
* Its over the counter, and does NOT need a prescription.
* Average of 1 out of every 20 people that are signing up to
become distributors are in the medical profession, Doctors,
Nurses,
Nurses Aides, etc.
* GROUND FLOOR Opportunity- It just started Jan 22, 2001.
* Company is a subsidiary of a PUBLICLY traded company that has
been on NASDAQ and around for over 10 years.
CALL NOW...1-800-266-7240 ext. 2714
Leave Your Info After The 3 Minute SIZZLE Message
********************************************************************
If you have never requested more information on Bizops please remove
at:
mailto:quikls@yahoo.com?subject=remove
*********************************************************************
From nfs4-wg-request@sunroof.eng.sun.com Sat Aug 18 19:28:21 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16390
for ; Sat, 18 Aug 2001 19:28:20 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19376;
Sat, 18 Aug 2001 17:28:53 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21815;
Sat, 18 Aug 2001 16:28:06 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7INRvL28225
for ; Sat, 18 Aug 2001 16:27:58 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA24809;
Fri, 17 Aug 2001 21:18:54 -0700 (PDT)
Received: from emc.com (emcmail.lss.emc.com [168.159.48.78])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA09246;
Fri, 17 Aug 2001 22:18:49 -0600 (MDT)
Received: from emc.com ([172.25.30.243])
by emc.com (8.10.1/8.10.1) with ESMTP id f7I4IqL11298;
Sat, 18 Aug 2001 00:18:52 -0400 (EDT)
Message-ID: <3B7DED49.33C84758@emc.com>
Date: Sat, 18 Aug 2001 00:21:29 -0400
From: Uresh Vahalia
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Brent
CC: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References: <3B7D80DF.2C6D2638@eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Brent wrote:
> Robert Thurlow wrote:
> >> I think we should try to keep this protocol independent of v4
> >> and make it a general protocol that's independent of the
> >> up with requirements unusual to any single file access protocol,
> >> e.g. replication of filehandles or file open state.
> >
> > The problem with making it independant of NFSv4 is that I think
> > we want correct replication of ALL of the NFSv4 attributes when
> > possible; I expected to re-use the nfsv4.x file to be able to
> > express these attributes in the server-to-server protocol. If
> > this is the generic effort of an separate WG, can we do this?
> > And if we can't do this, can we achieve correct replication and
> > migration?
>
> Realistically, we won't ever have correct replication/migration
> unless it's across homogeneous filesystems. I think we'll be
Absolutely. But if it is merely something that kind of sort of works
most of the time, customers would doubtless seek safe haven in a
homogenous solution.
>
> happy with something that mostly works, even if it's not 100%
> perfect.
>
> As for the NFSv4 attributes. Yes, the NFSv4 attribute set is
> a good guide to the kind of attributes that a replication
> protocol might support, though there are a few virtual attributes
> in there that may not be appropriate, e.g. the "changed" attribute
> is an opaque thingy that cannot easily be represented physically
> in any filesystem.
>
>
> Brent
From nfs4-wg-request@sunroof.eng.sun.com Sat Aug 18 19:33:26 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16430
for ; Sat, 18 Aug 2001 19:33:25 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02186;
Sat, 18 Aug 2001 16:32:58 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22099;
Sat, 18 Aug 2001 16:32:19 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7INWBL28275;
Sat, 18 Aug 2001 16:32:11 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04670;
Sat, 18 Aug 2001 10:59:05 -0700 (PDT)
Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42])
by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20057;
Sat, 18 Aug 2001 11:59:20 -0600 (MDT)
Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net)
by dfw-smtpout2.email.verio.net with esmtp
id 15YANB-0001Yl-00; Sat, 18 Aug 2001 17:59:01 +0000
Received: from [63.184.75.187] (helo=localhost)
by dfw-mmp2.email.verio.net with esmtp
id 15YAN5-00032Q-00; Sat, 18 Aug 2001 17:58:55 +0000
X-Sender: robertlong@veriomail.com
From: Bob Long
To: "Mortgage Rate Info"
Date: Sat, 18 Aug 2001 11:05:03 -0700
Subject: Need a Home Loan? We Can Help!!
Reply-To: robertlong@veriomail.com
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_001__17172340_39903.59"
Message-Id:
This is a Multipart MIME message.
------=_NextPart_000_001__17172340_39903.59
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
------=_NextPart_000_001__17172340_39903.59
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64
DQoNCjxIVE1MPg0KDQo8aGVhZD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIg
Q09OVEVOVD0idGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSI+DQo8IURPQ1RZUEUgSFRN
TCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgNC4wIFRyYW5zaXRpb25hbC8vRU4iPg0KPFRJ
VExFPkZyZWUgUmF0ZSBRdW90ZTwvVElUTEU+DQo8TUVUQSBjb250ZW50PSJ0ZXh0L2h0bWw7
IGNoYXJzZXQ9aXNvLTg4NTktMSIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PFhNRVRBIA0K
Y29udGVudD0iTW96aWxsYS80LjcgW2VuXSAoV2luOTg7IEkpIFtOZXRzY2FwZV0iIG5hbWU9
IkdFTkVSQVRPUiI+DQo8TUVUQSBjb250ZW50PSJNaWNyb3NvZnQgRnJvbnRQYWdlIDQuMCIg
bmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJhY2tn
cm91bmQ9aHR0cDovLzIxNy42Ny4yMzAuMTUvbW9uZXlfZ3IuanBnIGJnQ29sb3I9I2ZmZmZm
ZiBiZ3Byb3BlcnRpZXM9ImZpeGVkIj4NCjxESVYgc3R5bGU9IkZPTlQ6IDEwcHQgYXJpYWwi
Pg0KPERJVj4mbmJzcDs8L0RJVj48L0RJVj4NCjxESVY+PEJSPjwvRElWPg0KPFAgYWxpZ249
Y2VudGVyPjxlbT48Yj48Zm9udCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNiI+JnF1b3Q7UmVm
aW5hbmNpbmcgWW91cg0KQ3VycmVudCBNb3J0Z2FnZSBNYWtlcyAkZW5zZSEmcXVvdDs8L2Zv
bnQ+PC9iPjwvZW0+PC9QPg0KPHAgYWxpZ249ImNlbnRlciI+PGI+PGZvbnQgc2l6ZT0iNCI+
TW9ydGdhZ2UgUmF0ZXMgQXJlIFNvIExvdyEmbmJzcDs8L2ZvbnQ+PC9iPjwvcD4NCjxwIGFs
aWduPSJjZW50ZXIiPjxiPjxmb250IHNpemU9IjQiPllvdSBDYW4gU2F2ZSBUaG91c2FuZHMg
T2YgRG9sbGFycyBCeSBUYWtpbmcNCkFkdmFudGFnZSBOb3chPC9mb250PjwvYj48L3A+DQo8
UCBhbGlnbj1jZW50ZXI+PEVNPjxCPjxGT05UIGNvbG9yPSNmZjAwMDAgc2l6ZT01PiZxdW90
O1dFIEFSRSBBTiBBU1NPQ0lBVElPTiBPRg0KTU9SVEdBR0UgQlJPS0VSUyBBTkQgTEVOREVS
UyA8L0ZPTlQ+PC9CPjwvRU0+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxFTT48Qj48Rk9OVCBj
b2xvcj0jZmYwMDAwIHNpemU9NT5XSVRIIFRIRSBCRVNUIFJBVEVTIEFORCBUSEUgTE9XRVNU
DQpDT1NUUyEmcXVvdDwvRk9OVD48L0I+PC9FTT48L1A+DQo8cCBhbGlnbj0iY2VudGVyIj4m
bmJzcDs8L3A+DQo8UCBhbGlnbj1jZW50ZXI+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTQ+
PEI+V2UmbmJzcDtoYXZlIHRob3VzYW5kcyBvZiBsb2FuIA0KcHJvZ3JhbXMgdGhyb3VnaCBo
dW5kcmVkcyBvZiBsZW5kZXJzITxCUj48L0I+PC9GT05UPjxGT05UIHNpemU9Mz48L0ZPTlQ+
PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJPTkc+PEZPTlQgc2l6ZT01PllvdSBjYW4gY2hv
b3NlIGZyb20mbmJzcDsiQWRqdXN0YWJsZSBSYXRlDQpNb3J0Z2FnZXMgDQphcyBsb3cgYXMg
My45NSUmcXVvdDs8L0ZPTlQ+PC9TVFJPTkc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxTVFJP
Tkc+PEZPTlQgc2l6ZT01PmFuZCZuYnNwOyJGaXhlZCBSYXRlIE1vcnRnYWdlcyBhcyBsb3cg
YXMNCjYuNTAlJm5ic3A7PC9GT05UPjwvU1RST05HPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48
U1RST05HPjxGT05UIHNpemU9NT5hbGwgd2l0aCB0aGUgbG93ZXN0IGNvc3RzIGluIHRoZQ0K
TmF0aW9uISZxdW90OzwvRk9OVD48L1NUUk9ORz48QklHPjxCSUc+PEZPTlQgY29sb3I9I2Zm
MDAwMD4qPC9GT05UPjwvQklHPjwvQklHPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCAN
CnNpemU9NT48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+JnF1b3Q7PGI+PGk+WU9VIENBTiA8dT5C
VVkgRE9XTiBZT1VSIElOVEVSRVNUIFJBVEU8L3U+DQpUTzwvaT48L2I+PC9mb250PjwvRk9O
VD48L1A+DQo8UCBhbGlnbj1jZW50ZXI+PGZvbnQgY29sb3I9IiNGRjAwMDAiIHNpemU9IjUi
PjxiPjxpPkFTIExPVyBBUyBZT1UgQ0FODQpBRkZPUkQhJnF1b3Q7PC9pPjwvYj48L2ZvbnQ+
PEZPTlQgDQpzaXplPTU+PEJSPjwvRk9OVD48Rk9OVCBzaXplPTM+PC9GT05UPjwvUD4NCjxQ
IGFsaWduPWNlbnRlcj48Rk9OVCBzaXplPSswPjxGT05UIGNvbG9yPSMwMDAwZmYgc2l6ZT0y
PjxCSUc+PEJJRz48Rk9OVCANCmNvbG9yPSNmZjAwMDAgc2l6ZT01Pio8L0ZPTlQ+PC9CSUc+
PFNUUk9ORz5BbGwgcmF0ZXMgYXJlIGJhc2VkIG9uIA0KcXVhbGlmaWNhdGlvbjwvU1RST05H
PiE8L0JJRz48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWNlbnRlcj48Rk9OVCBzaXpl
PSswPjxGT05UIHNpemU9Mj48QklHPjwvQklHPjwvRk9OVD48Rk9OVCANCmNvbG9yPSMwMDAw
ZmY+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+PEEgaHJlZj0iaHR0cDovLzIxNy42
Ny4yMzAuMTUiIA0KdGFyZ2V0PV9ibGFuaz48Rk9OVCBzaXplPTU+PFNUUk9ORz48Rk9OVCBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPkNsaWNrIGhlcmUgZm9yIA0KeW91ciA8L0ZPTlQ+PEZP
TlQgc2l6ZT02PjxGT05UIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PEVNPiJGUkVFIFJBVEUg
DQpRVU9URSIhPC9FTT48L0ZPTlQ+PC9GT05UPjwvU1RST05HPjwvRk9OVD48L0E+PC9GT05U
PjwvRk9OVD48L0ZPTlQ+PC9GT05UPjwvUD4NCjxQIGFsaWduPWxlZnQ+Jm5ic3A7PC9QPg0K
PFAgYWxpZ249bGVmdD48aT48Yj48Zm9udCBmYWNlPSJBcmlhbCIgc2l6ZT0iKzAiPkNMSUNL
IE9OIExPQU5TIEJFTE9XIEZPUiBZT1VSDQpGUkVFIEFQUExJQ0FUSU9OITwvZm9udD48L2I+
PC9pPjxGT05UIGZhY2U9QXJpYWw+PEJSPjwvRk9OVD48L1A+DQo8UCBhbGlnbj1sZWZ0PjxT
VFJPTkc+PEVNPjxBIGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxh
bms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlB1cmNoYXNlIExvYW5zPC9mb250
PjwvQT4gPEZPTlQgc2l6ZT01Pg0KPC9GT05UPiA8L0VNPjxGT05UIA0Kc2l6ZT00Pi0gPEVN
PlRob3VzYW5kcyBvZiBwcm9ncmFtcyANCmZvciBGaXJzdCBNb3J0Z2FnZXMhPC9FTT48L0ZP
TlQ+PEk+PC9JPjwvU1RST05HPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMD48QlI+PEJSPjwv
Rk9OVD48L0k+PEEgaHJlZj0iaHR0cDovLzIxNy42Ny4yMzAuMTUiIF9ibGFuaz8+PEVNPjxT
VFJPTkc+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPlJlZmluYW5jZSBMb2Fuczwv
Zm9udD48L1NUUk9ORz48L0VNPjxJPjxGT05UIA0KY29sb3I9IzAwMDAwMCBzaXplPTI+IDwv
Rk9OVD48L0k+PC9BPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00Pi0gPEI+UmVkdWNl
IHlvdXIgDQptb250aGx5IHBheW1lbnRzIGFuZDwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAw
IHNpemU9Mj4gPC9GT05UPjxGT05UIA0KY29sb3I9I2ZmMDAwMCBzaXplPTU+R2V0IENhc2gg
QmFjayE8L0ZPTlQ+PC9CPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT00PiANCjwvRk9OVD48
Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mz48QlI+PEJSPjwvRk9OVD48L0k+PEEgDQpocmVm
PSJodHRwOi8vMjE3LjY3LjIzMC4xNSIgdGFyZ2V0PV9ibGFuaz48Zm9udCBjb2xvcj0iIzgw
MDA4MCI+PEVNPjxCPjxGT05UIHNpemU9NT5TZWNvbmQgDQpNb3J0Z2FnZXM8L0ZPTlQ+PC9C
PjwvRU0+PEk+PEZPTlQgc2l6ZT0zPiA8L0ZPTlQ+PC9JPg0KPC9mb250PiA8L0E+PEk+PEZP
TlQgY29sb3I9IzAwMDAwMCBzaXplPTM+IC0gPC9GT05UPjxCPjxGT05UIA0KY29sb3I9IzAw
MDAwMCBzaXplPTQ+V2UgY2FuIGhlbHAgeW91IGdldCBmcm9tIDwvRk9OVD48Rk9OVCBjb2xv
cj0jZmYwMDAwIA0Kc2l6ZT01PjkwJTwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9
ND4gdXAgdG8gPC9GT05UPjxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+MTI1JTwvRk9O
VD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9ND4gb2YgeW91ciBob21lcyB2YWx1ZSEgKHJh
dGlvcyB2YXJ5IA0KYnkgc3RhdGUpPC9GT05UPjwvQj48L1A+DQo8UCBhbGlnbj1sZWZ0PjxB
IGhyZWY9Imh0dHA6Ly8yMTcuNjcuMjMwLjE1IiANCnRhcmdldD1fYmxhbms+PEI+PGZvbnQg
c2l6ZT0iNSIgY29sb3I9IiM4MDAwODAiPkRlYnQgQ29uc29saWRhdGlvbjwvZm9udD48L0I+
PC9BPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiA8Rk9OVCBjb2xvcj0jMDAwMDAwIHNp
emU9ND4tIA0KPEI+Q29tYmluZSA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+
YWxsPC9GT05UPjxGT05UIGNvbG9yPSMwMDAwMDAgDQpzaXplPTQ+IHlvdXIgYmlsbHMgaW50
byA8L0ZPTlQ+PEZPTlQgY29sb3I9I2ZmMDAwMCBzaXplPTU+T25lIExvdyBNb250aGx5IA0K
UGF5bWVudCE8L0ZPTlQ+PC9CPjxCUj48QlI+PC9GT05UPjxCPjxBIA0KaHJlZj0iaHR0cDov
LzIxNy42Ny4yMzAuMTUiIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0iNSIgY29sb3I9IiM4
MDAwODAiPkZpcnN0IFRpbWUgSG9tZSBCdXllcnM8L2ZvbnQ+PC9BPjxGT05UIGNvbG9yPSMw
MDAwMDAgc2l6ZT0zPiAtIA0KPEZPTlQgY29sb3I9IzAwMDAwMCBzaXplPTQ+V2UgY2FuIGhl
bHAgeW91IGJ1eSB3aXRoIDxGT05UIGNvbG9yPSNmZjAwMDAgDQpzaXplPTU+TG93PC9GT05U
PjwvRk9OVD48Rk9OVCBjb2xvcj0jZmYwMDAwIHNpemU9NT4gTW9uZXkgRG93bjwvRk9OVD48
Rk9OVCANCmNvbG9yPSMwMDAwMDAgc2l6ZT00PiwgYW5kIGV2ZW4gPC9GT05UPjxGT05UIGNv
bG9yPSNmZjAwMDAgc2l6ZT01PkdldCBDYXNoIA0KQmFjayE8L0ZPTlQ+PC9GT05UPjwvQj48
L1A+PC9JPg0KPFAgYWxpZ249Y2VudGVyPjxCSUc+PEJJRz48Rk9OVCBjb2xvcj0jZmYwMDAw
Pio8L0ZPTlQ+PC9CSUc+QWxsIHJhdGVzIGFyZSBiYXNlZCANCm9uIHF1YWxpZmljYXRpb24h
PC9CSUc+PC9QPg0KPFAgYWxpZ249Y2VudGVyPjxCPjxJPjxGT05UIGNvbG9yPSMwMDAwMDAg
c2l6ZT02PldlIGhhdmUgcHJvZ3JhbXMgZm9yIA0KPC9GT05UPjxGT05UIGNvbG9yPSNmZjAw
MDAgc2l6ZT02PjxVPkVWRVJZPC9VPjwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9
Nj4gDQpjcmVkaXQgc2l0dWF0aW9uITwvRk9OVD48QlI+PEJSPjxBIGhyZWY9Imh0dHA6Ly8y
MTcuNjcuMjMwLjE1IiB0YXJnZXQ9X2JsYW5rPjxGT05UIA0KY29sb3I9IzAwMDBmZiBzaXpl
PTU+Q2xpY2sgaGVyZSBmb3IgeW91ciBGUkVFIFJBVEUgUVVPVEUhPC9GT05UPjwvQT48L0k+
PC9CPjwvUD4NCjxQIGFsaWduPWxlZnQ+PEZPTlQgY29sb3I9IzAwODAwMD48U1RST05HPiAN
CklmIHlvdSBmZWVsIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGluIGVy
cm9yLCBwbGVhc2UgZm9sbG93IHRoZSBiZWxvdyANCmluc3RydWN0aW9ucyBhbmQgeW91IHdp
bGwgYmUgcmVtb3ZlZCBpbW1lZGlhdGVseS4gIFdlIGltbWVkaWF0ZWx5IGhvbm9yIGFsbCBy
ZXF1ZXN0cyANCnRvIGJlIHJlbW92ZWQgZnJvbSB0aGlzIGxpc3QuIFRoaXMgbWVzc2FnZSBp
cyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGggDQp0aGUgRmVkZXJhbCBs
ZWdpc2xhdGlvbiBmb3IgY29tbWVyY2lhbCBlLW1haWwgKEguUi40MTc2IC0gU2VjdGlvbiAx
MDEsICBQYXJhZ3JhcGggDQooZSkoMSkoYSkpIGFuZCBCaWxsIHMuMTYxOCBUaXRsZSBJSUkg
cGFzc2VkIGJ5IHRoZSAxMDV0aCBVUyBDb25ncmVzcy4sIGZ1cnRoZXIgDQp0cmFuc21pc3Np
b25zIHRvIHlvdSBieSB0aGUgc2VuZGVyIG9mIHRoaXMgZS1tYWlsIG1heSBiZSBzdG9wcGVk
IGF0IG5vIGNvc3QgdG8geW91IA0KYnkgc3VibWl0dGluZyBhIHJlcXVlc3QgdG8gYmUgcmVt
b3ZlZC4gPGEgaHJlZj0ibWFpbHRvOmdyZWF0cmF0ZXMxMDhAZXhjaXRlLmNvbT9zdWJqZWN0
PVBMRUFTRV9SRU1PVkVfTUUhX1ZSTzEiPkNsaWNrIEhlcmUgdG8gU2VuZCBhIFJlbW92ZSBS
ZXF1ZXN0PC9hPi4NCk5vIG5lZWQgdG8gdHlwZSBhbnkgbWVzc2FnZS48L1NUUk9ORz48L0ZP
TlQ+PC9QPjwvQk9EWT48L0hUTUw+
------=_NextPart_000_001__17172340_39903.59--
From nfs4-wg-request@sunroof.eng.sun.com Sat Aug 18 19:57:07 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16553
for ; Sat, 18 Aug 2001 19:57:06 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23716;
Sat, 18 Aug 2001 17:57:38 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19037;
Sat, 18 Aug 2001 16:57:03 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7INr4L28474;
Sat, 18 Aug 2001 16:53:04 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA22706;
Fri, 17 Aug 2001 21:56:05 -0700 (PDT)
From: make_10k_a_month@excite.com
Received: from domino1.sfbb.org (mail.sfbb.org [208.62.8.161])
by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05025;
Fri, 17 Aug 2001 21:56:04 -0700 (PDT)
To: nfs4-wg-request@sunroof.eng.sun.com
Subject: YOU DESERVE MORE Than $8-12 An Hour!
Date: Fri, 17 Aug 2001 21:10:11
Mime-Version: 1.0
Message-ID:
Content-Type: text/html; charset="DEFAULT_CHARSET"
Hello nmaltseva,
DID YOU MAKE $5,000 LAST MONTH? IF NOT, YOU NEED TO JOIN US TODAY!
Market the hottest consumer savings package in America today and earn up to
$1,000 each and every time someone joins for $0 DOWN!
Imagine being plugged into a proven system that puts your entire business on
auto-pilot and has you earning $3,000 every week!
IT IS TRUE! You can be in business for $0 DOWN! And you can easily make
$3,000 your very first week...and we'll show you how! Your business will literally
explode overnight when you join our team and plug into our exclusive marketing
system!
We provide you with all the tools and the absolute BEST marketing system available
on the web. The only thing you need to do is join our team and plug into our proven
system for success today!
I did it all with my computer! People sign up like crazy! First I said, ok, I am
financially totally down, I need to give this one a try. But after two weeks I am
already out of dept! Oh god, I did not expect that! And I am not a sales person and I
did it! I am so excited, thank you Richard and Mary!
- Randy S. Los Angeles, CA
I was in my chiropractor's office when the secretary was about to throw out a fax
that they had just received. The fax was similar to this email and caught my eye. I
did exactly what it told me to do (a fax blast) and in my second day I made $6,000.
No hard selling, no hustling my friends, just friendly people looking at a great
opportunity and wanting in. Even if it took me a month to make an extra $5,000 I
would have been happy, but $6,000 in my second day, wow! I'm excited!
- Dave W. Newport Beach, CA
If you have been looking for something that is NOT MLM, is turnkey and very easy
to do, then join us now. This is a truly explosive income opportunity! Sign up 3
people and earn $3,000! Sign up 10 people & earn $10,000...how much do you
want?
This is the easiest sale you will EVER make! GET STARTED WITH INCREDIBLE
$0 DOWN + START EARNING $1,000 COMMISSIONS YOUR FIRST MONTH!
All sales wired into your checking account on a daily basis!
========================================================
This message is in full compliance with U.S. Federal requirements for commercial
email under bill S.1618 Title lll, Section
301, Paragraph (a)(2)(C) passed by the 105th U.S. Congress and cannot be
considered SPAM since it includes a remove mechanism.
From nfs4-wg-request@sunroof.eng.sun.com Sat Aug 18 20:25:44 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16723
for ; Sat, 18 Aug 2001 20:25:44 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28226;
Sat, 18 Aug 2001 18:23:56 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA20212;
Sat, 18 Aug 2001 17:23:30 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7J0JaL28686
for ; Sat, 18 Aug 2001 17:19:36 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA15254;
Fri, 17 Aug 2001 21:09:55 -0700 (PDT)
Received: from emc.com (emcmail.lss.emc.com [168.159.48.78])
by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA23469;
Fri, 17 Aug 2001 21:09:54 -0700 (PDT)
Received: from emc.com ([172.25.30.243])
by emc.com (8.10.1/8.10.1) with ESMTP id f7I49rL09382;
Sat, 18 Aug 2001 00:09:53 -0400 (EDT)
Message-ID: <3B7DEB27.53BBCA8B@emc.com>
Date: Sat, 18 Aug 2001 00:12:23 -0400
From: Uresh Vahalia
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Robert Thurlow
CC: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Robert Thurlow wrote:
> > We should define the objectives for protocol support of
> > replication/migration.
>
> I think we should mainly be focused on defining a protocol
> which permits a server to contact another server to initiate
> and complete a data transfer to create or maintain filesystem
> replicas, or to move a filesystem.
>
> > Do we want to:
> >
> > 1. Define a standard way for a server to replicate/migrate data to another,
> > possibly heterogenous, server?
>
> I believe this should be our priority here, with "heterogeneous"
> being the key word. Sun has a block-level replication product
> which is good, so does NetApp - but they're only capable of doing
> that with the same brand of machines. Islands of functionality
> like this do not meet customer needs.
Most serious server vendors have some form of block-level replication products.
Some of us also have filesystem replication products, albeit homogenous.
It is hard to imagine that heterogenous file system replication is a real customer
need, although you will always find the bleeding edge guys who absolutely must
have it. It could be a very exciting technology to develop, but commercially it
is likely to be a solution looking for a problem.
>
> > 2. Provide useful mechanisms for servers to send/receive file data and
> > attributes to each other so that server vendors can build effective
> > replication/migration solutions?
>
> I may be misunderstanding this, but I don't think we're interested
> in building a "toolkit" - we want a protocol servers can speak to
> transfer entire filesystems and then propagate updates to replicas.
> The IETF does protocols and not APIs, so this seems necessary.
To clarify my point -- you could build a minimal protocol that provides essential
communication based on which vendors could build different kinds of solutions, or
you could do something much more comprehensive, which in effect would become a
complete recipe for replication/migration.
>
> > 3. Provide ways for clients to control what gets replicated/migrated (whole
> > file systems, directory trees, individual files), when, and where?
>
> I don't think we are standardizing how an administrator at her
> desk communicates her desire to have servers achieve a migration
> or replication activity, but perhaps we should be doing that.
Migrating an entire file system is useful, but often not good enough. The ability
to specify which parts of the file system should be migrated makes this extremely
powerful and useful.
>
> > 4. Allow clients to recognize the existence of replicas or be informed that
> > some data has been migrated elsewhere, and to optimize their data access
> > accordingly (load balance among replicas, for instance)?
>
> Right now, we haven't been talking much about how resource info
> is "published" so that clients can know about it. It is clearly
> important, and customers have BIG complaints that this is not
> standardized, leaving them to manage more islands of functionality.
>
> But replication only adds a couple of requirements to this issue
> ("give me multiple names" and "permit this info to be mutable"),
> so I would think this is not a goal for this work. If we wanted
> to discuss doing NFS resource discovery in a standard way, I'd
> think that would be a useful effort, but not tied to replication
> and migration.
Whether part of replication this effort or not, this is a key feature that solves
some important customer problems. As we have noted, many vendors have a
homogenous replication protocol. However, this cannot be effectively leveraged by
clients, except for pure read-only environments (here too, I am not sure how many
other client implementations have incorporated Sun's automounter enhancement).
Let us assume a server vendor (or cooperating vendors) has a server replication
solution with one writer and one or more readers. Assume further that this
solution has the ability to switch the writer role from one server to another,
perhaps instantly. To make this useful, clients need a way of knowing (a) the
number of replicas and their location, (b) which one of them is writable, and (c)
any change in this configuration. The same applies in the more complex cases of
multiple writers.
Likewise, for migration, it is very useful for a server to be able to inform a
client that a particular data set is located on a different server, so that
adminstrators can freely move data sets around without disrupting client access
and major management hassles.
Finally, why does migration require ANY protocol support beyond regular NFS? Even
v3 should work just fine.
Uresh
>
>
> Rob T
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 20 14:59:52 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00114
for ; Mon, 20 Aug 2001 14:59:52 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21468;
Mon, 20 Aug 2001 12:00:26 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07104;
Mon, 20 Aug 2001 11:55:58 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.84.45] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KItmL06019
for ; Mon, 20 Aug 2001 11:55:48 -0700 (PDT)
Received: from eng.sun.com (terra.Eng.Sun.COM [129.146.86.99])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KItmG545397
for ; Mon, 20 Aug 2001 11:55:48 -0700 (PDT)
Sender: Brent.Callaghan@eng.sun.com
Message-ID: <3B815D2F.DC44BDD8@eng.sun.com>
Date: Mon, 20 Aug 2001 11:55:43 -0700
From: Brent
Organization: NFS Whackers
X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References: <3B7C42AE.69FCEA7B@eng.sun.com> <3B7C56B2.A05405F4@eisler.com> <3B7D7C22.7A393AB@eng.sun.com> <3B7D9F2C.5FCB1BB7@eisler.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Mike Eisler wrote:
>
> Brent wrote:
> > So, switching to another writable copy shouldn't be any worse
> > than a server reboot should it ?
>
> Except that servers for mission critical applications are
> rarely rebooted, whereas if fileset migration is useful, it won't
> be rare.
>
> These is lease state and meta-data state.
>
> lease state. The existing NFsv4 protocol allows server to
> avoid grace periods after server reboots
> if they records lease state in persistent
> storage. If the fileset transfer protocol punts on
> transfering lock state, then this cuts into the
> availability of the fileset, because the receiving server will
> have to return NFS4ERR_GRACE for the duration of the grace period
> to re-establish leases.
>
> Let's say a server is rated at 99.99 per cent availability,
> and lets say you can market the server such that the 99.99
> refers to per-fileset availablility.
> This works out to around 3000 seconds of downtime per fileset
> year. I've certainly seen systems up for years at time; 99.99 is not
> even state of the art these days.
Yes, if you want to make three 9's availability a requirement for
this protocol, then you have to move the lock and lease state.
But if it becomes a requirement, then the result will be
a protocol so complex to implement, that nobody will do it.
All we have today is proprietary, block-level protocols like
Sun's SNDR, EMC's SRDF, or NetApp's SnapMirror. I don't
think any of those move file open or lock state either, but
I'm sure they're widely used, and by mission critical apps.
A good initial stab would be a protocol that does a good
job of creating read-only replicas and the synchronization
of periodic snapshots. If that is successful (and if anyone's
interested) then apply some read-write and high availability
requirements to a follow-on standard.
Brent
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 20 15:15:40 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00614
for ; Mon, 20 Aug 2001 15:15:40 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15353;
Mon, 20 Aug 2001 13:16:06 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10868;
Mon, 20 Aug 2001 12:11:01 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KJ9UL06132
for ; Mon, 20 Aug 2001 12:09:31 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21139;
Mon, 20 Aug 2001 12:09:31 -0700 (PDT)
Received: from eagle.professionals.com (eagle.professionals.com [206.127.192.10])
by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17327;
Mon, 20 Aug 2001 12:09:30 -0700 (PDT)
Received: from eisler.com ([206.27.132.50])
(authenticated)
by eagle.professionals.com (8.10.2/8.10.2) with ESMTP id f7KJ73e28591;
Mon, 20 Aug 2001 12:07:04 -0700 (PDT)
Sender: mre@eagle.professionals.com
Message-ID: <3B816083.B7476495@eisler.com>
Date: Mon, 20 Aug 2001 12:09:55 -0700
From: Mike Eisler
X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Brent , nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References: <3B7C42AE.69FCEA7B@eng.sun.com> <3B7C56B2.A05405F4@eisler.com> <3B7D7C22.7A393AB@eng.sun.com> <3B7D9F2C.5FCB1BB7@eisler.com> <3B815D2F.DC44BDD8@eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
> All we have today is proprietary, block-level protocols like
> Sun's SNDR, EMC's SRDF, or NetApp's SnapMirror. I don't
> think any of those move file open or lock state either, but
> I'm sure they're widely used, and by mission critical apps.
I'm sure that none of them are used with writeable, migratable
filesets.
> A good initial stab would be a protocol that does a good
> job of creating read-only replicas and the synchronization
> of periodic snapshots. If that is successful (and if anyone's
Which is exactly where we end up if we constrain the
problem in the manner you listed (which prompted my response).
-mre
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 20 16:03:48 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02046
for ; Mon, 20 Aug 2001 16:03:48 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13017;
Mon, 20 Aug 2001 13:56:37 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29073;
Mon, 20 Aug 2001 12:55:56 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.85.105] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KJtjL06310
for ; Mon, 20 Aug 2001 12:55:45 -0700 (PDT)
Received: from eng.sun.com (terra.Eng.Sun.COM [129.146.86.99])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KJtjG561505
for ; Mon, 20 Aug 2001 12:55:45 -0700 (PDT)
Sender: Brent.Callaghan@eng.sun.com
Message-ID: <3B816B3C.682E883A@eng.sun.com>
Date: Mon, 20 Aug 2001 12:55:40 -0700
From: Brent
Organization: NFS Whackers
X-Mailer: Mozilla 4.76C-CCK-MCD Netscape [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References: <3B7D80DF.2C6D2638@eng.sun.com> <3B7DED49.33C84758@emc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Uresh Vahalia wrote:
>
> Brent wrote:
> > Realistically, we won't ever have correct replication/migration
> > unless it's across homogeneous filesystems. I think we'll be
>
> Absolutely. But if it is merely something that kind of sort of works
> most of the time, customers would doubtless seek safe haven in a
> homogenous solution.
... for which block-level solutions already exist. No problem with that.
I'm guessing that most apps make fairly minimal demands on filesystem
features so that they have maximal portability.
So I hope it's reasonable to assume that a protocol that works across
heterogeneous filesystems, albeit with less than 100% support of features,
will be useful and popular. Isn't that the premise behind NFS ?
Brent
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 20 16:23:57 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02881
for ; Mon, 20 Aug 2001 16:23:57 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04063;
Mon, 20 Aug 2001 14:24:25 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04423;
Mon, 20 Aug 2001 13:23:54 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KKNaL06668
for ; Mon, 20 Aug 2001 13:23:36 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24497
for ; Mon, 20 Aug 2001 13:23:38 -0700 (PDT)
Received: from mx01-a.netapp.com (mx01-a.netapp.com [198.95.226.53])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03335
for ; Mon, 20 Aug 2001 14:23:32 -0600 (MDT)
Received: from hawk.corp.netapp.com (hawk.corp.netapp.com [10.10.20.101])
by mx01-a.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f7KKNLX27671;
Mon, 20 Aug 2001 13:23:21 -0700 (PDT)
Received: from ussvlexc01.corp.netapp.com (localhost [127.0.0.1])
by hawk.corp.netapp.com (8.11.1/8.11.1/NTAP-1.2) with ESMTP id f7KKNLq12747;
Mon, 20 Aug 2001 13:23:21 -0700 (PDT)
Received: by ussvlexc01.corp.netapp.com with Internet Mail Service (5.5.2653.19)
id ; Mon, 20 Aug 2001 13:23:54 -0700
Message-ID: <8C610D86AF6CD4119C9800B0D0499E333355A1@red.nane.netapp.com>
From: "Noveck, Dave"
To: "'Brent'" , nfsv4-wg@sunroof.eng.sun.com
Subject: RE: Replication and migration requirements
Date: Mon, 20 Aug 2001 13:23:18 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Brent wrote:
> Uresh Vahalia wrote:
> >
> > Brent wrote:
> > > Realistically, we won't ever have correct replication/migration
> > > unless it's across homogeneous filesystems. I think we'll be
> >
> > Absolutely. But if it is merely something that kind of sort of works
> > most of the time, customers would doubtless seek safe haven in a
> > homogenous solution.
>
> ... for which block-level solutions already exist. No problem with that.
>
> I'm guessing that most apps make fairly minimal demands on filesystem
> features so that they have maximal portability.
People who are interested in portability, often test whether certain
functionality is present and do different things so that they can
workaround the case in which the functionality is not present.
If the results of that test can be invalidated at any instant as a
result of migration, then such apps would have a problem.
Apart from the apps, lots of client implementations may have problems
if features that were present one instant are not available the next.
Consider all the optional attributes and how tough it might be
to deal with migration to a file-system that supported a smaller set,
while keeping all the client code from losing its mind.
I think one of the goals here should be to define the conditions for
reasonably safe migration, so that you can say "I can't do that",
rather than trying and causing chaos.
> So I hope it's reasonable to assume that a protocol that works across
> heterogeneous filesystems, albeit with less than 100% support of features,
> will be useful and popular. Isn't that the premise behind NFS ?
As far as the protocol goes, yes. But the user who uses NFS generally
has some contraints on what is on the server side. I think it would be
very hard to find a significant application that that would work with
any possible server implementation. This is the other side of the
decision that NFS doesn't dictate fs semantics. To the degree that
you depend on fs semantics, you are depending not on NFS but on the
semantics exported by the server fs.
NFS-v4, because it embraces so many optional features, (attributes,
types of handles, named attributes, etc.) makes this issue larger
than it was in v2 and v3. Also, the very attempt to be less
UNIX-centric creates more opportunities for multiple types of
clients to have a larger range of expectations regarding server
behavior, such that these could be invalidated by an inappropriate
migration.
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 20 18:20:55 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05762
for ; Mon, 20 Aug 2001 18:20:54 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28001;
Mon, 20 Aug 2001 16:21:31 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28379;
Mon, 20 Aug 2001 15:20:40 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KMKSL07785
for ; Mon, 20 Aug 2001 15:20:29 -0700 (PDT)
Received: from peyto (vpn-129-147-152-129.Central.Sun.COM [129.147.152.129])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with SMTP id f7KMKRG606084;
Mon, 20 Aug 2001 15:20:27 -0700 (PDT)
Date: Mon, 20 Aug 2001 16:20:58 -0600 (MDT)
From: Robert Thurlow
Reply-To: Robert Thurlow
Subject: Re: Replication and migration requirements
To: Brent
Cc: nfsv4-wg@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3B815D2F.DC44BDD8@eng.sun.com>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> Yes, if you want to make three 9's availability a requirement for
> this protocol, then you have to move the lock and lease state.
>
> But if it becomes a requirement, then the result will be
> a protocol so complex to implement, that nobody will do it.
It is far from obvious to me that trying to migrate state will
result in an unimplementable mess. Surely it's worth some
thought experiments before we limit ourselves to tackling a
replication protocol only?
Rob T
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 20 18:21:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05776
for ; Mon, 20 Aug 2001 18:21:11 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16711;
Mon, 20 Aug 2001 15:21:45 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28436;
Mon, 20 Aug 2001 15:20:53 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged))
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KMKQL07782
for ; Mon, 20 Aug 2001 15:20:26 -0700 (PDT)
Received: from peyto (vpn-129-147-152-129.Central.Sun.COM [129.147.152.129])
by jurassic.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with SMTP id f7KMKOG606062;
Mon, 20 Aug 2001 15:20:24 -0700 (PDT)
Date: Mon, 20 Aug 2001 16:20:55 -0600 (MDT)
From: Robert Thurlow
Reply-To: Robert Thurlow
Subject: Re: Replication and migration requirements
To: Uresh Vahalia
Cc: nfsv4-wg@sunroof.eng.sun.com
In-Reply-To: "Your message with ID" <3B7DEB27.53BBCA8B@emc.com>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
> It is hard to imagine that heterogenous file system replication is a real
> customer need, although you will always find the bleeding edge guys who
> absolutely must have it. It could be a very exciting technology to develop,
> but commercially it is likely to be a solution looking for a problem.
Our customers regularly tell us (sometimes loudly and colourfully)
that we can't just put things into Solaris - that we need to make
sure the stuff we do is also available on other vendors' systems.
That's what makes me believe that heterogenous replication and
migration is worth doing. Whether there are enough interested
vendors to make this viable, and enough customer demand that it
matters once built, I don't know. Do you believe your customers
would not care about a heterogeneous transfer protocol?
> Migrating an entire file system is useful, but often not good enough. The
> ability to specify which parts of the file system should be migrated makes
> this extremely powerful and useful.
From my past with AFS, I was used to people using volumes which
were the right size, so that policy set on the volume would be
fine. My home directory was a volume, not a subdirectory on a
huge filesystem like it is now. Clearly, if you are forced by
a shortage of LUNs or partition slots to share huge filesystems,
a finer-grained policy is desireable, but it seems like it could
be just a workaround. I know we're working to permit right-sized
partitions so a per-filesystem policy is more correct. Do you
have an example that shows this as more generally useful?
> > Right now, we haven't been talking much about how resource info
> > is "published" so that clients can know about it. It is clearly
> > important, and customers have BIG complaints that this is not
> > standardized, leaving them to manage more islands of functionality.
> Whether part of replication this effort or not, this is a key feature that
> solves some important customer problems.
...
> Let us assume a server vendor (or cooperating vendors) has a server
> replication solution with one writer and one or more readers. Assume
> further that this solution has the ability to switch the writer role from
> one server to another, perhaps instantly. To make this useful, clients need
> a way of knowing (a) the number of replicas and their location, (b) which
> one of them is writable, and (c) any change in this configuration.
Agreed here; I'd love to see this more standardized. Do others on
the alias want to see us work to solve this?
> Finally, why does migration require ANY protocol support beyond regular NFS?
> Even v3 should work just fine.
This is a good question; in answering, I've been hitting some
some assumptions that a separate protocol can be faster and more
able to pare down transferred data to a minumum. While I still
think a protocol which uses XDR structures over a TCP connection
could be faster, that's not necessarily true.
If we have a module which can bypass any block boundaries and
sizes, and which has either the ability to get precise lists of
changes from the shared filesystem or the ability to calculate
this with rsync, we can do very well. But we can't get a couple
of things I think are important.
Without a seperate protocol, state migration can't happen, so
truly seamless migration is not possible; the client/server
protocol has no op for this nor a need for such an op. And
management of the transfer seems impossible without some kind
of out-of-band way to control the process, e.g. to reserve a
partition for a new replica, or to inform a peer that we're
done sending data. So I think that even if we used NFS ops to
transfer most data and metadata, we need something more.
Rob T
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 20 18:28:18 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05975
for ; Mon, 20 Aug 2001 18:28:17 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04045;
Mon, 20 Aug 2001 16:28:41 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29990;
Mon, 20 Aug 2001 15:28:20 -0700 (PDT)
Received: from athyra.eng.sun.com (athyra [129.146.85.90])
by sunroof.eng.sun.com (8.11.6.Beta0+Sun/8.11.6.Beta0) with ESMTP id f7KMS9L07815
for ; Mon, 20 Aug 2001 15:28:09 -0700 (PDT)
Received: from athyra (localhost [127.0.0.1])
by athyra.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f7KMRqL848349;
Mon, 20 Aug 2001 15:27:52 -0700 (PDT)
Message-Id: <200108202227.f7KMRqL848349@athyra.eng.sun.com>
To: "Noveck, Dave"
cc: "'nfsv4-wg@sunroof.eng.sun.com'" ,
"Roa, Guillermo"
Subject: Re: special stateids (was "LOOKUP vs OPEN in NFSV4")
In-reply-to: Your message of "Thu, 16 Aug 2001 06:52:19 PDT."
<8C610D86AF6CD4119C9800B0D0499E3333558E@red.nane.netapp.com>
Mime-Version: 1.0 (generated by tm-edit 1.7)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 20 Aug 2001 15:27:51 -0700
From: Mike Kupfer
>>>>> "DN" == Noveck, Dave writes:
DN> The server is implementing mandatory locking (for all files or
DN> for particular files, such as those with some mode bit set).
DN> I guess you could say that the fact that it doesn't completely
DN> ignore mandatory locking on such IO requests "allows mandatory
DN> locking to be implemented" but that just seems an odd way to
DN> describe the fact that this form of IO, like others, obeys the
DN> constraints of mandatory locking.
I think the point was to contrast with the Unix advisory locking
model, where the client first obtains locks that cover the I/O region
and then does the I/O.
DN> As I understand the spec now, if we leave aside special
DN> stateid's (and non-V4 clients and local access...), share
DN> locks are inherently mandatory while it is up to the server to
DN> decide whether byte-range locks have mandatory effect (and the
DN> server could do it for some files based on mode bits or
DN> whatever). Is that everybody else's understanding?
That's my understanding.
DN> But providing a way a for one client to ignore another
DN> client's mandatory locks isn't advisory locking. It's
DN> something different and kind of scary.
What would you say then is the difference between the current spec and
advisory locking?
>> So, to answer Dave's question, I think that the current text in
>> Section 8.1.4 should be changed. A READ with an all-1 stateid
>> should bypass both record locks and share reservations, and a
>> WRITE with an all-1 stateid is equivalent to a WRITE with an
>> all-0 stateid.
DN> "should bypass" as opposed to "must bypass"!
Right.
Though it just occurred to me that extending the special all-1
stateid to share reservations may not make much of a difference, since
share reservations are primarily enforced on OPEN, not READ/WRITE, and
OPEN doesn't take any magic stateids.
DN> Generally, the poeple who complain about Windows locks
DN> stopping them from accessing a file are complaining about
DN> share reservations rather than record (i.e. byte-range)
DN> locks.
Well, that, combined with my observation above about OPEN, implies
that the all-1's stateid will be of limited usefulness.
DN> my preference would be to avoid two different
DN> ways of doing the same thing. I would rather allow:
DN> Read with all-0: Normal READ with no locks or opens.
DN> Subject (of course) to mandatory locking.
DN> Write with all-0: Normal WRITE with no locks or opens.
DN> Subject (of course) to mandatory locking.
DN> Read with all-1: Special READ which bypasses locking
DN> checks, and thus an exception to mandatory locking, if the
DN> server supports the exception.
DN> And make invalid:
DN> Write with all-1: Invalid since a WRITE which bypasses
DN> locking checks is too horrible to contemplate (for long).
That's okay with me.
I'm debating with myself whether to propose any significant changes in
this area (e.g., removal of the magic stateids, or changing OPEN so
that servers may ignore deny=read under some circumstances). But none
of the changes I've thought of is compellingly superior to the current
spec, so I'm inclined to leave things pretty much as they are.
I will suggest that servers be allowed to reject deny=read OPENs if
the requestor only has read access to the file in the first place.
Also, as long as I'm thinking about share reservations, did the WG
ever discuss the Windows semantics where having a file open keeps the
file from being renamed or deleted? My reading of RFC 3010 is that v4
share reservations do not keep the file from being renamed or
deleted. Is that everyone's understanding?
DN> I think it would help if we added the following text
DN> at the end of the fifth paragraph of section 8.5.2.
DN> READs with a stateid of all-ones, must also return
DN> NFS4ERR_GRACE, even though such READs bypass locking
DN> checks, unless the server can determine that no reclaims of
DN> delegations can possibly occur.
Fifth paragraph or fourth paragraph?
I wouldn't bother mentioning the locking bypass here. I'd just say
something like
Note that a stateid of all-ones does not provide any special
exceptions for READ requests. The server must reject such
requests with NFS4ERR_GRACE unless it can determine that no
reclaims of conflicting delegations can possibly occur.
mike
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 20 19:41:40 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07547
for ; Mon, 20 Aug 2001 19:41:39 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA15791;
Mon, 20 Aug 2001 16:42:23 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA14099;
Mon, 20 Aug 2001 16:41:40 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged))
by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7KNfPm08067
for ; Mon, 20 Aug 2001 16:41:25 -0700 (PDT)
Received: from eng.sun.com (awe195-188.AWE.Sun.COM [192.29.195.188])
by jurassic.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7KNfIk629376
for ; Mon, 20 Aug 2001 16:41:18 -0700 (PDT)
Sender: Brent.Callaghan@eng.sun.com
Message-ID: <3B819F2F.16012997@eng.sun.com>
Date: Mon, 20 Aug 2001 16:37:19 -0700
From: Brent
Organization: NFS Whackers
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Robert Thurlow wrote:
>
> > Yes, if you want to make three 9's availability a requirement for
> > this protocol, then you have to move the lock and lease state.
> >
> > But if it becomes a requirement, then the result will be
> > a protocol so complex to implement, that nobody will do it.
>
> It is far from obvious to me that trying to migrate state will
> result in an unimplementable mess. Surely it's worth some
> thought experiments before we limit ourselves to tackling a
> replication protocol only?
I've no objection to thought experiments, but we need to focus
on basic file-level data replication first. If we can't come
up with a simple protocol that's scalable and efficient, then
the game's over.
We need to prioritize the requirements list. Then we can
decide which features are near the bottom, and likely to
fall off.
Brent
From nfs4-wg-request@sunroof.eng.sun.com Mon Aug 20 20:48:59 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08448
for ; Mon, 20 Aug 2001 20:48:59 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA04627;
Mon, 20 Aug 2001 17:49:48 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25363;
Mon, 20 Aug 2001 17:48:53 -0700 (PDT)
Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged))
by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L0mfm08346
for ; Mon, 20 Aug 2001 17:48:41 -0700 (PDT)
Received: from eng.sun.com (awe195-188.AWE.Sun.COM [192.29.195.188])
by jurassic.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L0mdk648097
for ; Mon, 20 Aug 2001 17:48:39 -0700 (PDT)
Sender: Brent.Callaghan@eng.sun.com
Message-ID: <3B81AEF7.7E62413F@eng.sun.com>
Date: Mon, 20 Aug 2001 17:44:39 -0700
From: Brent
Organization: NFS Whackers
X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.8 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References:
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Robert Thurlow wrote:
> > Let us assume a server vendor (or cooperating vendors) has a server
> > replication solution with one writer and one or more readers. Assume
> > further that this solution has the ability to switch the writer role from
> > one server to another, perhaps instantly. To make this useful, clients need
> > a way of knowing (a) the number of replicas and their location, (b) which
> > one of them is writable, and (c) any change in this configuration.
>
> Agreed here; I'd love to see this more standardized. Do others on
> the alias want to see us work to solve this?
Well, the Service Location Protocol provides a great infrastructure
for developing this kind of capability. Replica location is necessary,
but in this context it's a distraction. We should draw a clean boundary
between the mechanics of moving/replicating data - and naming it.
Customers already have mechanisms for replicating data that are
separate from how they name it. I think we should maintain this
flexibility.
Uresh Vahalia wrote:
> Finally, why does migration require ANY protocol support beyond regular NFS?
> Even v3 should work just fine.
NFS is not designed to move large amounts of data/metadata efficiently.
For instance, you'll move a file collection much more quickly in a
tar or zip file over FTP than a "copy -r" over NFS.
Neither does NFS have any efficient way to ask a server for a list
of files or directories that need to be updated.
Brent
From nfs4-wg-request@sunroof.eng.sun.com Tue Aug 21 00:51:12 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13533
for ; Tue, 21 Aug 2001 00:51:11 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA24128;
Mon, 20 Aug 2001 21:51:38 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07091;
Mon, 20 Aug 2001 21:50:55 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L4okm09429
for ; Mon, 20 Aug 2001 21:50:46 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA05199
for ; Mon, 20 Aug 2001 21:50:48 -0700 (PDT)
From: shdf@msn.com
Received: from um.grudziadz.pl ([212.160.232.137])
by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24508
for ; Mon, 20 Aug 2001 21:50:47 -0700 (PDT)
Received: from 209.205.162.115 (ppp363-nosp3.i-55.com [209.205.162.115])
by um.grudziadz.pl (8.8.8/8.8.8) with SMTP id HAA02862;
Tue, 21 Aug 2001 07:56:50 +0200
Message-Id: <200108210556.HAA02862@um.grudziadz.pl>
To: pwrc@msn.com
Subject: Do You Accept Credit Cards?
Date: Tue, 21 Aug 01 00:42:36 Atlantic Daylight Time
X-Priority: 3
X-MSMailPriority: Normal
Importance: Normal
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_018C_01BD9940.715D52A0"
This is a multi-part message in MIME format.
------=_NextPart_000_018C_01BD9940.715D52A0
Content-Type: text/html;
ACCEPT ALL MAJOR CREDIT CARDS
START INCREASING SALES TODAY
INTERNET MERCHANTS, RETAIL STORES OR MAIL
ORDER/TELEPHONE ORDER MERCHANTS.
98% OF OUR APPLICANTS ARE ACCEPTED!!
TERMINALS & PRINTERS OR PROCESS
DIRECTLY THROUGH YOUR WEB SITE OR P.C.
0 DOWN W/GOOD CREDIT,
BAD CREDIT HISTORY? NO PROBLEM!
NO APPLICATION OR SETUP FEE WITH THIS AD.
LOWEST RATES, LOW MONTHLY PAYMENTS
SUPER QUICK APPROVAL AND SET UP!!
REAL TIME SECURE PROCESSING FROM YOUR
WEB SITE OR PHYSICAL STORE FRONT
INCREASE SALES BY UP TO 300%!!
CALL NOW!! 800-474-9698
------=_NextPart_000_018C_01BD9940.715D52A0--
From nfs4-wg-request@sunroof.eng.sun.com Tue Aug 21 02:54:08 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01130
for ; Tue, 21 Aug 2001 02:54:08 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11559;
Tue, 21 Aug 2001 00:49:46 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01666;
Mon, 20 Aug 2001 23:49:11 -0700 (PDT)
Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5])
by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7L6mxm09581;
Mon, 20 Aug 2001 23:48:59 -0700 (PDT)
Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01650;
Mon, 20 Aug 2001 23:49:00 -0700 (PDT)
Received: from dbserver.chinakids.net.cn ([210.192.111.52])
by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05018;
Tue, 21 Aug 2001 00:49:16 -0600 (MDT)
Received: from yg.mx.aol.com [63.208.231.2] by dbserver.chinakids.net.cn
(SMTPD32-6.04) id AEE339F1012E; Tue, 21 Aug 2001 11:00:51 +0800
Reply-To:
From: "Cybershark@aol.com"
To: "7777@aol.com" <7777@aol.com>
Subject: Lightspeed Mailing Report 1277496:-795447016:1510:Stargate:1510!
Content-Type: text/plain; charset="us-ascii";format=flowed
Content-Transfer-Encoding: 7bit
Message-Id: <200108211101203.SM00251@yg.mx.aol.com>
Date: Tue, 21 Aug 2001 14:49:16 +0800
Content-Transfer-Encoding: 7bit
08/20/01 19:27:38
Cybershark User: Stargate
Addresses To Send: 195050
Confirmed Deliveries: 1277496
From nfs4-wg-request@sunroof.eng.sun.com Tue Aug 21 07:19:43 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04703
for ; Tue, 21 Aug 2001 07:19:42 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01506;
Tue, 21 Aug 2001 05:20:29 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27349;
Tue, 21 Aug 2001 04:19:48 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LBJMm11355
for ; Tue, 21 Aug 2001 04:19:22 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA12991
for ; Tue, 21 Aug 2001 04:19:23 -0700 (PDT)
From: sales@seebex.com
Received: from rafi ([213.8.76.34])
by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11903
for ; Tue, 21 Aug 2001 04:19:20 -0700 (PDT)
Received: from mail pickup service by rafi with Microsoft SMTPSVC;
Tue, 21 Aug 2001 14:12:06 +0200
To:
Subject: Instant Messaging platform at your Web site is now a few clicks away
Date: Tue, 21 Aug 2001 14:12:06 +0200
Message-ID: <11f901c12a3a$7e64ce90$0200a8c0@rafi>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Mailer: Microsoft CDO for Windows 2000
Thread-Index: AcEqOn5kEoIDmH4jT7+/hywIp0FiNA==
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-OriginalArrivalTime: 21 Aug 2001 12:12:06.0149 (UTC) FILETIME=[7E7A2B50:01C12A3A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA04703
Instant Messaging platform at your Web site is now a few clicks away
----------------------------------------------------------------------
Install a FREE Instant Messaging server at your Web site.
Use it as is or customize to meet your specific branding.
Cross platform servers line support 25 and up to 1000 concurrent users
All servers offered can be secured with RSA 512Bit (and higher) encryption!!
Download free 10 concurrent users server at:
http://www.seebex.com/download/get_server.asp
It is easier, faster and affordable than ever!!
For further information please check seebex Web site at: http://www.seebex.com
or contact our Marketing & Sales department at sales@seebex.com
First 50 Web sites to download and embed the free 10 concurrent users server
are entitled to a free 100 concurrent users server
and will be listed on Seebex Web site.
From nfs4-wg-request@sunroof.eng.sun.com Tue Aug 21 08:05:09 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06714
for ; Tue, 21 Aug 2001 08:05:08 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28147;
Tue, 21 Aug 2001 06:05:53 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15539;
Tue, 21 Aug 2001 05:05:34 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LC5Jm11492;
Tue, 21 Aug 2001 05:05:20 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16357;
Tue, 21 Aug 2001 05:05:20 -0700 (PDT)
Received: from tiamat.info-boutique.com (tiamat.info-boutique.com [207.253.87.34])
by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27683;
Tue, 21 Aug 2001 05:05:18 -0700 (PDT)
Message-Id: <200108211205.FAA27683@venus.sun.com>
Received: from CX1136893-A ([12.64.42.124]) by tiamat.info-boutique.com
(post.office MTA v2.0 0813 ID# 0-12500) with ESMTP id AAA248;
Tue, 21 Aug 2001 08:03:59 -0400
From: " 4 Tony c"
Subject: 41 Great Mortgage Rates!!!
To: <#field0#@venus.sun.com>
Date: Mon, 21 May 2001 01:46:29 -0700
X-Mailer: Mozilla 4.05 [en] (Win95; I)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA06714
kuytd
Whether a new home loan is what you seek or to refinance
your current home loan at a lower interest rate, we can help!
Mortgage rates haven't been this low in the last 12 months,
take action now!
Refinance your home with us and include all of those pesky
credit card bills or use the extra cash for that pool you've
always wanted...
Where others say NO, we say YES!!!
Even if you have been turned down elsewhere, we can help!
Easy terms! Our mortgage referral service combines the
highest quality loans with the most economical rates and
the easiest qualifications!
Take just 2 minutes to complete the following form.
There is no obligation, all information is kept strictly
confidential, and you must be at least 18 years of age.
Service is available within the United States only.
This service is fast and free.
Free information request form:
PLEASE VISIT
http://www.1xin.net/mortgagezone
****************************************************************
Since you have received this message you have either responded
to one of our offers in the past or your address has been
registered with us. If you wish to be removed please reply to:
mailto:mailer8654@yahoo.com?subject=remove
****************************************************************
potyd4
From nfs4-wg-request@sunroof.eng.sun.com Tue Aug 21 08:13:33 2001
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07266
for ; Tue, 21 Aug 2001 08:13:33 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04190;
Tue, 21 Aug 2001 06:14:22 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16235;
Tue, 21 Aug 2001 05:14:04 -0700 (PDT)
Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6])
by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LCDvm11550
for ; Tue, 21 Aug 2001 05:13:57 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16981
for ; Tue, 21 Aug 2001 05:13:54 -0700 (PDT)
Received: from server.conradcairo.com.eg (host-213-131-70-110.link.net [213.131.70.110])
by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02240;
Tue, 21 Aug 2001 05:13:47 -0700 (PDT)
Received: by server.conradcairo.com.eg from localhost
(router,SLMail V3.2); Tue, 21 Aug 2001 13:20:55 +0300
Received: from CX1136893-A [12.64.42.124]
by server.conradcairo.com.eg [10.152.82.251] (SLmail 3.2.3113) with ESMTP
id A3D0CD9D8FAE11D598D20008C78CDFEE
for plus 19 more; Tue, 21 Aug 2001 13:20:37 0300
From: " 4 Tony c"
Subject: 41 Great Mortgage Rates!!!
To: #field0#@conradcairo.com.eg
Date: Mon, 21 May 2001 01:46:29 -0700
X-Mailer: Mozilla 4.05 [en] (Win95; I)
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Message-id: <20010821132055.a3d0cd9d8fae11d598d20008c78cdfee.in@server.conradcairo.com.eg>
X-SLUIDL: 5F8B26A6-95AB11D5-98D20008-C78CDFEE
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA07266
kuytd
Whether a new home loan is what you seek or to refinance
your current home loan at a lower interest rate, we can help!
Mortgage rates haven't been this low in the last 12 months,
take action now!
Refinance your home with us and include all of those pesky
credit card bills or use the extra cash for that pool you've
always wanted...
Where others say NO, we say YES!!!
Even if you have been turned down elsewhere, we can help!
Easy terms! Our mortgage referral service combines the
highest quality loans with the most economical rates and
the easiest qualifications!
Take just 2 minutes to complete the following form.
There is no obligation, all information is kept strictly
confidential, and you must be at least 18 years of age.
Service is available within the United States only.
This service is fast and free.
Free information request form:
PLEASE VISIT
http://www.1xin.net/mortgagezone
****************************************************************
Since you have received this message you have either responded
to one of our offers in the past or your address has been
registered with us. If you wish to be removed please reply to:
mailto:mailer8654@yahoo.com?subject=remove
****************************************************************
potyd4
From nfs4-wg-request@sunroof.eng.sun.com Tue Aug 21 12:29:55 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22891
for ; Tue, 21 Aug 2001 12:29:54 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA11053;
Tue, 21 Aug 2001 09:30:11 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28337;
Tue, 21 Aug 2001 09:28:55 -0700 (PDT)
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25])
by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7LGSgm14374
for ; Tue, 21 Aug 2001 09:28:42 -0700 (PDT)
Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27754;
Tue, 21 Aug 2001 09:28:43 -0700 (PDT)
Received: from emc.com (emcmail.lss.emc.com [168.159.48.78])
by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23693;
Tue, 21 Aug 2001 10:28:38 -0600 (MDT)
Received: from emc.com ([172.25.208.114])
by emc.com (8.10.1/8.10.1) with ESMTP id f7LGSeP14257;
Tue, 21 Aug 2001 12:28:41 -0400 (EDT)
Message-ID: <3B17E5A4.E544593E@emc.com>
Date: Fri, 01 Jun 2001 14:57:40 -0400
From: Uresh Vahalia
Organization: EMC Corporation
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Brent
CC: nfsv4-wg@sunroof.eng.sun.com
Subject: Re: Replication and migration requirements
References: <3B81AEF7.7E62413F@eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Brent wrote:
> Robert Thurlow wrote:
> > > Let us assume a server vendor (or cooperating vendors) has a server
> > > replication solution with one writer and one or more readers. Assume
> > > further that this solution has the ability to switch the writer role from
> > > one server to another, perhaps instantly. To make this useful, clients need
> > > a way of knowing (a) the number of replicas and their location, (b) which
> > > one of them is writable, and (c) any change in this configuration.
> >
> > Agreed here; I'd love to see this more standardized. Do others on
> > the alias want to see us work to solve this?
>
> Well, the Service Location Protocol provides a great infrastructure
> for developing this kind of capability. Replica location is necessary,
> but in this context it's a distraction. We should draw a clean boundary
> between the mechanics of moving/replicating data - and naming it.
>
> Customers already have mechanisms for replicating data that are
> separate from how they name it. I think we should maintain this
> flexibility.
True. The two are somewhat separate problems. However, the naming problem, which
includes what view a client has of a replicated environment, will have a strong
influence on any server-to-server replication/migration solution/protocol, since the
latter will have to meet the expectations of the former.
>
>
> Uresh Vahalia wrote:
> > Finally, why does migration require ANY protocol support beyond regular NFS?
> > Even v3 should work just fine.
>
> NFS is not designed to move large amounts of data/metadata efficiently.
>
> For instance, you'll move a file collection much more quickly in a
> tar or zip file over FTP than a "copy -r" over NFS.
>
> Neither does NFS have any efficient way to ask a server for a list
> of files or directories that need to be updated.
>
> Brent
From nfs4-wg-request@sunroof.eng.sun.com Wed Aug 22 00:39:19 2001
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09008
for ; Wed, 22 Aug 2001 00:39:18 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA07164;
Tue, 21 Aug 2001 21:39:57 -0700 (PDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88])
by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA11327;
Tue, 21 Aug 2001 21:39:37 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13])
by sunroof.eng.sun.com (8.11.6+Sun/8.11.6) with ESMTP id f7M4dTm19117
for ; Tue, 21 Aug 2001 21:39:29 -0700 (PDT)
Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2])
by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA20881
for