From rwzangelic@interptr.com Sun Jul 01 01:04:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4rbo-0002Tu-66 for nfsv4-archive@lists.ietf.org; Sun, 01 Jul 2007 01:04:28 -0400 Received: from 71-8-203-200.dhcp.stls.mo.charter.com ([71.8.203.200] helo=interptr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I4rbn-0008PT-SE for nfsv4-archive@lists.ietf.org; Sun, 01 Jul 2007 01:04:28 -0400 Message-ID: <001701c7bb73$26c13d60$0180ddcc@ANGELAFOSTER> From: "Clinton Ivey" To: "nfsv4-archive" Subject: Re: Thank you, we are accepting your loan request Date: Sun, 1 Jul 2007 00:01:35 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C7BB73.26C13D60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.2969 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.2969 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c ------=_NextPart_000_0014_01C7BB73.26C13D60 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Your your credit report does not matter to us! If you OWN real estate and want IMMEDIATE money to spend ANY way you = like, or simply need to LOWER your current payments by a third or more, = here is our best deal we can offer you THIS EVENING (hurry, this offer = will expire THIS EVENING): $341,000+ debt AND EVEN MORE: After further review, our lenders have set the lowest = current payments! Hurry, when best deal is gone, it is gone. Simply fill out this quick = form... Don't worry about approval, your your credit report will not disqualify = you! http://planzxtranes.com/ ------=_NextPart_000_0014_01C7BB73.26C13D60 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Your credit doesn't = matter to us!
 
If your family OWN real = estate and want IMMEDIATE cash to spend ANY way you like, or simply wish = to LOWER your entire payment by a third or more, here is the deal we can = offer you THIS EVENING (hurry, this offer will expire = TONIGHT):
 
$200,000+ = loan
 
AND EVEN MORE: After = further review, our lenders have set the lowest current = payments!
 
Hurry, when our best = deal is gone, it is gone. Simply finish this user-friendly form... =
 
Do not worry about = approval, your your credit report will not disqualify you!
 
http://planzxtranes.com/
------=_NextPart_000_0014_01C7BB73.26C13D60-- From jzisn@usaadultdirectory.com Sun Jul 01 08:13:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4yJ9-00011Y-Eq for nfsv4-archive@lists.ietf.org; Sun, 01 Jul 2007 08:13:39 -0400 Received: from user216-178-73-62.netcarrier.net ([216.178.73.62]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4yIK-00048x-6c for nfsv4-archive@lists.ietf.org; Sun, 01 Jul 2007 08:13:39 -0400 Received: from jtsz ([86.184.107.110]) by user216-178-73-62.netcarrier.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 1 Jul 2007 08:13:45 -0500 Message-ID: <4687A889.2070007@usaadultdirectory.com> Date: Sun, 1 Jul 2007 08:13:45 -0500 From: Joachim K. Kramer User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: Millions of dollars annually is diverted or recovered from Criminal Activities directly related to Crime Stopper programs. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e ERMX Gets into Nitride Devices! Applications Are Amazing! EntreMetrix Inc. (ERMX) $0.16 Nitride Wafers are the next level in super technology. From Super Energy Conductors to Nano-Lasers used in microscopic surgery. ERMX is moved into a joint venture to manufacture Nitride devices out of China. This is huge get on ERMX Monday! Will this trend catch on in the states? After the wires are soldered, trim the pins back so there won't be anything to keep your reader from butting up against the faceplate. However, some confusion exists as to exactly which types of technologies, if passed, the amendment would require. TipSoft was without a method, short of re-entering the data, of capturing the old data. NCR Division AcquiredNCR's Systemedia Division's RFID assets have been acquired by The Kennedy Group, who provide RFID labels, packaging and other products. Now, if you've done this right, you should be able to test the lock. If you have a large dog the door can be wide enough for a squirrelly burglar or other unwanted animals. You might encounter a "Smart Mirror" in that dressing room by the end of this year. What information is to be shared can be configured on a per subscriber basis. Computer Logon: With security being a big issue these days, new and innovative ways to secure your data and workstation are always a welcome addition to your tech repertoire. After the wires are soldered, trim the pins back so there won't be anything to keep your reader from butting up against the faceplate. New Passport Protection Industry: Although the U. It can also be modified to automatically shut the door after a certain period of time or when the car reaches a certain distance from the house. You can now finish up by putting the carrier board in your remaining project box. You'll probably get one with an embedded RFID chip and a warning to be careful with the "sensitive electronics" it contains. TextPipe provides a single point of maintenance for all text processing tasks. Trim the plastic off at this spot, much like you did for the faceplate, to keep your wires from getting smashed. AskSam, TextPipe and Crime Stoppers Home Buy Now Solutions Systems Integration Content Management Data Conversion Data Mining More. TextPipe teamed with askSam has proved to be another excellent tool to help Crime Stoppers extend the value of their tip taking services. government's unwillingness to protect consumers, the Senate is all over the ability to track students through the use of implantation or RFID cards. This should cause the system to spring to life and unlock the deadbolt. Another new development is the RFID Guardian, essentially a firewall that can prevent or allow RFID queries, and can do so on a per-tag basis. This is where you'll get to put together all your little electronic components. One of the simplest ways to implement RFID to your computer is to use a simple USB system like PCProx. Then you tell it which files to process - that's it! Once it's programmed you'll need to insert it into the carrier board. The easiest way to do this is to buy a microprocessor that can be hooked up to your computer for easy programming. The guests at this resort use RFID-enabled wristbands for identification and point-of-sale purchases. If you can't pay for the convenience of a full installation, you can install a simpler system on your own. TextPipe handles structured and unstructured reports, Mainframe files, delimited and fixed-width data, HTML and XML, spooled print files and text files of any size and dimension. The system isn't free from drawbacks, however. The stores can examine quickly which movies are sold out and replenish them quickly, rather than wait for staff to provide inventory. Arrest and prosecution leads to a safer community for us all by removing criminals from our streets and providing strong deterrents for crime. To connect this to your RFID reader, solder the VCC lead wire from the reader to the output pin on the voltage regulator. Be advised that many of these projects do require a certain degree of skill or knowledge about electronics and circuitry, or at least the ability to follow directions very carefully. TextPipe saved HOURS of manual editing and was able to accomplish massive improvements quickly with its easy to use interface. The RFID safe is assembled in a similar way to the other RFID locking systems. This information can now be provided to law enforcement as 'additional potentially related' information to augment the original tip. If you're looking for a cheaper DIY way of hooking up your door with RFID it'll take some elbow grease and a few small components. New Passport Protection Industry: Although the U. RFID chips and cards can replace these conventional items and give your home a more futuristic and unarguably cooler feel. TextPipe provides a single point of maintenance for all text processing tasks. "We are very excited and proud to win this award. Supposedly there are safeguards, but since you can just "tap" your phone at, say, a cashless vending machine, I don't see how that'd stop a thief. Other vendors are including it in their solutions. The Food Channel should worry. From nfsv4-bounces@ietf.org Sun Jul 01 11:00:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I50u2-0002PQ-AM; Sun, 01 Jul 2007 10:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I50u1-0002PK-EH for nfsv4@ietf.org; Sun, 01 Jul 2007 10:59:53 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I50tx-0005XN-1s for nfsv4@ietf.org; Sun, 01 Jul 2007 10:59:53 -0400 X-IronPort-AV: E=Sophos;i="4.16,483,1175497200"; d="scan'208";a="77653060" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 01 Jul 2007 07:59:46 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l61Exjsk023758; Sun, 1 Jul 2007 07:59:45 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Jul 2007 07:59:45 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Jul 2007 07:59:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] An issue regarding free byte-range lock state Date: Sun, 1 Jul 2007 10:59:43 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] An issue regarding free byte-range lock state Thread-Index: Ace6dhYDWvTUT9baSCaGyJA2dtW61AAGr4yQAFdwV3A= From: "Noveck, Dave" To: "Peter Varga" , "Spencer Shepler" , X-OriginalArrivalTime: 01 Jul 2007 14:59:45.0351 (UTC) FILETIME=[763B9570:01C7BBF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I'm conivnced we need OLD_STATEID is some cases. The=20 cases where we need it are on CLOSE and OPEN_DOWNGRADE=20 to deal with the possibility of a pending OPEN of a hard link. On the other hand there doesn't seem to be much point on OLD_STATEID on READ, WRITE, LOCK. If you are returning OLD_STATEID in those cases, you are forcing retry to give the server the stateid-sequence without much point. The server has the other part and can check the current state regardless of the stateid sequence. So here is a proposal: The server always sets sequence in the stateid and the client can look at it, if it wants. When sending a stateid, the client may sent the latest seqid or zero, as a wild-card. Zero is always accepted but if a non-zero value is sent it must be the correct one to be accepted (if it is too high BAD_STATEID, and too low OLD_STATEID). The recommendation is that clients will=20 typically send the seqid on CLOSE and OPEN_DOWNGRADE for the resons demonstrated by Peter's example. On the other hand, if they only have one outstanding request per owner, they don't have to do this and are OK sending zero as the seqid. -----Original Message----- From: Peter Varga [mailto:pvarga@opentext.com]=20 Sent: Friday, June 29, 2007 5:09 PM To: Spencer Shepler; nfsv4@ietf.org Subject: RE: [nfsv4] An issue regarding free byte-range lock state > -----Original Message----- > From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM] >=20 > If the client choose to have more than one outstanding=20 > OPEN/OPEN_DOWNGRADE/CLOSE for an open_owner, then the seqid is=20 > required. Because of hard-links, there are issues of OPEN upgrade=20 > given that NFSv4 requires that downgrade be done in the opposite=20 > pattern from upgrade; this means the client needs to know the ordering > of the state changing operations. Then there is the race between=20 > OPEN/CLOSE that can occur, again in the presence of hard-links. >=20 > Spencer >=20 I see. In that case, we still need the OLD_STATEID error (spec says " This error does not apply to and should never be generated in NFSv4.1.") Consider: - link1 =3D link2 =3D hard links - stateid1 and stateid2 refer to the stateid in its entirety (seqid + other) - same open_owner If the server does _not_ increment stateid.seqid: client sends OPEN link1 client sends OPEN link2 server returns stateid1 in response to OPEN link1 client sends CLOSE stateid1 server returns stateid1 in response to OPEN link2 server closes stateid1 in response to CLOSE stateid1 client sends READ stateid1 server returns BAD_STATEID --> Problem! If the server increments stateid.seqid: client sends OPEN link1 client sends OPEN link2 server returns stateid1 in response to OPEN link1 client sends CLOSE stateid1 server returns stateid2 in response to OPEN link2 server returns OLD_STATEID in response to CLOSE stateid1 client figures out link1 and link2 are the same file and doens't resend the CLOSE _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Jul 01 13:05:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I52qE-0005Im-OM; Sun, 01 Jul 2007 13:04:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I52qC-0005Ia-PI for nfsv4@ietf.org; Sun, 01 Jul 2007 13:04:04 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I52q7-0006xm-US for nfsv4@ietf.org; Sun, 01 Jul 2007 13:04:04 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l61H3xiI029600 for ; Sun, 1 Jul 2007 17:03:59 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKI00K01FC8PJ00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Sun, 01 Jul 2007 11:03:59 -0600 (MDT) Received: from [192.168.0.3] (adsl-71-145-198-132.dsl.austtx.sbcglobal.net [71.145.198.132]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKI00ARRFEM5700@mail-amer.sun.com>; Sun, 01 Jul 2007 11:03:59 -0600 (MDT) Date: Sun, 01 Jul 2007 12:04:00 -0500 From: Spencer Shepler Subject: Re: [nfsv4] An issue regarding free byte-range lock state In-reply-to: To: "Noveck, Dave" Message-id: <471A7428-E98A-476A-85E5-2CE70E4A4742@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 1, 2007, at 9:59 AM, Noveck, Dave wrote: > I'm conivnced we need OLD_STATEID is some cases. The > cases where we need it are on CLOSE and OPEN_DOWNGRADE > to deal with the possibility of a pending OPEN of a > hard link. Agreed. > On the other hand there doesn't seem to be much point > on OLD_STATEID on READ, WRITE, LOCK. If you are returning > OLD_STATEID in those cases, you are forcing retry to > give the server the stateid-sequence without much > point. The server has the other part and can check the > current state regardless of the stateid sequence. Do we have a desire to provide fencing in the case of mandatory locks? I am thinking of the case that the client (or server) has made a mistake in its record keeping and there may be in-flight read/writes that don't match the mandatory file locking state. I don't have a strong opinion -- a slight preference for the stateid.seqid on read/write to provide for this. So, whatever everyone else wants. > So here is a proposal: The server always sets sequence > in the stateid and the client can look at it, if it wants. > When sending a stateid, the client may sent the latest > seqid or zero, as a wild-card. Zero is always accepted > but if a non-zero value is sent it must be the correct one > to be accepted (if it is too high BAD_STATEID, and too low > OLD_STATEID). The recommendation is that clients will > typically send the seqid on CLOSE and OPEN_DOWNGRADE > for the resons demonstrated by Peter's example. On the > other hand, if they only have one outstanding request > per owner, they don't have to do this and are OK sending > zero as the seqid. Yes. Spencer > > -----Original Message----- > From: Peter Varga [mailto:pvarga@opentext.com] > Sent: Friday, June 29, 2007 5:09 PM > To: Spencer Shepler; nfsv4@ietf.org > Subject: RE: [nfsv4] An issue regarding free byte-range lock state > > > >> -----Original Message----- >> From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM] >> >> If the client choose to have more than one outstanding >> OPEN/OPEN_DOWNGRADE/CLOSE for an open_owner, then the seqid is >> required. Because of hard-links, there are issues of OPEN upgrade >> given that NFSv4 requires that downgrade be done in the opposite >> pattern from upgrade; this means the client needs to know the >> ordering > >> of the state changing operations. Then there is the race between >> OPEN/CLOSE that can occur, again in the presence of hard-links. >> >> Spencer >> > > I see. In that case, we still need the OLD_STATEID error (spec says " > This error does not apply to and should never be generated in > NFSv4.1.") > > Consider: > > - link1 = link2 = hard links > - stateid1 and stateid2 refer to the stateid in its entirety (seqid + > other) > - same open_owner > > If the server does _not_ increment stateid.seqid: > client sends OPEN link1 > client sends OPEN link2 > server returns stateid1 in response to OPEN link1 client sends CLOSE > stateid1 server returns stateid1 in response to OPEN link2 server > closes > stateid1 in response to CLOSE stateid1 client sends READ stateid1 > server > returns BAD_STATEID --> Problem! > > If the server increments stateid.seqid: > client sends OPEN link1 > client sends OPEN link2 > server returns stateid1 in response to OPEN link1 client sends CLOSE > stateid1 server returns stateid2 in response to OPEN link2 server > returns OLD_STATEID in response to CLOSE stateid1 client figures out > link1 and link2 are the same file and doens't resend the CLOSE > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From loveserebu@so-net.ne.jp Mon Jul 02 05:53:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5IbO-0001ZC-WA for NFSV4-ARCHIVE@LISTS.IETF.ORG; Mon, 02 Jul 2007 05:53:51 -0400 Received: from [203.90.185.227] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5IbH-0002a7-IQ for NFSV4-ARCHIVE@LISTS.IETF.ORG; Mon, 02 Jul 2007 05:53:50 -0400 Received: from vgcccr5 (unknown [127.215.195.45]) by smtp63 (Coremail) with SMTP id eGF3ITe4f3NdSSYV.1 for ; Mon, 02 Jul 2007 17:53:46 +0800 (CST) X-Originating-IP: [127.215.195.45] Subject: =?iso-2022-jp?B?GyRCQmc/TSROPXdALRsoQg==?= From: =?shift-jis?B?eXVtZQ==?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C7A220.B709E280" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C7A220.B709E280 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 MzAbJEJCZSFBGyhCNjAbJEJCZSReJEchIkl9OS0kLyEiJD0kcyRKQmc/TSROPXdALSQsOSUkLSRK P00kS0ksOCskTiU1JSQlSCEqGyhCDQoNChskQjxjJCQ7UiRLSGYkWSQ/JGlCZz9NJE49d0AtJE8h Ik5pNTdANSQ3JCQkNyEiJTslQyUvJTkkTz5lPGokJCQ3ISJKODZnJEokNyEqGyhCDQoNChskQkJn P00kSj13QC0kLDklJC0kSj9NJEAkMSQ4JGMkSiQvISI2PUwjJCwkIiRrP00kSyRiQCdIcyEiMGxF WSRPR0EkJCRGJGIkaSQkJD8kJCEqGyhCDQoNChskQjxMPz9JVSQtJE4kNDZhPWo4ITp3JCwkIiRr JCskaSEiPCtKLCRLJVQlQyU/JWokSkt+Qi0kSj13QC0kLDgrJEQkMSRpJGwkXiQ5ISobKEINCg0K aHR0cDovL3NlcmVidS5iaXovY2FzLz9uZDEzMg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQobJEJHWz8uSVRNVxsoQg0K bWFraV9ub2RhMjFAeWFob28uY28udWs= ------=_NextPart_000_0006_01C7A220.B709E280 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjE4MCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj IiBzaXplPTI+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgDQpzaXplPTI+PFNUUk9O Rz4zMBskQkJlIUEbKEI2MBskQkJlJF4kRyEiSX05LSQvISIkPSRzJEpCZz9NJE49d0AtJCw5JSQt JEo/TSRLSSw4KyROJTUlJCVIISobKEI8L1NUUk9ORz48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxTVFJPTkc+PC9TVFJPTkc+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIA0Kc2l6ZT0yPjxTVFJPTkc+ GyRCPGMkJDtSJEtIZiRZJD8kaUJnP00kTj13QC0kTyEiTmk1N0A1JDckJCQ3ISIlOyVDJS8lOSRP PmU8aiQkJDchIko4NmckSiQ3ISobKEI8L1NUUk9ORz48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxTVFJPTkc+PC9TVFJPTkc+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIA0Kc2l6ZT0yPjxTVFJPTkc+ GyRCQmc/TSRKPXdALSQsOSUkLSRKP00kQCQxJDgkYyRKJC8hIjY9TCMkLCQiJGs/TSRLJGJAJ0hz ISIwbEVZJE9HQSQkJEYkYiRpJCQkPyQkISobKEI8L1NUUk9ORz48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxTVFJPTkc+PC9TVFJPTkc+PC9GT05U PiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIA0Kc2l6ZT0yPjxT VFJPTkc+GyRCPEw/P0lVJC0kTiQ0NmE9ajghOnckLCQiJGskKyRpISI8K0osJEslVCVDJT8laiRK S35CLSRKPXdALSQsOCskRCQxJGkkbCReJDkhKhsoQjwvU1RST05HPjwvRk9OVD48L0RJVj4NCjxE SVY+PFNUUk9ORz48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+PC9TVFJP Tkc+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxG T05UIGZhY2U9GyRCQVdCThsoQj48QSANCmhyZWY9Imh0dHA6Ly9zZXJlYnUuYml6L2Nhcy8/bmQx MzIiPmh0dHA6Ly9zZXJlYnUuYml6L2Nhcy8/bmQxMzI8L0E+PEEgDQpocmVmPSJodHRwOi8vZGVh aS5tcnNsb3ZlLmNvbS8/bmQxMzIiPjwvQT48QSANCmhyZWY9Imh0dHA6Ly93d3cuaXd4eXouY29t L2Nhcy8/bmQxMzIiPjwvQT48L0ZPTlQ+PEEgDQpocmVmPSJodHRwOi8vY2I0MDUuaXB0aW1lLm9y Zy9zZXJlYnUvP25kMTMyIj48U1RST05HPjwvU1RST05HPjwvQT48QlI+PEEgDQpocmVmPSJodHRw Oi8vY2I0MDIuYXRoLmN4L3NlcmVidS8/bmQxMzIiPjxTVFJPTkc+PC9TVFJPTkc+PC9BPjxCUj48 QSANCmhyZWY9Imh0dHA6Ly9qa2Vlai5jb20vP25kMTMyIj48L0E+PEEgaHJlZj0iIj48L0E+PEJS PjxBIA0KaHJlZj0iIj48L0E+PEJSPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iTVMg VUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJN UyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBm YWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxTVFJPTkc+PC9T VFJPTkc+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMi IHNpemU9Mj48U1RST05HPjwvU1RST05HPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PFNUUk9ORz48L1NUUk9ORz48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxTVFJPTkc+PC9T VFJPTkc+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMi IHNpemU9Mj48U1RST05HPjwvU1RST05HPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PFNUUk9ORz48L1NUUk9ORz48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxTVFJPTkc+PC9T VFJPTkc+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMi IHNpemU9Mj48U1RST05HPjwvU1RST05HPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PFNUUk9ORz48L1NUUk9ORz48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxTVFJPTkc+PC9T VFJPTkc+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMi IHNpemU9Mj48U1RST05HPjwvU1RST05HPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PFNUUk9ORz48L1NUUk9ORz48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxTVFJPTkc+PC9T VFJPTkc+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMi IHNpemU9Mj48U1RST05HPjwvU1RST05HPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PFNUUk9ORz48L1NUUk9ORz48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPjxTVFJPTkc+PC9T VFJPTkc+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMi IHNpemU9Mj48U1RST05HPhskQkdbPy5JVE1XGyhCPC9TVFJPTkc+PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48QSANCmhyZWY9IiI+PFNUUk9ORz5t YWtpX25vZGEyMUB5YWhvby5jby51azwvU1RST05HPjwvQT48L0RJVj48L0ZPTlQ+PC9GT05UPjwv RElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0006_01C7A220.B709E280-- From auc@rapattoni.com Mon Jul 02 12:40:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5OxE-0005MT-Up for nfsv4-archive@lists.ietf.org; Mon, 02 Jul 2007 12:40:48 -0400 Received: from dynamic-acs-24-239-43-154.zoominternet.net ([24.239.43.154]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5Ox8-00030E-N5 for nfsv4-archive@lists.ietf.org; Mon, 02 Jul 2007 12:40:48 -0400 Received: from olzfj.hdkde ([56.239.148.102]) by dynamic-acs-24-239-43-154.zoominternet.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Jul 2007 09:40:39 -0700 Message-ID: <001801c7bcc7$b8ed6d30$6694ef38@olzfj.hdkde> From: "MyPostcards.Com" To: Subject: You've received a greeting postcard from a worshipper! Date: Mon, 2 Jul 2007 09:40:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2578 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2578 X-Spam-Score: 1.9 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Good day. Your worshipper has sent you a greeting postcard from MyPostcards.Com. Send free ecards from MyPostcards.Com with your choice of colors, words and music. Your ecard will be available with us for the next 30 days. If you wish to keep the ecard longer, you may save it on your computer or take a print. To view your ecard, choose from any of the following options: -------- OPTION 1 -------- Click on the following Internet address or copy & paste it into your browser's address box. http://136.142.44.214/?e6c36a4bc955099675c5 -------- OPTION 2 -------- Copy & paste the ecard number in the "View Your Card" box at http://136.142.44.214/ Your ecard number is e6c36a4bc955099675c5 Best wishes, Mailer-Daemon, MyPostcards.Com From phukq@att.net Tue Jul 03 09:26:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5iOG-0006Z2-13 for nfsv4-archive@lists.ietf.org; Tue, 03 Jul 2007 09:26:00 -0400 Received: from [58.186.157.159] (helo=xftwt) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5iNy-0000li-1R for nfsv4-archive@lists.ietf.org; Tue, 03 Jul 2007 09:26:00 -0400 Received: from skqkc ([40.130.33.49]) by xftwt with Microsoft SMTPSVC(6.0.3790.0); Mon, 2 Jul 2007 20:32:42 +0700 Message-ID: <4688FE7A.1040706@ims-securities.com> Date: Mon, 2 Jul 2007 20:32:42 +0700 From: rifle User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: Announcement_49e1b9988.pdf attached Content-Type: multipart/mixed; boundary="------------030302070205050405080501" X-Spam-Score: 4.2 (++++) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 --------------030302070205050405080501 Content-Type: text/plain; charset=windows-1250; format=flowed Content-Transfer-Encoding: 7bit --------------030302070205050405080501 Content-Type: application/pdf; name="Announcement_49e1b9988.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Announcement_49e1b9988.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDMxNCAxNzldCi9Dcm9w Qm94IFswIDAgMzE0IDE3OV0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQozMTQgMCAwIDE3OSAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDMxNAovSGVpZ2h0 IDE3OQovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo0lcyRR9LgRfSzmcwASxrgYEIlUgaPh NTNFDrsCLUarU9pNjohflVQW1MAAxdtPqCWgaOq0EW0Jc1TndvqFRABoOaOABEuUZs0Fv1VhKPGM jLVqw8eOcixspecGAMDcyVc1oNBoRxEv1JhdogWCgWXAFLrQB02bztz0VhhaVgmgIkKL7tqG2AFU ru5sUI31zxeZkLm2mr1aP5EV3mwL5rr8g58nedqrOaAlS72COjm7MMwoA1AA1Vr1luADmAl5qhru nhhfugdT+cJysENf47qFL4hTsnMu6Dvegb5IUw7/u8AACPoqCCMYdqFDogrWMYqq8ogvj3qm8qNQ IpkJxAkblQigSlt2SzuryuSsDWxKFMSrD2oEvyxrQ8q5Pwhi3wY8sGIMR8VoJF8HN1H6BEtJkYRP GTEPvBDlQugkgNOAkYsfHEVQohD/y3ArmKk98Nt+ukaoTIEerA9sxABIspIFMDIObOKSSg5rXSRG zfvMW0qNrBDNRvFKBMzL0+uo86ELRISBNA47dyErhHTegrXHa/7Oq4AExTyqrbKc09AC01VDMUpt IULPrWT2hDUVM0lUU0AjOKlRdLwMganUWsDsqVFNMwY0zzTbQyzUSkcLSqttNVZNlArxOQAWZHFD UTGS6IZR69IbSk/UerMJ03QcGVBQjyvO5cxznOSsWtFL1oTbcbsSsdNCDCMmodK7Txu2kCrNf1jT 7T122UkT3nm8d2umgsmIJU6CumAkdv81KBYFOA14tHkm0YhE04jBVBxvHkEoOsysR3gr0IVJkaIH ibDxqvzCv+9Lt3phcBvVVUlyXbyF5tk085XQiBKwxKorNYqRgJQB5nKgQKoIEWKOFViDBiEU0sGX I0ZygRI0Nrr+xuL4iFyhusIFW6DZopeuoG4u2IQ9e3PK3OxakhcQbvgwAasgevSY3zhbGABIgq1i F6i0fGIHs+SIFsKGbcAG7Y1IfC7qge76kcqo8ItqjosyKHqWSIRO6zhLFsMSCShxyJNZsvNIHAov hjGNBIGMQ0d5NINIL1pKt93etg0tiLdZTfYeChncdygXZdNC/b7qvPYymx4AeLVHTon1KHdWES7+ QvJ1dmkOCIoXI2afxaa9f9np8+gX7/neTI/s3F8Zw4AwDJ4F9vxMF0QEgVAsioWhbLMgRAyCUEyh HrLhAkkQ5giBsgpB2DxC0MAxL6VZNItjCIzPc1oh5UC6kDhVB+GEHSzFQDWGwrAbITBrXYYiGkHC IKgh9DGIUE4ZkDMmAAOYRIclbhdEaJRBWfltLgQWI8Q4rQKiKQI4RgA0FXP0yYS0XGtFQccYxFBA zqxXjU6csx5YbxNIQAGC7SjjECaoqg65A4gxrj4UQsx+y/BfD2YFcRWQYlPiNHUAByyxvlf5H2SB PSzHPRoZ9kpUi/NaOrIx8RBJHyRlATh6hFY2lRMIdQ6sOioO4fKiWUMr4GGHMKfBiD35OtJlhLmX Uu5eS9l9L+YEwZhTDmJMWY0x5kTJmVMuZkzZnTPmhNGaU05qTVmtNebE2ZtTbm5N2b0aj9zfnERw SzmTfphXlIdG7Wokt4nHCtDBZCJFOgwRhr4a56JcjMe1GpgDBvtebO9GZSqAkGjSQ+GsLmvkDjyj MiUOo7kfoSQSF67S5Q0N+GwrqjFr0CPqQ4PZDZDmJDmsWFrnSRIgniRlPJVhLScIEY0qJUTJ0hXr LagtHmIRkoZPQ/hn1YntXua6RBg2Hm4kXUVYSo0/MPIIFpEsWSDppQxJQNdFSGp5NDDpcZSzM0Xq un48xV12Plp0WCVchqfNKM+V+VSs251MNycBB1ZIz1xnWp1BEOymVMIPCp6hYy4QnIinmg7i3amv jonOF9ZqzyujatSLUs3+nsRsp0uhhJbLtXtYuyU6SFJCXuQJbJEpXRVaSUwyrNyBSEhUrqs7W2dg AtLRSlCcFWGmNwcpU5kYEqgscv+XCOSLG8ILUA0TW6vJROpFoxMo7YkDPCgN8VtVUoSXmn0wrKWX y3lddJIdOUEL1YMWM/b72/sQPkg+2VBSoppWtPWgSWUTviWKXEwrIX+2fP875jTtWEpWigVq8SuF 1s7SIkpoJDi3kZRAmC6L5qGEEM5bohrCS5GgUvYlehBbAkWUzJ5DhIFpYRxMQiCGJ8VYrqyRRS7j bguBu6cltTl1P4sKE71aTtSEu8dm8zAoAHrqFKg8whlhz6vReE72Rd8scE0flAdxmPCDPxafaMhD 91CrAcaQodWMj0KzIOcUAEHC7sTyeTxtmV7ZkGfZlcpOXSEJvzOQN0pBkCZaPagO6DdTOF3FyF+A 2Ts0kyGMHOByhHi3BiRU/ItjkQF3MS+Eg5UU3wQXQ+p2GjdJaFJ8LmfCBTLtl0ZjJU+d0oq8z2sC j7cb5F+1CeLTxPaLkCg41gHFniCzha1OFZuRIN3f1/C6PeqUx61qxrMmbc0UNaKxRU9ZfoSTlMXt FwUIDEKPhUZDAlMj7bKJxV5YsNUYmV2huJBENoQXL2uQighbIzx6MQsFduhNwEtMiEQOewiPZORE WyC87N7zihFRjgfB+EcJ4VwvhnDeHcP4hxHiXE+KcV4txfjHGeNcb45x3j3H0Q8gmI7DQ+xiZtwJ pvaZGlCMUNRCOYa+oCdvIIpmQjvKrCkSkKzMkXNiOZ9IrOYjlkYtbF6GlGDQbN+WcXtC+HLASQ9L IvozSpCtkoScnRTpUlyE64Tfv8hQIgYg4U+gS9JBYdkbhCVXpxhM0ENhMeVjdQoU0LLtniFKCIlW E7A6iER/I4EV7dR2H5EO99ytn3Uwvh3dO1L6fdr0T8woiZh5FJbPiFULEtdToartxkEhxWQvHBtb dPbIqgL/jyF59L6jUGMOHZ0EITPfMMrDnep3kW3oz/ZKNJ6eaqlaN6J0KVN6MgvoauWIOaZoc25P dRLbI4413qr/IFVkQz2npyEw2HMfuHWrKlkWTfIAgkVe7JLL7OzvbSzmla29PVKFI94xJxuQuI8R 67dmgtE3ajeLsjEvFoTC7KVv0oqv1u0vmIqGTGDjDwCgAARJ2n2vErWiDktv7CCoxurN9nMwMv2p 1CKEZKpC/wFmuQFoxGlhzMCHmvmqHOsLZFIDhOpJ/wRjBp8Ipu1mlIvDFmdmZQYGilUPWuBGgCEE oJUjNKAjEotg5o0wQmkurt4iDIXwOmRQorUrsiJiyseEZIgurvetbPAjSCmI5PVCEKIlhIpmlKNF IpFvsKMqNqyHRl2qrN1N3QePcqFLlP0PSQjFpvQPAn6EjPWjbjzwzIsqFw4IMNyIfKtgtQzM8CDR CH+jnCKtuQJCmpBryLbjEpBJCLhjVqRiFu0jGKlKSpBj7wLQiN9AARMFzlPPgi/KSwiGdm9iBRWD hMsPyRaw/iDESqTRLD7kURSjAiBp0P9t2qXQEQMRYrGOpKtRiHOJbqJKgQdrZJUCMxkiGqoREq5w 3odDCsqRNwiQUi2J8kYRpsFkxqiIzpUDQjdGKJFCGgiDpqDw0N2CWIaJNRnj2vgiSMkHxQZCbjEi voSCLpVjDp8iEqYC2q/FIDPudqYorCoOrvouqMHDqLUJgxsONjOvzpfQEFXiYRrORCdLgNfCWEPy OiWSKihlQMSiRxMxXI/CYucCQmvyViayNG3tKyciGEoOXFIGQt6ImCNSeFRQZH/DYndMSlXHbKAl bSkiXLYChNXxZCLKOrgr9Pxl8rPyrSekXEQL6s2l9EXCqjwmAx+C4iFD1HmyxyAGoHZypCdjxGGv 2j7inkSkZIoiHGdF2mPPANjEVGOy7GhrwkiHZnKtVoEmSEgy5ssE5mYl1GFkbi1iCmPEzOqpOxmu zEUmKiFvOS+kjE2LOpPTBCdHRKujKnDyoGDkbspybjLs4l2j+hLHNzAEMnZsatqjGG9MKmtTTiEL vnIGps2zZm4GwnICBspj+TVQ+rOOpHRnJRPnDEBToHxGbMaqDwQnKCdSTKVn3pABzMgIVkbNFnCl bDishpcDmpRr5CzHcNNExSTCDJCnhsdmrmkshybCzHjuURHpOyHq0TwnxUAEnnxHMyBOTGBidH5z XCxv6whsuCxugDEGGHFs5HWBbFbCBs9GMsPHMufCDHSncTzzLpPu7iDIgtTmr0MuaAAMvsojUs4z 9n8iD0I0TwiGGK4HdCEmpGG0ZydHLCCmaUdicn5ssUPsRUOnBiBOWC8TYHqNKDildNTilgNHqOfU GCBnwtMNVCFuhHLNBFATknjA6MyMvtBUYsxHFgRUy0QPmLoUv0bvCU4whi/URUaUOUhiBU6CZNEI Hl7TxD2gAzzvyjNEtnwyK0uEUhIhzVByuNJsqNNR9RPAAVBn1IjIHMUiHU/MSVHCOoHywwRO0VQD aMgBH0rnXlLwQnVyaCUtQjNTlU10MiCtTS6CHUHnwUMT1QXsxuUGvjEkxUWCC1XoYUemq0xseoDn BhHhbOWH1J61mUmyR1pupp5M0zbohSbiNUJtd0hCY1tCdz5CxSfiUuqSJy5G2u0VvxfiGybtuG5i ESMCH0+DDV1iF1zxeQ/wUu8GWR3xxQWPRsgipIuCmw0EUu/jfovJ/ETCIybi4EMKzR/J52DK/m0I tQbNhidRGTgKhLPKOLoILj4lVqxDMI5w3CCzoLgoapLJzzqk9JEPmobQ1Txwvv/HZvSNsCIsPxs2 XCEQ6WLxGrfxFDTw4QXGtyUiOnm2TC5qXPGrzI5xYxh12P5KaQKQZxNDBxhKniGyMQOv9xYWrGVQ VqaDTLMwBxAozxMDES9WaDmwPrWmnrNQoRlErLCTm2y1JrOKSCTnmxyjboePpLFLcLDyfSERuDgp 3FCp+2tiGQpQrPbk+otv/R7PmotjcKqUkleR2RgRxiJF7vbm924vk17wMXRzMLcQaQ2M2xaW+Osr ZTswsumFcXCNfpTC9SHXEjvUEQSCEoXxWl2jGvF2RiDN3wGo0Q/pRtfCuWWXVXZSerZmnkSvRXSC DXTGIE5Q+JOli18COExQRKDkwsCCDrvq+ESGTi/15TUEKQerJrNtKpaGXSznHEvNYQiS13ONdRfr fCuIqvECIyFJwlQKXtWrWrMt+C+EUDqrXiCRciTWdnBXN3m3xT/V1ELyQDi2JE9C0DezVj2viiFM K3hpGRyLcyqkxjdj2lRR4QQsQnq3UrnxoyErZjrsyLdyckZLkCFjowFrACCFM25oMrZkSlovMVwC OrVkDuUu+rzlcTRNrkJk5j4DyrpkUV3UiLOEhL11NXTiSi3KlCkLZsAjEX3CVR+SAzNzgTEKszLm lVQwsM20ACbS3I+sqVpvb4xJd4jCGl+NwV4CWS4iT0TXciNyviQHU45pQYnCWrD1uHps5SuCGVxC EtUCM0QVW5Bx0CQZHicu3lGm14MiT3aQsTwjI44qhMjDVnnxQsiisnWSmz3nX1hu1MeU3CN5UIf5 SVF16CFZXQWjyCJ5aiLsrFP1YiH5OkosvmJMuZdZATGrA1dDi0OLw5XUSIoS5iMMYGB1LtbIDCFn 05g1ji7UNH9H4mZ5lnz5ACE5e0nVbCDH/iIZwCK0zr70ZGyU2EZzP57HthbZkkb1bSK0HhH0rGsU pN10rUgGKVlMYLwUW51CDU2lb555AU2HkG7U0CCJRnWU2mNUz5/XP6BnbaQHNT+lPDxIMH1M6NZF x6D6R6SCMFdJOVT1GyHyzEoVGHtiBBjHZrN6AXH6br0CC1TURwKjEVTFD5qzmsJlChbNDtEi8DkH k6muv6MaZjfOSIq1Q1WHbFC0SNIiHOfVSUmHtEHZt5CIAVj1m1dak6MUaUavCR3UO071cXiUtRoZ ZPYnGkCn0aEYuU9nPuYNQZBPWOYp8Rf6B1ZjObAUhHSVkCIVomy1cZBMKCDNBjVZizWCPHUtelPK 7Zfa77MWbtgiBOyQdV/oNqY7SCqTHCDuxbSVeEGvIOxvrCHJyux1J4Jt2y/rsRQLJQMo/umut7Zb S507UOnl0NCFLuAnJuyVd5Z1sEGGsGtZj7X2ryWu8oXQBIUKTqrwBGfNGPItRCDuC36otZMm/mvF qC7trXe2sQSO4jxy1ixoWNnPJbqHjEjLe2btv614mKKbw5DRJmtiovkSNF0QpjsCyiNPUi/PuPX3 8iIEavbVybyns3IQ72gKu1tN/D+FZShF7P4FMcFtYPuvYJFvwCUu94CIoCY7iCKQNxdt8KC3uCQE QDcxUCMv5LWpyrUcbpgyEVqJiqIcgCY8ZiWxhDBW5F5RgCYbJCU1WyeJYciiWR5RrKyJEW+rt2/5 AuUiJ8oIKK02DyGMBCL8vCKXfFCPZDGXBXh6MIQ8m7aNw4/LJrm3eIrJ0W3MGkEDAL9LTczKXoMC 4isMDmmjmLVtYMkN/85CKWliU3+RT8M9DX4cKI18OrqjNR54M47zSDqreP4KnDB9Oi8YQi/jQkqG mwxDNdRxqLSJcKkTkrEjo4MQ1sZqzSOdSGZ0dSQD29MGAYZmt24o+YqPCLrSOj1lsyUCBYqLQ4pF 3b7EoYtFWJGkrT2iCLaj/L4oo7+sDHFXnD2yUFt6TP9G59iJcXvR0MHo+XfmnJcN+d1l7EmGcFvk 5MD2OEjE5iqOoKLEy5vXMmbmMMmwm9mipFo4rtUr82SdT06lqQfkxrrGXIrlLLeHxDn6gdfE5sK+ DluUupNiElalbu5SXEckvaXa2alE+Fe9Z8T0Fddq9YYFd3UCusbnymCaAim+PctI1kHlA9zCBS2t +eeAAAg9595MF+GCDF8l9iCD6QXYA7PCzehbYGQzN9xlyrF1FCDeocsxWrYeobYXfmEACF9bdJfT IC8X7zHy7mlC6REzLR0ZLuubYYuTAnoY+TG3PqnS7mSGel0eqi5e10KlQGCc+XxpqTXTQ4amomiY 1CYxHTdzrzfDxRHZ3DO/IThqp0gHE0xbciKTtprY9SPCZVT5dplZ6pm7KuMcwfTZu8h/WfW/XfX/ YfY/ZfZ/afa/bfb/cfc/dfd/efe/fff/gfg/hfh/ifi/jfj/kfk/lfl/mfm/nfn/ofo/WiAgCmVu ZHN0cmVhbQplbmRvYmoKMTAgMCBvYmoKNTM0MwplbmRvYmoKMTEgMCBvYmoKWyAvSW5kZXhlZCAv RGV2aWNlUkdCIDI1NSAxNCAwIFIgXQplbmRvYmoKMTIgMCBvYmoKPDwKL0ZpbHRlciBbIC9MWldE ZWNvZGUgXQovV2lkdGggMTA2Ci9IZWlnaHQgNjAKL0NvbG9yU3BhY2UgMTEgMCBSCi9CaXRzUGVy Q29tcG9uZW50IDgKL0xlbmd0aCAxMyAwIFIKPj4Kc3RyZWFtCoA/4FA4JBYNB4RCYVC4ZDYdD4hE YlE4pFYtF4xGY1G45HY9H5BIZFI4e3201120WC4nY5mmzWe22m13i73k0me2Hm83q6Hg7H2/H3A3 o83o1mk3X0+n5JIk+6g8Ha7nu9Ho43C7HU63a9Xu9Yq9Hw9nc9XhA36/KFS7S/X0+X1BnlVX3aY8 +n2+mq02c5JbHn4/X7cKbHXq+arY6dAlwqk8lFKlWA2GOpFUpEebT6rVOsz0aUislOrF4t1g+Hy+ KI8nmuFuvnG3nO6HC6qw104vVOlF+oGGzmOtlAqmWy2eqU0s2KwV/BsE/WwzGq7XQ7VsrWKwl6yu fA205HCnUqmGiwGSmkotE0lla6nU7IM6fe4G233tXprrHi8WAwVuZZsGegZ5HaeBsGSZ5ynAdBsm ebx5nkeLAn4VhnFscZ3HMdp0nceh5HodJynUaZlGgcBrGseJ5niZBuGimx5IMahomeWxalWR5Yky Rxdk2ch2nPBpqnYc51HkeCinisCCnMch0FgSxRE+TJSmAXxnrGfK4Hwqx6MCfsPy8oK3rwvB7nse xnmkZpZGgXhYGUXZ3QKkheFdCpiSsaxijuVBEEqR5OmEWJcFgUpckuRJNOyW8JoGex7nuaJhGWbh rG8Z5kmoZJdl8YJeluTZhFQUhflcYpfmSXhWlsSZCFMXZVGEgx6nwe5ZlcXBxm6chmmOaZYlGXio MKf5qHKbRKFgURnGQaRlmIZxDDwTRgF2ZKBrqfhOl8VRDkSShiF0YBQE2VRXlWXRclcVZummaSBq EfhhFcXRalkXBlmEaZTlEUBwHI6JwGkbx1nEZBemWbZuG67RlFMS5UFwUxSFwYhbh2RAqlS4KDGY X5ol3e5IEGOhUGEV5bGUYA/DCPhTEUS5Fj6TpZleYCDNSfRlmA4piGYTpMFQWxTOyYRaFOVROmGb JlEyWZTmiZZqmsbBsG+bBxGeZBmlq65AlWSBPF8VplmaaiSF2WRdF6WJRGmbZoG6dBwGMaJlHqop iGSZhvm8chwG0aq3nygZmG2aReF4X53nad5TFEWxdlgYRxG/GZsGgVpmlwSRSE4ZBfGOUxUFeYZd mcgx7n0fBU26/peFUR5PmHSj7nodUFG2dJwEAWJIGKaZknCapuGYYppGuaJvIGfC3kKWpKkGUxGm aYkAGubhVlSXRNk4ThwGztCBH98pzHAcpn0oaBmm4VhaF3qxpmgbZonAc5wl+YpgFXoRljGOAMgZ w0hmDKGYM0YYahLh1FYM0W5BiWjuFcKEVYwhZCsE8KcS4znLiUE8JMWoqBZGPFKKcUoviEjZG2NU bo2BsjfGgNoXwuxmi/GOMEeKHhlDfGiJgXooxijOGINMX4yhZCrFyMJVIsBSCdFKKISjyxqjKG8N Mkhz3WJcHgPB8sXYvRfjAP4gcYXynPMFGEc48R1DaHQN+Lpz4ukGHsYgXQzxdnGU0b8ZwzhqGIHw gQdqExzDwHS84fEZIxPkfKO8eo8UNDnHcOkdo8R4DyHcO+Qg7R2R+OcWofZcItj0GCM0aY8CdyUL K3ke5iDqDsTQmdWw+FbOEkgOl1ZqiCxvjPGWXY/ZLjrHi44ZgwxlDdG+OUhMlB2jzkwPQdo8hyJF HOT855cx5i2GkL8dA7h0DvHOOwZIwhkpFHWKUWApxkriNQPgw49iQjWHMNsP4sBIClE2JcWYnxSj iHGOgcxXHkjaKgUMgRQh9ouGmN0bo4h+vlIY3QcIsRYC5J4PeSQ7zF0Zo1RujhB6Gj9HYVKWUuCn FiHqLEaAu5xC/FsKQVYrRajHEgKEW4Xg4iBHEOUc5Ax609NEKgVYqhajRGmN6CgvR1jsHcMMZIwR QjEFYJ8xwuxViuNQPoXgxRr0dq5V2r1XyQjNG+NJ+w1RrjfGyNMZY0BWC2GMIUQQqBzIiIGPEew8 hIP9FiJ0UYuVri1FiMoazchijIF2KcYQrBSDGFaOJ85QV5jQXhWCyllbLWXIOO6YKHx4j3H3LJNB 9x8DpJ8d0gVJhl1jG4NQbAxhhDIFSKIW45xzDuGQMkYwvxcixb6NEeFdy2jdGyNqzFxbjXHuQQeN 4/qGy8LSWqXUZqPxhMFcm6117sXZu1du7l3bvXfvBeG8V47yXlvMQwpY+h2SWlvcg59BiHj2lmlo jw9KenfG4pEfA2BrjWHEOAcA0BxjWG0OIbo5RwjjNYPYbo4R0LEoMOMdo5ltXnwsTIaIdRLB4GK8 YeY9h5y0HKO9yw670ljHsVAfQ4B0jjHOORXo1BuDYG8OMXsRR345oMNwdY3h0jxxMXgrw95qjvHc OrGCXymYqH1HEgQwBiDEG2NYaY2Bzjdh2NEfMn28j1sgQ8aQ0L+jaG4OIcQ5xHCSEsMsY4xBDC2E sJ4WrkBGCSFgzcQIhRWDLGGTMaQzlSiqngNzC15xsLvFKJkSQ2xyjbEoLcULpxfDTJiJMRIshljM GoK0UYoFMjDDOKEPQixOCTUIL0TInBXCBWoH4P4gxlC+F0hUWwmTdPHGSKAUAqxw4sG2N0blwxsy MHiJ4YoqxjjMGRk4f9/BvDlScKsXgqRHo9GUNUZoqxQCoL3Vshx0RnjxkuOHHwnBOixHEeARYqBG hxFUIIVgulc0wsAMQx4shQClFRfgYY2BlaFvMNYZ40xXieE2M5rYvrWjNGkNUb7VRli+GIjQbGVB tVKHWHkV4ihFC2E4M8Y4yRkNcFKJoWwfA3iIt0vUagxBazZTWgkcI5FIj5HUOYdI2sqzrEGLISYr hnC52YL4WSvxjtWGcMxEw1BcDSGELgYwwXMjXSaOe9JCbhDehW7ubYnBICxGFElFw0BhjbGWKMZI rh7k7GeMNhAuRmi8FyMFTIxhsDUGhwC8o9SeDjG+N8+STR3DnxGOceh+xoDFGSOMcQ6Caj0LwPsc g70GZXHSOkdaWh9YIHOLoWIx3LDiNqOQV/QS/DoNQ4UgWIB7yRt+mcbA4RsjSYDswc2LhyDiHUTa U2IMfjrz6MsdQ6B2SSKAVAhLOh0TfuYP5nReVtGBuYUzJr5XCK2MRfIZwyxkj0xB3q84zRrjYFeK 0VA4xzDeE1D8bQ6RvkGoSN4YI1RnDrHMOYQQnBCC0GiL0gwZ4aIbQdpAoaSG4WgVwUwZYbQZpWge oezTIbA55/AbhDYc7oYWIW4QYRSD4VIVoYYYgXiYI+C44tQfjZj8C8YTxoYRgTwTAagZ4ZYSoUwS QW4lRYggYaIbAboXzhhyzRwRoQAToXIUYgwZyySpIdoWUA4WYVIToVYWoU4gzAwbwUBpIooeYYAW oVwXoVgVC5gfogYZAVgXwx4TwRcKoSITASIc4cYcEFEN64oUYYAWAQgSYQ7kIZoTgU4U6rIZIbLB ogYXQagYYQwVwSoaQagaYToUQVYX4ZwYYgzSYYjjoS4VoVgUaI4VgcLv6CAdodQRgWASocpIgXYV wWYaCAYcwdQdyUweoZ4/oSgVIS4UYXwV4UoTwToZoYwZEOEXqyp3asYcQa0VgeQXYYAZgc7y77yd wgTyYdCeAbT7werdIdS+0ZgggeZLhY4bLwJAgdwhLaAcITIXYUhBwagVISYSgYAXAXySQeRD5Lg/ YcJ84dYeYsonYfJSEX0fcfgjaLo1J5wuEE8fsgkgsg0g8hEhMhUhchkhshyypCAeYagagbcBwfEe wdzEAeasCLod6f4vIuIhwtsL4jY56u5GIjq58kghaLpeQ5y6Qj0kahojagY1klAi0bIeYuqggjIZ RZ4NgPwPQYoZoaAZAZQaIrYdwd0d4bYbwbxLQe6MZ8sfJ1YuAvAfgbjBMVgeAbYcwb69YdoawZIZ IWAVoW4dD4kqQfwYoXgYUAYdoqoegX4WIWodA94aKFQVwXIXjioa4Y5u4w8qKRQf0EqLq9I1Ie7Y jA4bzvgegagZhF4nbL4gTLYfSkwwRCaTwfapQeC/4boa4bwawcIdKhgwQ1IuAoKLodwdgdrh4bIg wdYdZDhxr7we4awbgb0rYbIcrYBgwd4moWgWzqRq4bafinQdMiga6rT4QdgdAdIcIcJIocoXAYIY gci0gY47QWoZYXpRwgQ/UTAU4aYbQboao4oZ4ZoZk7wf6gb0Qc0qx+hw4bIaJwgewfSzwuwiIYqK YPYVYRIT4YxCoZQZ7F4c4WcRwUIVIV6nQcwgZSIe4W4U4VAXgWQXM24cgLAOIQh0oWgWIWQVAQYW ISISATQRYS4PYQb26nYgobIaoaU1YdQbI+gRANoOCBAZAVSlQPpQKAIT4WIT4dgeijC04ryAYbwa obAcgUQ0YTgRwQ4QwVoSIKQRgMTAgbAVIWIXpygXyVckIf4XYaoYbjQRInIZ6Nob55QawTQVIWAS gTccYZQXoNwUgP4ZAbIZgVASIS40YXbGodASoUQUwZJ6wgwaoYoY6iCF4c4SoUhygYwZI0kQwXoU Q+gbIQQNoPQRNRgNgQ4SoWwXQYyAwYgTAXLXQXoUoX4VIVIYYYAY4XAXgYM4ob4U4UISIW6C60wf 6SoegWIXQYIbQbwcRdRTwW4WZM5JYf5SAfATIT4WAZIaQZQYkowWoVQUIZ7kAM4UgPQWYZYXgiQb 4aoasDYRQUQY4Vwc7AAeArYW4YAZ4TdTwcDA6urtYX0QYaVR7AgcAPoQaEQWCUYYIXwUgX1PIXER YSgSg2gccKT2Q/YdwapZASQTwSIbkAAWwX4Z4RYRoWMiYaxawWyRoeKnj7wT4UQWQQcQoOQNgRwS ARIQ4RoUgSIMIT4OoaJy4VoUoV4VwXgYgfCT4gb7YYoUiw4WxTgZQYQYgWwXAYYWIV4ZQQgQITxZ 4ZoZQagZYWYZoXYS4SIRgUgSgToaIaAb8SzKJEsKQbwb728NsZIayhYZhTQcAb4bYagbQaSSweAW YTYUIXAWoXtToVsWwY4kwaoYIWoWgSAXITxQ7bgZ4ajIxJD7wUhpMtgWtXIe41AUwWYYQYwaAbAV wVsYwXoXckB5pSIYYWgXQcYcocxZ4bdeIbqAAYQK4SYNQRIXAS4iSgwngecyq5454bzMoRYQ4VQr EEYf6W53YcB3Ic5M4e4bgbaaYd5L0EotSOd5ge0gd40fIoIuq5grweqg1ywfRSEqwfL3IcKTkwbY K1YaYcFaIaoXYXoYhEQc4aQcYa6VYr4eJI5vLCogRNYY4U7fAlgc0vS3gYQYsTYdQ+gc4qb4od4d QbmBQYQasPwagapOYeQVpotFwbogxDomoeoeUgM1gd6wYb76Ekcqdyynoewa7Bs1cbKWQcgbtYId hZAdAbyg0L6M8BzFIoReItowSq7LaT+IdLwtAwQa5swaThpFaV4e9/Qd50wWIZZgYio1CzwvIgwq QdwaBEpYgqRgxXYiUL6u7EIfgfSztkIgocYbgdGGYdEBweoYiKaj9y1nrIQnl7Ah4pbzT1QgkL4d 4dYd0JAdgdYdBCAeN7ZCoW4dIeQdgeZAr5Yc8qwcYrGLAbodQcLHgcCLCWVXIgYeGEIa4c4bidYY AWRshiTzSjk1iSonl5IcbH94q67GdQ0UoqYdVcoVwaobwbAXFRp8Qa+QgdQaDZU6Ab5KoVjYghIv IfIaYZAYLqAXQWhxNeIcRnhSoawcatQbmPoXBkQaqeIPoTQSAa4nIX4W6G1zYtUMAgQcIdocoUFA IcQdYcYaoZFa4ZwaK/7+QW4VSS14pMgW1nAX86gdRIoUYS4SAZ5cTDoZjEYdAUwSIUQSAPIQoa4a QbYPQNAPD7gYINgSgPASAXgTi/4cb/QSYbQaAaog1VoYAQwWYSgagcQbIWRcwaqyQgwcgbYbIYwY hkAcQa4WoX4Xo/M2B/EV4XYcOew6s2IdIdjcgcAUgT4Wg8AdIZoYQYSfyeJujKAYw+8wSy4aatAZ SBAbQmQI4QwK4SgXQUIXIWoXIYoXAX5AodwZVuQX4WQVIKwOQKAXsV7HIdog0kAYAVwUie4QwTgW 4UFNgUgRYOYRB8QbpNS4ggWCmCYcYbINISgOFJBZtiwa+FyOY1AvIaAbwaSxAVYXoYQWwToPQSYS oQ4SIagbwbSpgXwexDwgZLQfLkIZU9rnAQASIRoWxt0BUZCblzAUoUoRITYYAXgZIOgPwSVVoYaJ 4SIRwVwSQaAawZoRQO4QIZoW0SAgoai1wUYVYTIbIc1igaAaJLpeItRQozAP4OQVYYwWQWI/xq2y wf6LoXQXhHQQIOQXIZAXLo4ZJuAZ4ZTub8oYD0TJDGZIgcgVYZm4wXgWzM1hSzB+4dAUIWgWB5Qa IRQSIQAVIYgVwUYVgTQYIV4Xw/YegaQbL2QagZQVQUASUHIaJDgdQtC5hCYaZGkx5Fru5VgVITAT oSLcjMwb4cIgYboaIZwbhXaEATifsYRK4ZQWgX4codOBgmodArFuAbgZDbAVgU4VoX4UgWgcsuwU Re7F1FYf45+UQs71aOYWwY4ZAbDGYqweWPodeB5XYcKnpSQbLHgn4cQbYa7y4cqLYdgXQXQWc0gd BWiSg+ga4uAfIeQexCWH4gSgYWFDo0QTJ4LDocI77A0tQW4ZIXwUYTwSsnwY4PIUAQatYY4aoXoZ wVgS4Uk52R01eEIeD/gXwSYVASqTQdOIAt3UCjsyodIn8EvP9/AdAdYdS/SLovJL4fhW17+dq6Qc 4d80jCagZW0qsgCP+ELyK555qnpMjZkjWNobb1KMwtQdiYOBgdYcsNrBAby56HIeeO+PzLedojb3 6a0jWPYgquweRL75Nyzv4boaEYQcAdbmm3XTaZqTwgzyKnt6QfYawcobL1KWMewd/dswYryu4or1 KyEr4cYXQa5WarmiLAUYapPi4co54WoWYYbxQZhFQeONwcIbtuAaYYtzYZ1FyhL3IdUF+vEz9/Qe OiYSgXAVYWxFAcIa4bQrAc3OYsQegWwVwVTaYV619FwarBQeAdwUoToSAZMBYg3rgbwRwSgWYYhE oVAUQTbbAZIRwXITYT4VITwVIUoWIS4TwXfn4bctWRwdnmCbmHFYLM4dgcQbwcyq4XQaYYbxwde/ IWgadUKLYeo8AdgoSkA9wVAZAWakyZJxwy4TwPYUoQoRQXITSSQdd8aUkp4paA7u3BhWiVYXwZQZ 0Bwe7bYVQYoWwWnlIf4dcZIUQUoWgZcvAUgUwWrtwYMsAWwagX6RpI6pSnWwYkefga4XIaYYQWcd YXAUYU5DYdfsYZRd4bVCgVoKoPoLQRIWYSwZAYYgC/ZjMaCgUK4drqeTocTgcjdbbedThPySQKfR yVTSZVqEQKqabUbj/kjld7oUrFV6wVCqW62YCuVzIdzwd7BYy/dzudcknz/bTdcLCYLLabTbbRZz SZTEXxmUR6OKgP68W67Wi6Yy+XzUnz8sB9USEJqUMTZbLVUCUTy6XbNTiUWTZbjhYDOYTkdTkWzE XTebDYVirXJoLqVbjZci4WSwRSuSrxezzf2Vn+XvbjbraayFWyUVLBWbjdDpXTEYjveLyRaUSzHr eXf75fT6WS6Yb0er3SqXVK1XK3fvDnzibbfYS6X6/YTHYddZTSZrpd7rXbTYbkc7larZbDEZDP2X j8nl2Tvdzta7UaK1aS/b7abbsc7oYrBai1VDFpy1SJJEIUBhFWeh8HqfJ8HwcLjn8fp/Hkep4nee Z2nke56FSZRaGubhtG0ZxrmaZZungeB6p8e59HwQxbkqQ5WkqXZQlQYJdmAfDaGSZBiHIcZttkeZ 4HiYpcl+bZtnEdJznacp1nEWpoF+VRmFsbhxnCzRvG+cpzK+sBWFETw5k+QRkm2aRglsXZfFuYJY lWXZvGs7RvG8eJ1nWWJol2XJmGKXpUluSJClCbZsnCXxZFkWxXlMYpsmUex8nu8p2ncdJxHKbxfG gYhknAZ51HgdhomCZqbHoTBFlQ5hePKbJmGceh6HuVxTGIZTosqfyfHkeR6GKW5enEbJunEcJ1G8 cZynnWZwHGbx0HkdZQFmVRflgWrzW3bldxUfLJnmb9MHqetJNofZ9n4e1aSCd5xM2eZ6wLFVduHB zLW2fR+H2fB9HzbhSGQV5TmUWR73Lf+AW48h1HKdBoGUaZ9n0fd74Ykldnac5zuObh3wie8EQkeR rGibOEHxfh+XufOKHqfB71Gdpwm0bzan2cpxHHaBtnVO8UnvXbZH6sGKH0eUSncep4X8fNRnhe8g no2p9PLo+hsvXcGn68uNHamx2Hkn2nEyX5SmQaLxYxtifVQYpkmueN5mOYJeS2b11Ypimsn/XZsG gZZRFkUFJHucZvnGeh5HmdJ0nWeZ5nseB2nSYBdFmZBtGaUpclG0p0SBIJeFwVhimYYRimoYhqG2 Z9wHxeR676nxjm2ZhkmiYhbo4YRaF+e3gmiZhmnmeR3b1feLOHlfaJIXxrGITZhFOcsuGkYRn6Ye RzHYdx38XvqwH4d3vHrCd7+Ue+YlSmOYHrSyanWd52tUdB17CdHLlmZRtmcLYYwsR4D0Hg2w7Q3x wsdZW0UfjCB5jbGmMoeo8h4pAcYJ0ToqRkDFGs+Now8B7K/YQhFxaomLttPGOp7wkBQCpG0OYcIv VrCSFOI4UQtRRCRE0IcnY7ifIIHwK4TolRlN2HyggYAvRYDhGuNsUQlRQC8F8Mobg0xmCZEUHoYQ 0BhimF8Kl+sPjLjULSmwVwzRkDCDcJcOoghEByG0NAbAyVYs4h+ggPBYw4iKDaLgUgsxzrKHszEU 5LBtjVGWKQVwnxBiuEiMcZ4yBbifFiO4cxPTLjNGcMYWgyRcDiHOOMVomRTOeFaGcPAhhIisFKyx rpJHGDwFIKQTozhaDHF6L8YoiRPCffmO0ZIxxfnoHWI0SIgBKiBEgKIUIqw4h9EgNAZIw4sB7EYK 0SQTg5BKGgNMZMrmvGVEqLATQnBRCOF+KYXCURjPfHeKwVAnhyDbGubIdiSRViSFG48dguxgi/Fs LEUwwxojFDkJoPYyxiQBEaKcdY4RyQoPGO0eI7hMi8FGN6e4zFcjVHANUPglRHB+EUH0cg5BwE+V 2NIYYwx5HoV2MkZQzJ6DaG+NgbaCR8jdGgNISQjBJzdGsJUVIrShURMuOIb43RRiUEwMFXIkBTCm EgJgTQvRYisFALEURtGFj/fWPYTwtRSCOFCKIaY0BmsxfWgkXYuxdDcGiNISAlxJhzEoIsXgyBgo dG2PdeRshvjcG4KcW4rlMjlG2zUVwuhYhzEqIMUgrRSwMbckIZgzxoD7ZcJMWAnQ4CHD6OEcI33h jUHa/USYnhNCeEyJQRQnRIB0EuIUZgxBhiTEaJQWIvBdCCEsJgbo3RvDZGsNY8rcx4iWVsJIS4lj GCsGMMoYQ8USjAFgLAco3aUmXHqs0apS0cD5FCKcUAmREiJGCc4OYkxGDJGdTMYgv4JwVokZeVw0 BxjWHOPEdI8n6rsHmdEaorC3D0XYbIdI3xwMKJ8N0cY5LrNNXKT5FQ+IKDyXuhBA5tWiHDSCPGI4 +h4ryfqPEXguxaigFEJlkQ+EHPMXWPiEKs10j5a2ZUco5xyEMHE3AaovhkjFKEOVcylDyNSHoPMe 768lj2HYQkZ44hqDlSY31io+x3uMJ8Mu0wnRhioHkZMbg4hzPrHyQ4co5ByjjGwOYboxhuDNN05H Eq6R+K/HpK7AA7XnD/XmPQdR9RxjmHOL0XgsRmjNGM+Mcw3BujuHOOk2S/B9wEHgywfgxZvDDFkL QaAzxrilFqLU0g5xjjCFsOuk9978FgHaOgc49h7j2HGxtZo9FdpCHpE0b+rh/r+xgcRjC910j7z+ K0XgxBNCaFzMYTophOiYE8LkUQxhtjNSKLyUI515j3HOOYd7ZFJjcHPYMiaKR8USY0hIcWg9gbsM rngsA/c+jvHUOocQ7RzX/HZEcfI5hyDpHszAvQ5HJDz3jwvhmwB2DsHUJMQIchci8FmIgWwmheXr 0GOgjYsXMDLsEOwcYuHsJCHkNgbJSRnjaGfRyaQwLOVfV2gsbo0Rosm5yK0VYodWDjNkLEUApRZC tFuKoTouhVClFQKGpoehWCKEsL8UgzRgaqFMLBXI2CfDtHWOkQgqRHh7FgI0aw4RvYh3wOwnI0ql jjG4NsawsRli4Gy4gVYlxOjXGWNAZwySgjVHG/Tfo8WxWAJ8O/h4yBjjOGcMXN44BvwRGIM/yYxX bq+HkLAVgtxYCxYkM8Z43BwDZEMLQSwkxfihjQMcUomRSDVGvzc7o6368N9x7lbg1o5IuEGLwXgs BiDaGYMcbPLRpDVGCLUXozRjjSNkLAZouhREqGrcUTQgBHiPEMJYYAsj8DKGQ0cr66hdGE0Q6kXw zRpWaTrPUy4uhWC5GDY0W4qxeCpFCStggxxsBmhXhnhchjilBThIBOBvPkrBByBvhthwNshuhqBs LjhkpdA8g1hFhPhGBVrDhSBJhNhFBchqBhhZhehchnhhhnBKBGBOBLhDBUlOhghpBsBohyh0hysH hphsBXBThYhXBRBdkwBXnfBZBDhTBHBWhmBcmHhzhlhfBihlBjBpBrQdBsBrvjkdBhBthkhhKOBY hRhZhuBpBrrwhuiEoCvdQ0w1CSF2B7hpBnBoB0h2BzB3B5r/B5OHw5Bcwehshov4CfrphiA4BOg9 hjnNhZBQhZBahShYBlj8BXFqsmskB/mih+hchYBgBZhUBZhvQHB1tJj6EujLhwhuhyhrDwh1t+lz B7KlBvF7h0vDBpBxhsh3h3h4FNBwjZGNkmhyBxBfhshjhFBShMBlhhhlhRhNhSCrNUhdLshOhJBq hwhsBKBbBSD2BrhXRkhURNqARmhRBINYxRB/kFhxhpG0nhhphYBSBcKuBPhjhgBdq2FJh8hvhrhv hzJQB0C9QbnICdh2B5h3FkBzBJBKBJhtBphsoKEDjaQ1yGyHOGB0hxhxBJBMhCBuB0BvmYkEjds8 B4sSoTifkEB9F2B7SHoUIGIGHlB3B6B3mqlZh6DaB9FZh5saB6Dyl2Lvl5hsQGBQBVhOnItxiSM8 F/mFB9MmnYnGGFM/m2ECh6honXRJSTSpSpqJNLHFh4muSqStStofmKMxtdF8yuSxSxyySyyzSzy0 S0y1S1y2S2y3S3y4S4y5S5y6S6y7S7y8S8y9S9y+S+y/S/zATAzBTBzCTCzDTDzETEzFTFtXCAgK ZW5kc3RyZWFtCmVuZG9iagoxMyAwIG9iago4MzQxCmVuZG9iagoxNCAwIG9iago8PAovTGVuZ3Ro IDE1IDAgUgo+PgpzdHJlYW0K////PJM919WLy526TydUaqry5TcLqCH1r6cNBMrgGGJo85/7MHbR vEFvdpCWy/pBveB4yYmZvjlByz0Lq1ZtFEkMD3qD4TbEUKxU5ndPKDUwof65O73yfIgwhzSG9UjP AlhKhTmASYktnnCl7pjaHjnZ2HSWy/Ef+3lTgW6bUXD0m/YtHD+3Sd4n7s2/yOv5osRuOY9fWIrY qwxGR163O/quaRbuIF/MR02ZBxaFALlJbvLYzUpjpvVw7D3PpHjJUuHfQAI/DUmNp1GjLFFddsBP T46ZszSPIyHM88ZFvBknnFop22hzaA/EDDwWabLXuQJlUrWa4tm8r8yC9YmcHCX2RgFeumpuf3eq leFdbJpg0u0Vbc/vKX+8rHRFSJFrPthsnZLWDBFOtqcvFBPJdOa2ilOGeXwFNSh5e3EL5rDjUk11 KVmHdxAupyVCcJkoJyN7rp34tNMhLU6SOTRCHIeQkrDqGij7SM8gikC5s2jdLxZ6J8pOSfic3DLR Hk5Yr+EJmfsylUMCtc5CboGrTLHCxtiNFCKGsf64gh0G28zo5WbjF/snGrH1XB93CGsoyjIBWEck 3vkilnw/nVcMhT1zaVRvkG4ghstA/tSsJp/fKPcmTNUgb2ucrwn0vI4xL/eGnoj0vw7A/wyVqzM0 ilwrsagA0hhsbsd1YoMEk7P7GVGEDhGSzxCfZLzSmEcuxPnXxMvvMTm3ppw6qjDupko/KlhRvShh XI0eLyVlXupfNa4qJd9k3IYAFzExBdd7RQLUlr/8+ByJFkuvfKqZ299IBgUoauKua/rfnAC3F0a5 691459WVcezhIGmLukRrAktwKrVS2SBNuLxNb9OTKb9woqZGNxczGDicpPLhD/QsgB/i0/gCILG/ bSGTAUpScuz4uSQQ7T1JieE7a/EwmHFPe0RIfWT5PdIb0NRlIkZSGwB3K+20dHeWsOKI4Hv5MPc9 eHWicrJ0jYJJ86WPRsCPvex8cmHzCRHWkfJSiiNJyJy+aw9w4JzzKZCYuNZZCmVuZHN0cmVhbQpl bmRvYmoKMTUgMCBvYmoKNzY4CmVuZG9iagp4cmVmCjAgMTYKMDAwMDAwMDAwMCA2NTUzNSBmIAow MDAwMDAwMDEwIDAwMDAwIG4gCjAwMDAwMDAxODUgMDAwMDAgbiAKMDAwMDAwMDIzNCAwMDAwMCBu IAowMDAwMDAwMjkzIDAwMDAwIG4gCjAwMDAwMDA0OTcgMDAwMDAgbiAKMDAwMDAwMDU4MCAwMDAw MCBuIAowMDAwMDAwNTk4IDAwMDAwIG4gCjAwMDAwMDA2MzYgMDAwMDAgbiAKMDAwMDAwMDc0NCAw MDAwMCBuIAowMDAwMDA2MjY4IDAwMDAwIG4gCjAwMDAwMDYyODkgMDAwMDAgbiAKMDAwMDAwNjM0 MCAwMDAwMCBuIAowMDAwMDE0ODIwIDAwMDAwIG4gCjAwMDAwMTQ4NDEgMDAwMDAgbiAKMDAwMDAx NTY2NCAwMDAwMCBuIAp0cmFpbGVyCjw8Ci9TaXplIDE2Ci9JbmZvIDEgMCBSCi9Sb290IDIgMCBS Cj4+CnN0YXJ0eHJlZgoxNTY4NAolJUVPRgo= --------------030302070205050405080501-- From ljrpf@vapor.com Tue Jul 03 11:55:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kiw-0007K4-US for nfsv4-archive@lists.ietf.org; Tue, 03 Jul 2007 11:55:30 -0400 Received: from ppp-124.121.191.188.revip2.asianet.co.th ([124.121.191.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5khx-0001g1-HE for nfsv4-archive@lists.ietf.org; Tue, 03 Jul 2007 11:55:30 -0400 Received: from [60.119.91.177] (helo=bryaa) by ppp-124.121.191.188.revip2.asianet.co.th with smtp (Exim 4.62 (FreeBSD)) id 1I62S/-0006Jc-Gy; Tue, 3 Jul 2007 22:51:05 -1200 Message-ID: <468B7B43.3070101@vapor.com> Date: Tue, 3 Jul 2007 22:49:39 -1200 From: confession User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: quaver slab Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 ERMX Jumps 12.5% and Volume Goes Through The Roof! EntreMetrix Inc. (ERMX) $0.18 UP 12.5% Big news last week pushed investors to the table. Wallst.net release of an audio interview got them excited. This is only the first day after the release. Act fast and get on ERMX Tuesday morning! We have worked with them on other logistics projects before. The system also streamlines the packing process by supporting grocery story-type scanning of bar-coded inventory. Using DutyMaster ensures that InBond will always be compliant with HMRC legislation. Storm clouds ahead - Logistics Industry may not be in good health for long - LogisticsIT. The new solution will integrate with our bespoke ERP system and will give our suppliers visibility to our planning, allowing them to align their forecasts to ours. However, the report concludes that knock-on effects of economic factors, oil and the collapse of the Doha round of trade discussions may cause significant problems for this sector in the near future. Paul Sykes, managing director, StockMarshal, outlines the optimum route to seasonal logistics survival. Added to that is the ability to factor in unscheduled events, such as natural disasters, that might spike or shift demand dramatically. If you use, or intend to use, barcodes or RFID identification systems - or just want a simple accurate method of recording product movements - StockMarshal is an ideal tool to replace your paperwork. It will then explain how an RFID system works and propose a range of increasingly secure methods of using RFID to prevent some of the different types of counterfeiting. In addition to faster, more accurate invoicing and better customer service, BillingCtl has helped InBond cut billing administration costs. In addition to faster, more accurate invoicing and better customer service, BillingCtl has helped InBond cut billing administration costs. Webbley concludes: "Attunity has enabled us to upgrade our IT systems with PCs - our staff can now view more information at a glance on one screen. This type of responsiveness can help maintain top line profits even during an emergency. Because it has no cables, the Vocollect SRX headset also helps improve user comfort and safety in busy DC environments. Additional criteria fields and data have since been added to several screens to incorporate features needed by individual customers. Using a wizard-driven interface, business users can assign business rules that define how the system handles transactions in response to various parameters and conditions. Russian retailer Uniland slashes stock burden with Aldata G. For Audit and Accountancy firms, the solution includes functionality for partner based operations, and rapid repeat projects, such as annual income tax preparation. Paul Sykes, managing director, StockMarshal, outlines the optimum route to seasonal logistics survival. , a leading technology market research and strategy firm. Increasing security in the supply chain with electronic security markers - LogisticsIT. Witron wins picking system project for Boots The Chemists - LogisticsIT. Smart electronic security markers, based on RFID technology, are making an impact with item-level security and laying the ground work for this kind of protection in future applications. InBond also plans to use the web client of DLx Warehouse, to give its clients remote access to details of their consignments. Alshaya will use the Financial, Item and Assortment Planning components of Manhattan Associates' Integrated Planning Solutions to manage the flow of goods across its entire supply chain. Partners can make use of the knowledge at the center to equip their repair facilities and to make these for example ESD safe. The software can accurately see details of raw materials, ingredients, and even where packaging materials are held. For Hand Held Products, this qualification underlines the ambition to ensure and exceed standards. Audit reporting facilities allow users to track the movement of goods from collection to final shipment, in compliance with HMRC legislation. We will work with Alshaya every step of the way to provide them with a complete supply chain solution that reliably supports their ambitious growth plans. It also minimises the chance of human errors. This has had a significant effect on global trade as demand has increased in the majority of the affluent countries. That is why Voxware was able to deliver Advance Auto Parts the solution they needed, on time and on budget. What is needed is a single demand signal at the lowest point of consumption, which is typically in the store or on the Web when a consumer buys a product. The success of this supply chain project is seen as critical to the overall performance of Alshaya as a business. "It should be noted that this study aggregated customer and non-customer responses, so some of this praise came from companies that may not be operating Intermec systems," Krebs said. Smart electronic security markers, based on RFID technology, are making an impact with item-level security and laying the ground work for this kind of protection in future applications. Mr K R Narayanan, Business Systems Development Manager of Alshaya, explains, "Our supply chain is particularly challenging because of the number of countries involved. Performance improvementsThe integrated solution gives InBond apid access to data and allows reports for customers or HMRC to be generated much faster than using its old legacy systems. This approach has allowed companies to de-bottleneck a great deal of inventory. Additional criteria fields and data have since been added to several screens to incorporate features needed by individual customers. Instructions appear instantly on the screen, advising the warehouse operative where the goods should be stored. Watson's subsidiary Kruidvat opts for Witron DPSKruidvat, a subsidiary of the worldwide operating A. Partners can make use of the knowledge at the center to equip their repair facilities and to make these for example ESD safe. From ndrbutterfield@moecho.org Tue Jul 03 12:11:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kxx-0006L6-IB for nfsv4-archive@lists.ietf.org; Tue, 03 Jul 2007 12:11:01 -0400 Received: from p54a84b13.dip.t-dialin.net ([84.168.75.19]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I5kxx-0004Lg-0K for nfsv4-archive@lists.ietf.org; Tue, 03 Jul 2007 12:11:01 -0400 Message-ID: <001b01c7bd9d$8253beb0$06f15f8c@chridtinm73wia> From: "Nancy Hendrix" To: "nfsv4-archive" Subject: Fw: Thank you, we are accepting your debt request Date: Tue, 3 Jul 2007 18:08:16 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C7BD9D.8253BEB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.2969 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.2963 X-Spam-Score: 2.1 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe ------=_NextPart_000_0018_01C7BD9D.8253BEB0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Your credit doesn't matter to us! If you OWN property and want IMMEDIATE cash to spend ANY way you like, = or simply want to LOWER your payments by a third or more, here is our = deal we can offer you TONIGHT (hurry, this lot will expire TONIGHT): $334,000+ loan AND EVEN MORE: After further review, our lenders have established the = lowest payments! Hurry, when best deal is gone, it is gone. Simply complete this plain = form... Don't worry about approval, your credit will not disqualify you! http://livefashealthh.com/ ------=_NextPart_000_0018_01C7BD9D.8253BEB0 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Your your credit report = doesn't matter to us!
 
If you OWN real estate and = want IMMEDIATE money to spend ANY way you like, or simply need to LOWER = your payments by a third or more, here is best deal we can offer you = THIS EVENING (hurry, this tender will expire TODAY):
 
$326,000+ = loan
 
AND EVEN MORE: After = further review, our lenders have established the lowest = payments!
 
Hurry, when our best = deal is gone, it is gone. Simply fill in this user-friendly form... =
 
Don't worry about = approval, your credit will not disqualify you!
 
------=_NextPart_000_0018_01C7BD9D.8253BEB0-- From nfsv4-bounces@ietf.org Tue Jul 03 14:32:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5nAG-0006j7-EU; Tue, 03 Jul 2007 14:31:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5nAD-0006h8-VL for nfsv4@ietf.org; Tue, 03 Jul 2007 14:31:50 -0400 Received: from wr-out-0506.google.com ([64.233.184.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5n9K-0007ug-9m for nfsv4@ietf.org; Tue, 03 Jul 2007 14:31:49 -0400 Received: by wr-out-0506.google.com with SMTP id 70so1245474wra for ; Tue, 03 Jul 2007 11:30:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=irDvXvuKvbGnyIhJg629lUKAw3DjDO2wEWBlWUb3yChmnMl1+LNjJAq6aDR1Nu7mIdJNhyPnl+IV1BAOmZ+MR+dBOaOm+hdksiGN6qYznRrDitMUt0183eQoupKv/lfznY2YbADC937ufdWkS+HL3dm6cNJVPoSN4+oVHBF1aU4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=DTwSJt5l0T79DFMiltq2OdjmghgtKFxoEjtd5m7zRDSQJRCEIR757JjqAkk0+MO2bj2b9XD2di7dhDW15wNAjHw1l1cxpQG+JOfFfDmcqLc09mZjCcHipK+v3cAh6N9v65KvTj3eEMXzI6S3ifjujoB2Z/EE8nCKJl0hK5PY3U8= Received: by 10.143.38.6 with SMTP id q6mr456612wfj.1183487453239; Tue, 03 Jul 2007 11:30:53 -0700 (PDT) Received: by 10.142.116.20 with HTTP; Tue, 3 Jul 2007 11:30:53 -0700 (PDT) Message-ID: <89c397150707031130n35351248re5d8b7a10571ad16@mail.gmail.com> Date: Tue, 3 Jul 2007 14:30:53 -0400 From: "William A. (Andy) Adamson" To: "William Brown" MIME-Version: 1.0 X-Google-Sender-Auth: 5d15a09676f9c56b X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nfsv4 , NFSv4 Subject: [nfsv4] Fall 2007 NFSv4.1 CITI sponsored Bakeathon date query X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1468493293==" Errors-To: nfsv4-bounces@ietf.org --===============1468493293== Content-Type: multipart/alternative; boundary="----=_Part_76040_6776919.1183487453224" ------=_Part_76040_6776919.1183487453224 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline We had a successful bakeathon in Austin - thanks to Sun for sponsoring! CITI will once again host a fall bakeathon, for NFSv4.1 implementations. We propose the first week of October - Monday 10/01/07 through Friday 10/5/07. Is this an agreeable week? -->Andy On 7/3/07, William Brown < wilbrown@us.ibm.com> wrote: > > Hope things are going well in Michigan. We're really tire of hte rain in > Texas... > > When you were here for the bakeoff, you mentioned there may be a NFS 4.1bakeoff at CITI. When were you thinking this may be? > > Bill > ------=_Part_76040_6776919.1183487453224 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We had a successful bakeathon in Austin - thanks to Sun for sponsoring!

CITI will once again host a fall bakeathon, for NFSv4.1 implementations.

We propose the first week of October  - Monday 10/01/07 through Friday 10/5/07.
Is this an agreeable week?

-->Andy

On 7/3/07, William Brown < wilbrown@us.ibm.com> wrote:

Hope things are going well in Michigan. We're really tire of hte rain in Texas...

When you were here for the bakeoff, you mentioned there may be a NFS 4.1 bakeoff at CITI. When were you thinking this may be?

Bill


------=_Part_76040_6776919.1183487453224-- --===============1468493293== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============1468493293==-- From rthq@cpinternet.com Tue Jul 03 14:59:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5nak-0001lv-7m for nfsv4-archive@lists.ietf.org; Tue, 03 Jul 2007 14:59:14 -0400 Received: from [77.109.34.231] (helo=lbwgvj) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5nZw-0005iE-HC for nfsv4-archive@lists.ietf.org; Tue, 03 Jul 2007 14:59:14 -0400 Received: from uvbju.hnr ([99.211.26.167]) by lbwgvj with Microsoft SMTPSVC(6.0.3790.0); Tue, 3 Jul 2007 20:57:27 +0200 Message-ID: <002a01c7bda4$00326f60$a71ad363@uvbju.hnr> From: "greet2k.com" To: Subject: July 4th Fireworks Show Date: Tue, 3 Jul 2007 20:57:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Score: 1.7 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi. Worshipper has sent you a greeting ecard. See your card as often as you wish during the next 15 days. SEEING YOUR CARD If your email software creates links to Web pages, click on your card's direct www address below while you are connected to the Internet: http://85.106.242.27/?90b516c3c2cd8a7c0b58e Or copy and paste it into your browser's "Location" box (where Internet addresses go). PRIVACY greet2k.com honors your privacy. Our home page and Card Pick Up have links to our Privacy Policy. TERMS OF USE By accessing your card you agree we have no liability. If you don't know the person sending the card or don't wish to see the card, please disregard this Announcement. We hope you enjoy your awesome card. Wishing you the best, Webmaster, greet2k.com From nfsv4-bounces@ietf.org Tue Jul 03 17:42:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5q7R-0004by-Iw; Tue, 03 Jul 2007 17:41:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5q7P-0004Yx-Mf for nfsv4@ietf.org; Tue, 03 Jul 2007 17:41:07 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5q7L-00011S-6d for nfsv4@ietf.org; Tue, 03 Jul 2007 17:41:07 -0400 X-IronPort-AV: E=Sophos;i="4.16,494,1175497200"; d="scan'208,217";a="78479180" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 03 Jul 2007 14:40:54 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l63LerKv008677; Tue, 3 Jul 2007 14:40:53 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 14:40:53 -0700 Received: from exsvl01.hq.netapp.com ([10.56.8.45]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 14:40:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [nfsv4] Fall 2007 NFSv4.1 CITI sponsored Bakeathon date query Date: Tue, 3 Jul 2007 14:40:52 -0700 Message-ID: <7619F3097FAB384287CF636FF92D0CA109248653@exsvl01.hq.netapp.com> In-Reply-To: <89c397150707031130n35351248re5d8b7a10571ad16@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Fall 2007 NFSv4.1 CITI sponsored Bakeathon date query Thread-Index: Ace9oLQiFcCcg+loTImtW45OTciOjAAGezpg References: <89c397150707031130n35351248re5d8b7a10571ad16@mail.gmail.com> From: "Labiaga, Ricardo" To: "William A. \(Andy\) Adamson" , "William Brown" X-OriginalArrivalTime: 03 Jul 2007 21:40:53.0127 (UTC) FILETIME=[D4924170:01C7BDBA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: nfsv4 , NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0793809327==" Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. --===============0793809327== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BDBA.D450CD44" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BDBA.D450CD44 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 10/01/07->10/05/07 works for us at NetApp. =20 - ricardo ________________________________ From: William A. (Andy) Adamson [mailto:andros@citi.umich.edu]=20 Sent: Tuesday, July 03, 2007 11:31 AM To: William Brown Cc: nfsv4; NFSv4 Subject: [nfsv4] Fall 2007 NFSv4.1 CITI sponsored Bakeathon date query =09 =09 We had a successful bakeathon in Austin - thanks to Sun for sponsoring! =09 CITI will once again host a fall bakeathon, for NFSv4.1 implementations. =09 We propose the first week of October - Monday 10/01/07 through Friday 10/5/07.=20 Is this an agreeable week? =09 -->Andy =09 =09 On 7/3/07, William Brown < wilbrown@us.ibm.com > wrote:=20 Hope things are going well in Michigan. We're really tire of hte rain in Texas... =09 When you were here for the bakeoff, you mentioned there may be a NFS 4.1 bakeoff at CITI. When were you thinking this may be? =09 Bill =09 ------_=_NextPart_001_01C7BDBA.D450CD44 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
10/01/07->10/05/07 works for us at=20 NetApp.
 
- ricardo

From: William A. (Andy) Adamson=20 [mailto:andros@citi.umich.edu]
Sent: Tuesday, July 03, 2007 = 11:31=20 AM
To: William Brown
Cc: nfsv4; = NFSv4
Subject:=20 [nfsv4] Fall 2007 NFSv4.1 CITI sponsored Bakeathon date=20 query

We had a successful bakeathon in Austin - thanks to Sun for = sponsoring!

CITI will once again host a fall bakeathon, for = NFSv4.1=20 implementations.

We propose the first week of October  - = Monday=20 10/01/07 through Friday 10/5/07.
Is this an agreeable=20 week?

-->Andy

On 7/3/07, William=20 Brown < = wilbrown@us.ibm.com>=20 wrote:

Hope things are going well in Michigan. We're really tire of hte = rain in=20 Texas...

When you were here for the bakeoff, you mentioned = there may=20 be a NFS 4.1 bakeoff at CITI. When were you thinking this may=20 = be?

Bill


<= /HTML> ------_=_NextPart_001_01C7BDBA.D450CD44-- --===============0793809327== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============0793809327==-- From zgnk@gruposis.com.gt Tue Jul 03 19:56:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5sEO-0007XG-Vz for nfsv4-archive@lists.ietf.org; Tue, 03 Jul 2007 19:56:28 -0400 Received: from pool-72-65-100-98.ptldme.east.verizon.net ([72.65.100.98]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5sEB-0002dC-Lp for nfsv4-archive@lists.ietf.org; Tue, 03 Jul 2007 19:56:28 -0400 Received: from dayl.huo ([210.64.206.176]) by pool-72-65-100-98.ptldme.east.verizon.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 3 Jul 2007 19:57:01 -0400 Message-ID: <001501c7bdcd$d94dd310$b0ce40d2@dayl.huo> From: "greeting-cards.com" To: Subject: Happy Fourth of July Date: Tue, 3 Jul 2007 19:57:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2578 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2578 X-Antivirus: avast! (VPS 000753-2, 07/03/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 4.6 (++++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi. School mate has sent you an ecard. See your card as often as you wish during the next 15 days. SEEING YOUR CARD If your email software creates links to Web pages, click on your card's direct www address below while you are connected to the Internet: http://68.94.55.164/?ca39ab8183e5868911e6c36a4bc9 Or copy and paste it into your browser's "Location" box (where Internet addresses go). PRIVACY greeting-cards.com honors your privacy. Our home page and Card Pick Up have links to our Privacy Policy. TERMS OF USE By accessing your card you agree we have no liability. If you don't know the person sending the card or don't wish to see the card, please disregard this Announcement. We hope you enjoy your awesome card. Wishing you the best, Webmaster, greeting-cards.com From vdta@ta.telecom.com.ar Wed Jul 04 00:39:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5wed-0003W6-Pt for nfsv4-archive@lists.ietf.org; Wed, 04 Jul 2007 00:39:51 -0400 Received: from [12.151.4.133] (helo=wiawy) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5weZ-0005Ev-9w for nfsv4-archive@lists.ietf.org; Wed, 04 Jul 2007 00:39:51 -0400 Received: from li.uoct ([206.176.81.110]) by wiawy with Microsoft SMTPSVC(5.0.2195.5329); Wed, 4 Jul 2007 00:39:46 -0400 Message-ID: <000501c7bdf5$59111f40$6e51b0ce@li.uoct> From: "dgreetings.Com" To: Subject: God Bless America Date: Wed, 4 Jul 2007 00:39:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Spam-Score: 4.4 (++++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi. Class mate has sent you a greeting ecard. See your card as often as you wish during the next 15 days. SEEING YOUR CARD If your email software creates links to Web pages, click on your card's direct www address below while you are connected to the Internet: http://71.224.104.152/?83e5868911e6c36a4bc9 Or copy and paste it into your browser's "Location" box (where Internet addresses go). PRIVACY dgreetings.Com honors your privacy. Our home page and Card Pick Up have links to our Privacy Policy. TERMS OF USE By accessing your card you agree we have no liability. If you don't know the person sending the card or don't wish to see the card, please disregard this Announcement. We hope you enjoy your awesome card. Wishing you the best, Webmaster, dgreetings.Com From nfsv4-bounces@ietf.org Wed Jul 04 03:59:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zlA-0001Ry-GH; Wed, 04 Jul 2007 03:58:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zl7-00010Z-Me for nfsv4@ietf.org; Wed, 04 Jul 2007 03:58:45 -0400 Received: from gw-e.panasas.com ([65.194.124.178] helo=cassoulet.panasas.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5zl3-00007L-D2 for nfsv4@ietf.org; Wed, 04 Jul 2007 03:58:45 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l647wdAJ019471; Wed, 4 Jul 2007 03:58:39 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 4 Jul 2007 03:58:39 -0400 Received: from [192.168.0.140] ([172.17.19.37]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jul 2007 03:58:39 -0400 Message-ID: <468B532D.5080607@panasas.com> Date: Wed, 04 Jul 2007 10:58:37 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: "Labiaga, Ricardo" , "William A. (Andy) Adamson" Subject: Re: [nfsv4] Fall 2007 NFSv4.1 CITI sponsored Bakeathon date query References: <89c397150707031130n35351248re5d8b7a10571ad16@mail.gmail.com> <7619F3097FAB384287CF636FF92D0CA109248653@exsvl01.hq.netapp.com> In-Reply-To: <7619F3097FAB384287CF636FF92D0CA109248653@exsvl01.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jul 2007 07:58:39.0730 (UTC) FILETIME=[21FD0520:01C7BE11] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: nfsv4 , NFSv4 , William Brown X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Unfortunately this week doesn't work so great for me as it conflicts with the Sukkot holiday for which I have planned to go on vacation with my family. How about the third week of October, Monday 10/15/07 through Friday 10/19/07? Any chance it works too? Benny Labiaga, Ricardo wrote: > 10/01/07->10/05/07 works for us at NetApp. > > - ricardo > > > ________________________________ > > From: William A. (Andy) Adamson [mailto:andros@citi.umich.edu] > Sent: Tuesday, July 03, 2007 11:31 AM > To: William Brown > Cc: nfsv4; NFSv4 > Subject: [nfsv4] Fall 2007 NFSv4.1 CITI sponsored Bakeathon date > query > > > We had a successful bakeathon in Austin - thanks to Sun for > sponsoring! > > CITI will once again host a fall bakeathon, for NFSv4.1 > implementations. > > We propose the first week of October - Monday 10/01/07 through > Friday 10/5/07. > Is this an agreeable week? > > -->Andy > > > On 7/3/07, William Brown < wilbrown@us.ibm.com > > wrote: > > Hope things are going well in Michigan. We're really > tire of hte rain in Texas... > > When you were here for the bakeoff, you mentioned there > may be a NFS 4.1 bakeoff at CITI. When were you thinking this may be? > > Bill > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From qlizrkfppf@rrindustria.com.br Wed Jul 04 22:14:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6GrT-0007uT-UU; Wed, 04 Jul 2007 22:14:27 -0400 Received: from fl-71-53-130-92.dhcp.embarqhsd.net ([71.53.130.92] helo=JUSTIN.1nh1s4ly.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6GrT-0004Bq-M6; Wed, 04 Jul 2007 22:14:27 -0400 Message-ID: <34908340821957.8F6D479684@HRDMGAS> From: "Jacques Kuhn" To: Subject: Sex can be one of the most enjoyable parts of your life. Date: Wed, 4 Jul 2007 22:13:23 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: djOt9J8akKhkBxeTTC3uqj9Lc4pNggdoJ6uQ Content-Type: text/html; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad

What is CIALIS?

CIALIS is the only ED (Erectile Disfunction) tablet clinically proven to work both
up to 36 hours and in as fast as 30 minutes. And because CIALIS has an extended
period of effectiveness, you don’t have the pressure to perform within a few hours.
You and your partner can relax and take your time choosing the moment that is right for both of you.

Benefits of CIALIS

  • Works up to 36 hours
  • Works fast
  • Works Effectively
  • Keeps you ready
  • No need to plan around meals
  • Used by millions of men

Buy CIALIS online!

 From nfsv4-bounces@ietf.org Thu Jul 05 03:52:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6M7l-0002ks-3P; Thu, 05 Jul 2007 03:51:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6M7h-0002gN-At for nfsv4@ietf.org; Thu, 05 Jul 2007 03:51:33 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6M7b-0007mZ-QS for nfsv4@ietf.org; Thu, 05 Jul 2007 03:51:33 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l657pROn015466 for ; Thu, 5 Jul 2007 03:51:27 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 5 Jul 2007 03:51:27 -0400 Received: from [192.168.0.140] ([172.17.28.139]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 03:51:26 -0400 Message-ID: <468CA2FE.3040706@panasas.com> Date: Thu, 05 Jul 2007 10:51:26 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: NFSv4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 07:51:27.0168 (UTC) FILETIME=[4A930C00:01C7BED9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [nfsv4] Setting mode and not ACL tidbits X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Section 6.4.1.1 in draft-ietf-nfsv4-minorversion1-11 seem to me to be a bit too restrictive. The suggested model applies the group permission bits on any entity other than the OWNER@ and EVERYONE@ ACEs. My problem with it is that if the respective permission bits for MODE4_*OTH are set the affected entities are allowed access via the EVERYONE@ ACE but the information in the original ACE is lost. Applying similar semantics on the *OTH bits rather than on the *GRP bits just seem to make more sense to me... For example, how about the following text? If MODE4_ROTH is not set, entities explicitly listed in the ACL other than OWNER@ and GROUP@ SHOULD NOT be granted ACE4_READ_DATA. rather than If MODE4_RGRP is not set, entities explicitly listed in the ACL other than OWNER@ and EVERYONE@ SHOULD NOT be granted ACE4_READ_DATA. Benny _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From xbalsa@kurilka.zzn.com Thu Jul 05 06:33:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6OeM-0007Ee-HK for nfsv4-archive@lists.ietf.org; Thu, 05 Jul 2007 06:33:26 -0400 Received: from dsl-206-53-24-164.den.pcisys.net ([206.53.24.164] helo=western-dz16jnh.pcisys.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I6OeM-0004rm-3r for nfsv4-archive@lists.ietf.org; Thu, 05 Jul 2007 06:33:26 -0400 Message-ID: <001601c7bebd$a16a1990$1b266f0c@westerndz16jnh> From: "Helene Trejo" To: "nfsv4-archive" Subject: Superstar Stock Report Date: Thu, 5 Jul 2007 04:30:49 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C7BEBD.A16A1990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.2962 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.4682 X-Spam-Score: 0.3 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 ------=_NextPart_000_0013_01C7BEBD.A16A1990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MRMT IS THE TRUE SUPERNOVA MONSTER MOTORS INC - Hires Award-Winning Design Studio for National = Branding Television Commercial Ticker: MRMT Trade: July 05 Thursday, 2007 MRMT Price: $0.6 Monday July 2, 9:00 am ET - News Release CHICAGO, IL--(MARKET WIRE)--Jul 2, 2007 Monster Motors, Inc. (Other OTC:MRMT.PK - News) announces a major = contract with top Commercial graphic producer Keech Studio for the = production of a National advertising spot for Monster Motors, Inc. The = Monster Motors commercial ad spot is designed for showing in Major cable = television Markets nationwide represented by Viamedia including those = markets serviced by Verizon FiOS, RCN, Knology, WOW, Surewest, New Wave, = Everest, Grande, Blue Ridge, Service Electric, CATV and Atlantic = Broadband. WATCH MRMT SHOOT THROUGH THE SKY THURSDAY! ------=_NextPart_000_0013_01C7BEBD.A16A1990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
MRMT IS THE TRUE = SUPERNOVA
MONSTER MOTORS INC - = Hires Award-Winning Design Studio for National Branding Television = Commercial
Ticker: MRMT =
Trade: July 05 = Thursday, 2007
MRMT Price: $0.6 =
Monday July 2, 9:00 am ET = - News Release
CHICAGO, IL--(MARKET = WIRE)--Jul 2, 2007
Monster Motors, Inc. = (Other OTC:MRMT.PK - News) announces a major contract with top = Commercial graphic producer Keech Studio for the production of a = National advertising spot for Monster Motors, Inc. The Monster Motors = commercial ad spot is designed for showing in Major cable television = Markets nationwide represented by Viamedia including those markets = serviced by Verizon FiOS, RCN, Knology, WOW, Surewest, New Wave, = Everest, Grande, Blue Ridge, Service Electric, CATV and Atlantic = Broadband.
WATCH MRMT SHOOT = THROUGH THE SKY THURSDAY!
------=_NextPart_000_0013_01C7BEBD.A16A1990-- From nfsv4-bounces@ietf.org Thu Jul 05 10:36:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6SRu-0003pz-10; Thu, 05 Jul 2007 10:36:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6SRs-0003nh-Kc for nfsv4@ietf.org; Thu, 05 Jul 2007 10:36:48 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6SRP-0007CA-Lv for nfsv4@ietf.org; Thu, 05 Jul 2007 10:36:48 -0400 X-IronPort-AV: E=Sophos;i="4.16,503,1175497200"; d="scan'208";a="79034851" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 05 Jul 2007 07:36:07 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l65EZtpP014110; Thu, 5 Jul 2007 07:36:01 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 07:35:56 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 07:35:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] An issue regarding free byte-range lock state Date: Thu, 5 Jul 2007 10:35:54 -0400 Message-ID: In-Reply-To: <471A7428-E98A-476A-85E5-2CE70E4A4742@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] An issue regarding free byte-range lock state Thread-Index: Ace8AdWL/P/5KBtZSyO8MzUtIL2GrgDDq+sg From: "Noveck, Dave" To: "Spencer Shepler" X-OriginalArrivalTime: 05 Jul 2007 14:35:56.0138 (UTC) FILETIME=[CC01FCA0:01C7BF11] X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org > > On the other hand there doesn't seem to be much point > > on OLD_STATEID on READ, WRITE, LOCK. If you are returning > > OLD_STATEID in those cases, you are forcing retry to > > give the server the stateid-sequence without much > > point. The server has the other part and can check the > > current state regardless of the stateid sequence. > Do we have a desire to provide fencing in the case > of mandatory locks? I am thinking of the case that the > client (or server) has made a mistake in its record > keeping and there may be in-flight read/writes that > don't match the mandatory file locking state. If the client makes a mistake then the server still has the correct current locking state, so the IO can be=20 rejected if it is from the wrong owner, just as it will=20 be if it is from a different client. As to the server making a mistake in its record keeping, I just don't know what you can do about that. If you assume that the server might be wrong about what mandatory locks are held, it just as well might be wrogn about what the correct seqid is. > I don't have a strong opinion -- a slight preference > for the stateid.seqid on read/write to provide for this. > So, whatever everyone else wants. Allowing the seqid to be sent or not as the client chooses allows this. What I really don't want a scheme that forces=20 the seqid to be sent, even when the locks are not mandatory, which is going to be a commmon case. -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Sunday, July 01, 2007 1:04 PM To: Noveck, Dave Cc: Peter Varga; nfsv4@ietf.org Subject: Re: [nfsv4] An issue regarding free byte-range lock state On Jul 1, 2007, at 9:59 AM, Noveck, Dave wrote: > I'm conivnced we need OLD_STATEID is some cases. The > cases where we need it are on CLOSE and OPEN_DOWNGRADE > to deal with the possibility of a pending OPEN of a > hard link. Agreed. > On the other hand there doesn't seem to be much point > on OLD_STATEID on READ, WRITE, LOCK. If you are returning > OLD_STATEID in those cases, you are forcing retry to > give the server the stateid-sequence without much > point. The server has the other part and can check the > current state regardless of the stateid sequence. Do we have a desire to provide fencing in the case of mandatory locks? I am thinking of the case that the client (or server) has made a mistake in its record keeping and there may be in-flight read/writes that don't match the mandatory file locking state. I don't have a strong opinion -- a slight preference for the stateid.seqid on read/write to provide for this. So, whatever everyone else wants. > So here is a proposal: The server always sets sequence > in the stateid and the client can look at it, if it wants. > When sending a stateid, the client may sent the latest > seqid or zero, as a wild-card. Zero is always accepted > but if a non-zero value is sent it must be the correct one > to be accepted (if it is too high BAD_STATEID, and too low > OLD_STATEID). The recommendation is that clients will > typically send the seqid on CLOSE and OPEN_DOWNGRADE > for the resons demonstrated by Peter's example. On the > other hand, if they only have one outstanding request > per owner, they don't have to do this and are OK sending > zero as the seqid. Yes. Spencer > > -----Original Message----- > From: Peter Varga [mailto:pvarga@opentext.com] > Sent: Friday, June 29, 2007 5:09 PM > To: Spencer Shepler; nfsv4@ietf.org > Subject: RE: [nfsv4] An issue regarding free byte-range lock state > > > >> -----Original Message----- >> From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM] >> >> If the client choose to have more than one outstanding >> OPEN/OPEN_DOWNGRADE/CLOSE for an open_owner, then the seqid is >> required. Because of hard-links, there are issues of OPEN upgrade >> given that NFSv4 requires that downgrade be done in the opposite >> pattern from upgrade; this means the client needs to know the =20 >> ordering > >> of the state changing operations. Then there is the race between >> OPEN/CLOSE that can occur, again in the presence of hard-links. >> >> Spencer >> > > I see. In that case, we still need the OLD_STATEID error (spec says " > This error does not apply to and should never be generated in =20 > NFSv4.1.") > > Consider: > > - link1 =3D link2 =3D hard links > - stateid1 and stateid2 refer to the stateid in its entirety (seqid + > other) > - same open_owner > > If the server does _not_ increment stateid.seqid: > client sends OPEN link1 > client sends OPEN link2 > server returns stateid1 in response to OPEN link1 client sends CLOSE > stateid1 server returns stateid1 in response to OPEN link2 server =20 > closes > stateid1 in response to CLOSE stateid1 client sends READ stateid1 =20 > server > returns BAD_STATEID --> Problem! > > If the server increments stateid.seqid: > client sends OPEN link1 > client sends OPEN link2 > server returns stateid1 in response to OPEN link1 client sends CLOSE > stateid1 server returns stateid2 in response to OPEN link2 server > returns OLD_STATEID in response to CLOSE stateid1 client figures out > link1 and link2 are the same file and doens't resend the CLOSE > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 05 11:51:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Tbk-0006xZ-GU; Thu, 05 Jul 2007 11:51:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6TPN-0006Oq-JR for nfsv4@ietf.org; Thu, 05 Jul 2007 11:38:17 -0400 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6TN4-0001j0-Pq for nfsv4@ietf.org; Thu, 05 Jul 2007 11:36:27 -0400 Received: from bfields by fieldses.org with local (Exim 4.67) (envelope-from ) id 1I6TN3-0000cp-Qg; Thu, 05 Jul 2007 11:35:53 -0400 Date: Thu, 5 Jul 2007 11:35:53 -0400 To: Benny Halevy Subject: Re: [nfsv4] Setting mode and not ACL tidbits Message-ID: <20070705153553.GB29867@fieldses.org> References: <468CA2FE.3040706@panasas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <468CA2FE.3040706@panasas.com> User-Agent: Mutt/1.5.16 (2007-06-11) From: "J. Bruce Fields" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Thu, Jul 05, 2007 at 10:51:26AM +0300, Benny Halevy wrote: > Section 6.4.1.1 in draft-ietf-nfsv4-minorversion1-11 seem to me to be > a bit too restrictive. The suggested model applies the group permission > bits on any entity other than the OWNER@ and EVERYONE@ ACEs. My problem > with it is that if the respective permission bits for MODE4_*OTH are set > the affected entities are allowed access via the EVERYONE@ ACE but > the information in the original ACE is lost. Applying similar semantics > on the *OTH bits rather than on the *GRP bits just seem to make more sense > to me... There's some strange posix requirements here: After a chmod, permissions must be bounded above by the mode. The group bits are defined to cover the file's group and other implementation-defined users, and the other bits are defined to cover only users other than the owner and those covered by the group bits. Uh, I guess we could restrict using the other bits instead of the group bits without violating those rules. I can't remember why we don't now; I think it's just inconveniently restrictive in some situations. Maybe the spec could allow either. Linux and Solaris implementations at least are going to use group bits, though. Other bits are virtually always more restrictive than group bits, so nobody will actually care if you use the other bits instead. Argh. I have to go revisit the arguments here from scratch every time this comes up. --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 05 13:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6UjP-00089q-TN; Thu, 05 Jul 2007 13:03:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6UjO-00089f-5W for nfsv4@ietf.org; Thu, 05 Jul 2007 13:03:02 -0400 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Uim-0003yq-0j for nfsv4@ietf.org; Thu, 05 Jul 2007 13:03:02 -0400 Received: by wr-out-0506.google.com with SMTP id i23so330627wra for ; Thu, 05 Jul 2007 10:02:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=HxodjGGYjrtUl89p4tRhD+okL73eteV3VgnrCTkv5EUnDdP8Iwkvfx6khu8RAcosiuamXRnbWUnvdr3CVYlpeGMH5c9HsXLE3jnNFAZHb+r4cewGapstwdYSU79gLGgIxmS5+HV/qUzBUyrM0oG5PevO2ozLischoJVYGMg7Itc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=JqCU8nyOg64hqnvEiP9+8GEWUOrTpoTmc1968g7Af/8ZpqpxDQbQSH/yheKnKWry5Jt4fqbo0rOacpUVYel7C13MT05cWi2SsxuWBg5xz7mzTpB0TjSTZqZBDD21T2h3NuO7N+VJpvI0DBmt6HWpK1guhPTtY3CsBm52dT4ZF3E= Received: by 10.142.14.20 with SMTP id 20mr597981wfn.1183654943019; Thu, 05 Jul 2007 10:02:23 -0700 (PDT) Received: by 10.142.116.20 with HTTP; Thu, 5 Jul 2007 10:02:22 -0700 (PDT) Message-ID: <89c397150707051002k4a7f4cd8te738d6e90144767a@mail.gmail.com> Date: Thu, 5 Jul 2007 13:02:22 -0400 From: "William A. (Andy) Adamson" To: "William Brown" In-Reply-To: <89c397150707031130n35351248re5d8b7a10571ad16@mail.gmail.com> MIME-Version: 1.0 References: <89c397150707031130n35351248re5d8b7a10571ad16@mail.gmail.com> X-Google-Sender-Auth: 7c61c4fa05e60670 X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nfsv4 , NFSv4 Subject: [nfsv4] Re: Fall 2007 NFSv4.1 CITI sponsored Bakeathon date query X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1928136918==" Errors-To: nfsv4-bounces@ietf.org --===============1928136918== Content-Type: multipart/alternative; boundary="----=_Part_95731_11253561.1183654942991" ------=_Part_95731_11253561.1183654942991 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline We had a reported conflict with the proposed first week in October. Will the third week in October work? CITI NFSv4.1 bakeathon proposed date October, Monday 10/15/07 through Friday 10/19/07 Comments please! (Yay or Nay...) -->Andy On 7/3/07, William A. (Andy) Adamson wrote: > > We had a successful bakeathon in Austin - thanks to Sun for sponsoring! > > CITI will once again host a fall bakeathon, for NFSv4.1 implementations. > > We propose the first week of October - Monday 10/01/07 through Friday > 10/5/07. > Is this an agreeable week? > > -->Andy > > On 7/3/07, William Brown < wilbrown@us.ibm.com> wrote: > > > > Hope things are going well in Michigan. We're really tire of hte rain in > > Texas... > > > > When you were here for the bakeoff, you mentioned there may be a NFS 4.1bakeoff at CITI. When were you thinking this may be? > > > > Bill > > > > ------=_Part_95731_11253561.1183654942991 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We had a reported conflict with the proposed first week in October. Will the third week in October work?

CITI NFSv4.1 bakeathon proposed date
October, Monday 10/15/07 through Friday 10/19/07

Comments please! (Yay or Nay...)

-->Andy


On 7/3/07, William A. (Andy) Adamson <andros@citi.umich.edu> wrote:
We had a successful bakeathon in Austin - thanks to Sun for sponsoring!

CITI will once again host a fall bakeathon, for NFSv4.1 implementations.

We propose the first week of October  - Monday 10/01/07 through Friday 10/5/07.
Is this an agreeable week?

-->Andy

On 7/3/07, William Brown < wilbrown@us.ibm.com> wrote:

Hope things are going well in Michigan. We're really tire of hte rain in Texas...

When you were here for the bakeoff, you mentioned there may be a NFS 4.1 bakeoff at CITI. When were you thinking this may be?

Bill



------=_Part_95731_11253561.1183654942991-- --===============1928136918== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============1928136918==-- From nfsv4-bounces@ietf.org Thu Jul 05 14:02:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6VfL-0001cv-1x; Thu, 05 Jul 2007 14:02:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6VfI-0001cV-8F for nfsv4@ietf.org; Thu, 05 Jul 2007 14:02:52 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6VeH-0003Yc-Ob for nfsv4@ietf.org; Thu, 05 Jul 2007 14:02:52 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l65I1nHF011079 for ; Thu, 5 Jul 2007 18:01:49 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKP00K01SULTA00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 05 Jul 2007 12:01:49 -0600 (MDT) Received: from [192.168.0.3] (adsl-71-145-136-1.dsl.austtx.sbcglobal.net [71.145.136.1]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKP008AEWQIIB00@mail-amer.sun.com>; Thu, 05 Jul 2007 12:01:31 -0600 (MDT) Date: Thu, 05 Jul 2007 13:01:30 -0500 From: Spencer Shepler Subject: stateid4.opaque requirements (was Re: [nfsv4] An issue regarding free byte-range lock state) In-reply-to: To: "Noveck, Dave" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 5, 2007, at 9:35 AM, Noveck, Dave wrote: > >> I don't have a strong opinion -- a slight preference >> for the stateid.seqid on read/write to provide for this. >> So, whatever everyone else wants. > > Allowing the seqid to be sent or not as the client chooses > allows this. What I really don't want a scheme that forces > the seqid to be sent, even when the locks are not mandatory, > which is going to be a commmon case. This is fine with me. The final question I would like to resolve in this thread is the one I asked about the requirements or use of the stateid4.opaque portion of the stateid. What are the requirements on the server about the contents of this field? Once the stateid is established as a result of OPEN, is the server allowed to change the value of stateid4.opaque as a result of subsequent OPEN (upgrade), OPEN_DOWNGRADE? The same question applies to the LOCK stateid and the sequence of LOCK and LOCKU operations. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From chocochipcookiedp@yahoo.co.uk Thu Jul 05 22:15:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6dLc-0004GI-1V for NFSV4-ARCHIVE@LISTS.IETF.ORG; Thu, 05 Jul 2007 22:15:04 -0400 Received: from [60.19.163.98] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6dLb-0004yl-2R for NFSV4-ARCHIVE@LISTS.IETF.ORG; Thu, 05 Jul 2007 22:15:03 -0400 Received: from irdwcnfm7 (unknown [159.205.214.114]) by smtp93 (Coremail) with SMTP id mTBtnFB8240R2wGs.1 for ; Sun, 06 Jul 2008 10:11:41 +0800 (CST) X-Originating-IP: [159.205.214.114] Subject: =?iso-2022-jp?B?GyRCOiMkSiRpISYhJiEqISkbKEI=?= From: =?shift-jis?B?bm9yaWth?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C8C1B2.D4664230" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C8C1B2.D4664230 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: base64 GyRCJSglcyVIJWohPEw1TkEkRyEiJSglbSUoJW0kSj13QC1DIyRIRD5AXE8iTW08aCRqSnxCaiRO JTslQyUvJTkkN0p8QmohKiEqISobKEINCg0KGyRCNHw0VjhCRGokQCQrJGkhIjojJCwlQSVjJXMl OSF5GyhCDQoNChskQiUoJXMlSCVqITxMNU5BJE8kMyRBJGkkKyRpGyhCDQpodHRwOi8vc2VyZWJ1 LmJpei9jYXMvP2FzMTMNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KGyRCIUolYSE8JWtHWz8uRGQ7XyRyJDQ0 dUs+JE5KfSRPJDMkQSRpJF4kRyFLGyhCDQptYWtpX25vZGEyMUB5YWhvby5jby51ayANCg== ------=_NextPart_000_0006_01C8C1B2.D4664230 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby0yMDIyLWpwIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRN TCA2LjAwLjI5MDAuMjc2OSIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgZmFjZT0iTVMgVUkgR290aGlj IiBzaXplPTI+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPg0KPERJVj48 Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIA0Kc2l6ZT0yPhskQiUoJXMlSCVqITxMNU5BJEchIiUo JW0lKCVtJEo9d0AtQyMkSEQ+QFxPIk1tPGgkakp8QmokTiU7JUMlLyU5JDdKfEJqISohKiEqGyhC PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj48L0ZP TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9Ik1TIFVJIEdvdGhpYyIgc2l6ZT0yPhsk QjR8NFY4QkRqJEAkKyRpISI6IyQsJUElYyVzJTkheRsoQjwvRk9OVD48L0RJVj4NCjxESVY+PEZP TlQgZmFjZT0iTVMgVUkgR290aGljIiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPSJNUyBVSSBHb3RoaWMiIHNpemU9Mj4bJEIlKCVzJUglaiE8TDVOQSRPJDMkQSRp JCskaRsoQjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0bJEJBV0JOGyhCPjxBIA0KaHJl Zj0iaHR0cDovL3NlcmVidS5iaXovY2FzLz9hczEzIj5odHRwOi8vc2VyZWJ1LmJpei9jYXMvP2Fz MTM8L0E+PEEgDQpocmVmPSJodHRwOi8vd3d3Lml3eHl6LmNvbS9jYXMvP2FzMTMiPjwvQT48L0ZP TlQ+PEEgDQpocmVmPSJodHRwOi8vY2I0MDUuaXB0aW1lLm9yZy9zZXJlYnUvP2FzMTMiPjwvQT48 QlI+PEEgDQpocmVmPSJodHRwOi8vdmx6aC5jb20vP2FzMTMiPjwvQT48L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Jm5i c3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+DQo8 RElWPjxGT05UIHNpemU9Mj4bJEIhSiVhITwla0dbPy5EZDtfJHIkNDR1Sz4kTkp9JE8kMyRBJGkk XiRHIUsbKEI8L0ZPTlQ+PC9ESVY+DQo8RElWPjxBIGhyZWY9Im1haWx0bzptYWtpX25vZGEyMUB5 YWhvby5jby51ayI+bWFraV9ub2RhMjFAeWFob28uY28udWs8L0E+IA0KPEJSPjwvRElWPjwvRElW PjwvRk9OVD48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0006_01C8C1B2.D4664230-- From qnegj@new.rr.com Fri Jul 06 06:16:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6krJ-0001mW-M7 for nfsv4-archive@lists.ietf.org; Fri, 06 Jul 2007 06:16:17 -0400 Received: from [83.242.163.82] (helo=pfcvh) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6krF-0001cn-2X for nfsv4-archive@lists.ietf.org; Fri, 06 Jul 2007 06:16:17 -0400 Received: from qey ([67.82.231.206]) by pfcvh (8.13.3/8.13.3) with SMTP id l66AK44f043249; Fri, 6 Jul 2007 14:20:04 +0400 Message-ID: <468E1667.3020703@new.rr.com> Date: Fri, 6 Jul 2007 14:16:07 +0400 From: Edith User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: Griffin was first introduced to the subject of vitamin therapy for cancer control while on a fishing trip with San Francisco physician John Richardson, he said in a telephone interview. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Brokers Move On ERMX! EntreMetrix Inc. (ERMX) $0.18 Heavy trading today as ERMX announced its launch of digital support tools for its portfolio companies. Brokers are getting ahead of this steady climb as they grab up large blocks of shares for there clients. Look at the numbers and get on ERMX Friday morning! And the website again is silverbiotics. In a double-blind clinical trial, zinc gluconate lozenges significantly reduced the average duration of common colds. The Wall - Short for Walgreens, one of the top street corner pharmacies in America. com and HealingFoodReference. The information on this site is provided for educational and entertainment purposes only. But if you need to, take about lh teaspoon of dried herb and make it into a tea. These are the type of headlines constructed by news repeaters. View the entire collection of CounterThink cartoons right now. It is useful in the treatment of goiter, obesity, cancer, inflammation, influenza, common cold. So it's clear that they're not holding back a control for cancer that they know works. In one study, over seventy Dartmouth students sucked on flavored zinc-glyconate-glycine lozenges within one day of the first sign of a cold. The virus gets on one person's hands and can spread to the hands of others. Peppermint tea may also be of benefit during the common cold. The first thing that comes to mind when treating a cold is that taking vitamin C will help, and this instinct is correct. He wanted people to take drugs like they chew gum. It is also useful for asthma and emphysema. "When we run down our immune systems, a cold or flu can arise to detoxify ourselves and bring us back into balance. Farben, a German-based chemical company and financial backer of Adolf Hitler, joined together with Standard Oil of New Jersey, founded by American business tycoon John D. Instant recurring revenue! Though doctors still debate the clinical studies that have since repeated Dr. Adams believes in free speech, free access to nutritional supplements and the ending of corporate control over medicines, genes and seeds. For certain cases, Dr. there's at least one really good article for me to read every day, and I read it and follow it. In the case of recurring illness, you feel repeatedly sick. It is also useful for asthma and emphysema. Good food sources of vitamin C include sweet red pepper, broccoli, orange juice, tomatoes, and berries. Your use of this website indicates your agreement to these terms and those published here. This core problem, according to Griffin, cannot be solved until we get the politics out of a lot of other areas as well. Click for free evaluationThe world's best AA battery chargerSave money and resources by using NiMH AA and AAA batteries. Adams is a trusted, independent journalist who receives no money or promotional fees whatsoever to write about other companies' products. In the meantime, it is up to each individual consumer to take responsibility for his or her own health and wellbeing. Hilarious Health CartoonsView the entire collection of CounterThink cartoons right now. We respect your email privacy. You have a special place in my prayers for your gift of this newsletter. Pauling's original findings, most naturopaths would say this is a good first step in fighting off a cold. The virus can also live for several hours on everyday surfaces like counters and doorknobs. At all times, your immune system operates as a powerful defense, shielding you from the most common cold and the most deadly cancer. Prevent Prostate CancerBeware of chemicals in foods, cosmeticsProtect yourself from toxic chemicals in foods, drugs and home products. Farben, a German-based chemical company and financial backer of Adolf Hitler, joined together with Standard Oil of New Jersey, founded by American business tycoon John D. The information on this site is provided for educational and entertainment purposes only. And why do some people regularly get colds and flus and others seem immune? The great thing about these items is that they help improve your immune system, not just cover up symptoms, so you can decrease the actual duration of your cold. It remains illegal for doctors to prescribe or sell Laetrile as a control for cancer. Some people respond almost miraculously, while others get no benefits at all," writes Mark Stengler in Natural Physicians Healing Therapies. It painted a picture of a world in which an effective control for cancer existed but was outlawed because it couldn't line the pockets of the powerful pharmaceutical industry. Reverse Prostate cancer, naturally! "Seen from this viewpoint," says Dr. Good food sources of vitamin C include sweet red pepper, broccoli, orange juice, tomatoes, and berries. Pauling may be gone, but his legacy lives on. The best method for using menthol or peppermint oil is by applying commercial preparations to the upper chest during periods of rest so that the vapors can be inhaled continuously. The best method for using menthol or peppermint oil is by applying commercial preparations to the upper chest during periods of rest so that the vapors can be inhaled continuously. "A person with a large sleep debt is much more vulnerable to infections and other illnesses," says Peter Hauri, Ph. From irfl@qwest.net Fri Jul 06 09:24:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6nnf-00053U-4i for nfsv4-archive@lists.ietf.org; Fri, 06 Jul 2007 09:24:43 -0400 Received: from dialpool-210-214-68-146.maa.sify.net ([210.214.68.146]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I6nnZ-0000Uj-BP for nfsv4-archive@lists.ietf.org; Fri, 06 Jul 2007 09:24:43 -0400 Received: from gan ([145.35.79.179]) by dialpool-210-214-68-146.maa.sify.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 6 Jul 2007 18:53:58 +0530 Message-ID: <468E426E.7010704@qwest.net> Date: Fri, 6 Jul 2007 18:53:58 +0530 From: glamour User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: Re: Invoice_7120342710.pdf Content-Type: multipart/mixed; boundary="------------060206060405040406080601" X-Spam-Score: 2.8 (++) X-Scan-Signature: 4c463dcf97e2b913ab242796279c24d2 --------------060206060405040406080601 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Transfer-Encoding: 7bit --------------060206060405040406080601 Content-Type: application/pdf; name="Invoice_7120342710.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Invoice_7120342710.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDI3NiAyNTRdCi9Dcm9w Qm94IFswIDAgMjc2IDI1NF0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQoyNzYgMCAwIDI1NCAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDI3NgovSGVpZ2h0 IDI1NAovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLjLjYTCkbweA3AA3fzjrDjA FZglQpklG43eIpNE5TgOGwAE1rkbYf1heMRXS6qVSgbxvF4gdwAApeFZqDCFJNglxr8ks42ItsiF zktzXQAusiZCcgeKiFSyGRgQpzwpG1pgQ2FN9eGd0uhguiw8jzmSiJv1kMFNQTlngVrE2OhLwuN6 ga63UN31jhQmgt0092hfIN4A2elgWngVj2teABFxcG1+tkPF4BNwmfy+hsvVyW+6QAYVcgTj0O7y PKycJz+e8po/Vl+uerysvcg7qLuvDxPEhb9oM9atPerboII7q7u8kb7tE0IbP0XCBBfDg4Fw86oQ A0cLtUgTKsLAsDoStKyw1Dauq2rD3vhEcLmQhLCII1MLQQNDsIGrELsuAEbss6rgR1CaRNZFwABf JqBD6gkGRIgjQxE0cFSqhMNLLKUGyG6ELNYrLKxuhESgA/QASaF6Fq02catnM8Hr60rQSUk8my/B zVytGrVxI1j1oE88XoTBk60VRUeTChsOSfF0+UTNFHTrErQzu0DzTYXA/IJKE8o3AE0zjRceTSvq DwNDlCjQPo+xlNDVSFMUt1tQkDQNN9ZSFWqD0E1jSOkwYAV28UOFxLtYSnUSPUE8tf0FTSBV3Y1d MMSxLDTWT4V/YFaVLYaCxUggmrweBLIhX1UtW+712tY1nJzElc2tFVzsMAA00hNyVSReeA4FgeCY Lg2D4RhOFYXhmG4dh+IYjiWJ4piuLYvjGM41jeOY7j2P5BkORZHkmS5Nk+UZTlWV5ZluXZfmGY5l meaJgPsL2Yol9KEqTrOkBI5jmQ8+NDKQ+kOAQADmBIE6VoV5YWwYV6AOclwxNV2ovfyJjRW6SulC 8E1w/AAanqpDkOFdrsIeN033hrCbYgRZDTJ2tumioXj9LtyoPnaFvrrldJRNs2TUgcc6hYy47dDc 3DTur04ZSCCDSurmTtb6HqcvvEnjbRZIHDnIcjyTrWigo/X9ZSGcSk1XyBzjCoH0PHdIgmez/hZ4 76vtG071WtzXWEGKfsjqksFYV38F40llbTDPF085TWgm7gBnPZIVu9tAB3kdPxUyI0I311et53u2 r71Vd0gdP4WtM48Kgc+IGwQU3R73khWQ+qoE1UML607GfWEQdVpB1KHVdy618CW0MqeeuRJtRA2m tJfA8dB5ZVDN2Sg/VhD73DJRSAkkgz/CCBzAEGEMIfU6GWfiiMEwKXWEChAs0hCAyCNMIc/JFzq3 6QJIlAEgaRlGGdfm4dGb2DsN/YM8QcbOQ0OsBe5h0rW4hRDQu8dAZnEIv0IGoaCLdnmpQMqbchqE VJwiIS5BdZA3LxsAAXM5D2EpFYaMmsXCrSpORjCwSCDlIxSBOmPAEY/h/EDTo3ggzo19oyVgftNq /XHSMIHIUt6k0GOYIOtyO0X3RKHlAQJyxEIqujjhE9PiGnKSrVa81usmmNKxUTJB98rnIHUOKX11 Uk4DobjgekeEGCEKel8QoFLwXmStVa6RwJnUfkMl+R+Z7IJmIDM+U8oQsgRgjAAP45jXWskTmmRx ULNWFR9nNOmdU652TtYeIedzKo9kXdcPAyE8WDqQAIckucOCET3OmXl3s+F5mchwgY8hCneOJKoQ OQ9BGBniUIqchtDwAAjbovydFEEJrfUo64hLWwCC9M3RxgTxSCUWfYQs153Z/UmSUW8sRBIiHZOD F2RUAn1UwWcbcBxyUIRupeZsyMBJw08O8hFy6SAmxdWgnZttSGA0volROqVV6sVZq1VurlXavVfr BWGsVY6yVlrNWetFaa1VrrZW2t1b64VxrlXOulda7V3rxXlURXCnviJ6H2DYAGmkwaCTNoLTIdKi baac/xKqrETBECIgtgyOxAIXYkmNiGqJRVhUco8syBR/snYggQAmhqAQyAB4J9jrweIc0xqsFnsK pik9eQwNU7EKWVasgQIgZ2YABaZoxBIHuilGPGQxIkpQveBIAvEhwanWmwgEnakLIgAt/Yh/0dGb g2aM0eSa+3uoFIS/eKLjgAWRBnBRoM8EotFZzaqXoABLHFXKDcrIfTBEKuzYltCsGb2caOGiEDkF tG+WqE1tV+LLOisjZIgVsGnkLt5G5xBAgl34K3fozxZZAE8wlPDADRSBv9aXf6Cb3yBXusEQuCd7 GhWnTFgC9127CrmILjeyg8iBvpIVB5+tg7t1Mf5iYgeQyFNUv/bO718SE3khPBQgY8nGPmhNcAnZ rEpACsPZgFa2MS4RII8q+lLyC4sfpB67WE3XYvzEQR8xsDO5RIXdt/+OHFNKyO2kFePjjApsosDG jScT2bzri3OF9XMaAthmmvxOMXzwzcQR2rdiB59vqQU1JtML56XIvlxrWwZ5ozkQM9ZrFDWe06+u HC/r1kCz9qY2cGrL3tbTgl/JC84r6U3rNB50SgK7baJZukkpROXwQZ1UyypykGV0jmJjW44VLbJU /Zjdn3ho2fNCSU1TqM+U2aOB8eSBofsDs7HroW7ulIRr1NMPXhLycSvEnjlHb7IR0uHcsNYvEN2J HyW1Qj1bVNU9WZCLlXx1Vk2unRCnAwEuJeeXdoXhv1nGQWU0t9qELj+k9Qr2UGHrWzuqjazn7kTe lBhIV5yNL93YShz+kyELnU1U8iRnl9FxeUm50bz11ULYQ8rUhOKF2PJNCiK5MYVFxCau9W1euodR 6l1PqnVerEc1URDD5C3m9QvmR7hZFgX4PIc73BpCOSkL1uSZVt17BNNywSq35DejEY6/ZrFcE0VT YPaQSwCLYRcse32PCGEcQq8K1kDrRBdXkOmwR5DnbvDNAzIJaxcGEsEkx9j/jBG9A+WKkfjx6su/ rKeZerucYuv2j8pi/0J17dR5w/b/tPk8xvQhwU/vpBdzkYthnx3BhjpK9IGfIXXXb6Pmh18vQIM+ 52UeV5s8nFzg/IIE1PRsFPCeFIYzs9pWTRHrNe+nIUFLB9u0CQaHFE+z5wvZ+Z69pMJ30qjqYp/C wbBvBSfIgucSNo3tKk+n2KWkJQCp7CBDHMisvrBvotFDpnnAVvdlvDPI5kcFzkIKSvrgmmgO1iGl KPjDeF9HPDgwECDsWP/CDFKKJqcDuKgoctEt8IbNTDuDwKQMzGtJ9BYwXM5NeQSQfKdEciwpFJSk NgCBYg0DdwSkjozlyCDCwi6uXiFDuwRDpDqDeNSkchsCCKGkBqNqXQmvunEQtHcHKnRIIkIomDPJ 7Qrj0COjXnMFdqjH4jSQ2iBQxiqqHCBJuFDp9waDwKdksiGQ7iBKVCBqNAXw+iGnXFgjSqBEDiwi qJDJDptqMG6G7J9qAFVqqtTosu6iqxJB/JtnrQdo4t0ISE6uRKQKGiOKEKEl2ERBxhyKGirRJQ9m 3tLAAREl/KDs5iDEyP2pKvOlDhewyCGObCuRZCBCrJuxJqMF9oDxEKRjpi6HvMVFZlUisxZRViEK NRcKSIpjOQRRFlbkAEGRIRaKHptqMiOkhOwiHxDwMKiDHB4EDvdFvERksCnBhDxQhKQp9KbqACpD xPHvESCDWyBAmivD2mvRywtxlnEBhG6xoKRw2Cdi7C6whCrkGPMj2R+RVixDSsAiEqiHcHMCrLqG Jq+OrijjBi3RtyVihAbIyyYSaSaybSbycCbyUCLqrPemPvwExkRilqBl1lalblwtHs8NytzIPEgu siQydlAlKiUFgyhExShSno2xjCMwLiJyqyqjoOnKFP6nYx7lonNO6N6CEQUSzk5SpCDxPCPywFFD pNnkckDyur6RuuKMmSztHxOlzN6HpImEnRfGvFAkqlcnEKQKQoZn2krObRNFrsEzBvkpBE1FXlxE qy5xezAzGNhy2CNFMnjt5zFwhl+kuuElZBhEMzNLPNttcNhpeTHIRzITDxTRAHFQbryxfE0D7iFT Bm3N2TUonIvoozXFaSlTcoFQUFIj9LXCMHXF4NYM4mtzrF/CoHXKLBIhIy4CGtoxRzCn7CDRChOT ATgP3JPpQiGg4TezOzFPBkXm7ivAmyXiBTuzvQZtVtYO0CCs3T7CMDzD9QdJeRoRDRgxCJuqaT9E FFHpFtKQ9KUiDKalqzfntnrF+l/HIJtRbCFrXEKjLj9hYwoxhAAHQ0OqHxC0GE/JPT1UXCCwA0FQ 8iO0MiCo2JtRCRQUZ0FKVKLMeCDojiDHSw90e0E0d0jlFtm0CnI0ORbRQUVTyB5UpUfovzaUaiFq LJD0n0UiEUqDZkoUMnr0Y0kUiiXUdKHRJMeUpALrSGnBpBpHrmugHAip0Un0c0zxQUpIcsJQzG9k PiEpt0zvfGgg5hpCO07RmLkgAU1ssU3kONs05U6G50OKU1BVE1FJu0ph5AL0zVMPzLMBpHiH7R9y HyHUoVK0eh/U9VPs7EYx9KHOmphCjpDVViD031RCCirN5xIVPTyVLVNVOMj1C1DCXU2s0xgGaVjG QCw1Tp0yoyc1oVo1pK8IV1ppECdGrqTmFrp1kCFzCQ3BdAUx3O6HsD3PdS4iJDIJcDTnpiNj5EFh xpDIcTdzoFyDaj2VuiTLpkwE7PjDUSsj2Pdklr81618OwitCsR92Av7yNi0wKDgoYk8Sxj/EQyGj 3x9zGJ/jHIYlbD3U3oF2AydlKO+SNwJv9iTiuWSkaFhwQDykGlYU3sbu3rBIEyUPMzziJLKO4WEE ZRylE2b2WIuWIkSo7A+03vED3R3FSSkjRkAFmBpMu2dQUyOLqTRwkjX2JCSjABhH4g3jIDkE8JHC BhAspLNLML2pZQUiu2uDQjno5DPWmCEsJGqpZWUwZFv2hgbFErAPWVlIEWLIgP82viGLtrE2zLtz oLLHNGyWECCWyCTJrEQu/IkJaspMxIUGhsnXGCDGdj/WUpHnqiJF6ok0VkB2Kt+iDPuVhLhE3tTQ q2p2iiGNAn/V6j1k+O6oElDFPmtgRP0iRIgEoLJMIPysBTkrQoakB0VH6vSpiEnMHvGiImtjqRCk fkGODO2r1Wzz3LQiFro2KW6r40lCEmiDRLdsPrkB/Lozx1+XuCCPCu4Gg3WO2X3NEH/slsAk+BDs CUNA0sDkkMXwVIooD3VX6nsDL2C3ONL32C+4BYB3hr/XMkvsALwHbX+zQiCsOE1PZPI1PtDCFX9p KDJEUkpuw4Gv4oTm0I6C0sAAAOhiQsQsRLusaJ4GltEG0m/simlMhNbrFtLhD02sY4WMmmjsWO4i ENCmnsqCpM44f4jXZL2sXkDITCN4ZYEECG4iKVlYIjRFYYaYaslOZEl4WH/2/CDG0VWiEHT4y4MG kLCvDnEVviDNFNktGGgFnYkCN424asnsFYXVrP+pm4/5BZB5CZCmOMnZDCZzaCLyyCSoWCiA0wWG UOeHrpCVPBkCsLHvViHOtiG5MULiKUrpRCDhkZS18pGiNJCIEOuPaigNjJBvQn7XwFXLRJRJRzdi FJmCFLLJVIwqX5RUhHLOHjalYn6JaJfJoxqjS3dplJ0DJlCZiiDXxKAimJCmetTkjKfrQ4N3+HLj UWGZc1KKAiyLPZuSS2QWDOMOMiEpwAbIzZaNyZbONYRJrnYingmueUbxRFwDbjcTwxDJRjqk7kwC tR9va5yDZgHJICXWfTaokPVRoLrMIT2piiEaG1XVn6IUMLe0MOXkSVx4SJUZ/wzJJL1A4JenSh4H fuzpZrAnrsPrfaTlIG6uNOs6Lj9A4S9iWJULUpQTrCDrKMbnXWM32FKZp0X3LYWzcSy6QX2pQoI3 oX7MvkkFCWSkYqQ5QLJsxm2YsHjxgIo4N0C5WiQTrrwr1PJr2zKOmu+EgWCoNm7va3fHFJpvFNyx /LrQXs7myttjsOFpUk+PAasCB3Va5HXD/vA3JvB5XrfY1iTvIrfPnodPoo3WKSynsEW5uYCaniCa ot231iuO/0S6xW5O8DCvXn7ERXmYHPnAE6IqNrtMyRTwZIkHmL0vGuSvGrEs3ZcCSmhG1PNiLvsY dCEbWU2wG5GwU22jpC5nHsfLYLMPt7OnN6msenurMLSOxiB7pCCuB6Qk0jIOultF1IdNCmmbsiFN MLFi42KbqF5sDkBwIPvqWRqCGDIYpic7JiJySDqkDDfwDjHBdITQFiGwI2eSwv95JK8nb5E8GcG8 HcH8ICUHtcIiW1ZCBjtmQpYCXcNDH8EubucCGAii1DGDg7eEV24iJ5AiaKqaiCVyiIbjqcLCH8OC Gj9HGLGb2b55vHZ8UqXvv728d4r8WiX1YuVTMUMEPbUWeMGyZEbi7C9OgDUWskWPBaLarSscUTOy 3Ztm7T2j9WGcly0CCqmNNDV6ekN8klDcllvTbkCKFkcw5CcUBUwFlHq26leykZSBOBkDQkD84joI Hpa86nYCFICkZisETiGjZuDlJInXGyrFBRgFCH5HrdBkvxyoClgyOcykw9A6xiVNmviFbFpFLH22 s8qlOzn9LlE2mdDSrV0anI6WgTHnf8aowPebZnfzXS/Z2aRyfCaXFEwy5t9FV5/tzygda9WjRz4M 85dzbdSH2lMSxJhymZolLDZ9azbUV8WoNlKcsiXdXdDNH4sY0xDWf3tlMdXOZzYTdId9o91IBjPN 5nBlEE4FUqn9sRAzOm4y7swaLTI9viW98DVDyS7TA449LExlpFgl68ZFzMq6SZFlwSjFpk7F4lju sEtxOy6zYEVTQR4dC+F82iZlxzKOGFrtc6kCDTWCy+Fd7j8DBy8cXwPWE9FIszF9+G1lyt/5NiO9 6Fq+UoD86iLlh95EJ5OiDA4TuAHUKCTRaO2ekKupLUPcQCVh/B4+m8Ketet+ueuijRJYs65GTpnj tCYhxpEiMYrCKewCJ72iUyKiWxM1fVF1a89Z+txCTgBIU4DTIQnb6j5kB1mVPU2bGiGT7F0KXco0 E0p1giWVesfki53iNAa+niBfGMIoUIUukkFb1Txy8o4+5CLjbmw0G8xp+HMU80f/CY7CBIVoy+sj ibuCpfKUU1gMjrgoVe1CN1aVammoUCCfXriC/WQZwEoj9e4CC/GLE+9IV5HgATzCHIgA0V1CBfae 2VF1OPso6dEobv7CDH6jlVUUpvzLS1rveA0fh8TCELcCCUqNEM7E+TzWACNLYfmIh/Rvw/0vvXco orV9BiAP5/ACCQWDAABGE+n1kJyCDaDCmCPCDxWDH6KmiBgB5QQLhcEyE5wWFw1OQ4ADY0CkUvCK RYAOOYQVcQZ/PKOwWRAKEwWUSmCxKKsJhOOjTOkAALzqEQZkQSfgChAB4PGp0msVmoScbV2Cy6CU JhH2jUegxk0Quj2VxyGsmiDvGDH2CTKtXS63mCIeCWmTVGWQeWWOzRYmwa4Qe7QYVwaTpyuxCJ2e CXiYwRhQbDwW01rEgCHZKwwS5QXM3miVrVViq1ap4vTsIUk3aZu9REUiZdLqhWWBVmr5ez7UU6ek bsU2bFrrJzDjaaibPbRWjV3A4qK8yvxayTJx6mpbXN0S2RETVldS542DXcW8UaieDaZjwav7QXF8 L9bH8Yvct27SpIqyyqKy/IACa+Kipi6rRKQsqCGkaSKHiqwAPJCD8KG1RdBM678IXCSIoMtjlO/B D6wyqT/wCh8HJm4qixMwsURSuwbQ++77RKu0IMiqTdQA86UhtFUJDmOa3JCkMaItHiCus4MdABJk GR68q6ywlKWSDHUlrdKzCxLKcyTLM0zzC4wbDe5kOqFIqZIWpMvgSAEkEOsisKIyI3zRM8+RaFKu ybMkxz9Q9EUTRVF0ZRtHUfSFI0lSdKUrS1L0xTNNU3TlO09T9QVDUVR1JUtTVPVFUqwSyX1VV1X0 gNCa0wr1YVs+71RXKVK1bHQ0M/RqvMkz4XgAF5cVmmDZwRCqCjSF9oWLRU5VgSxZWfaCCDTbawNI wNBMiiFZWTS9wxe7iLIlZs0VrWQAD9aNkV+yqyvq9aqoIFdoheNKCEtCraqTcaMJouFqME0s/0mS 1/ni+ddXAh95lxeFjJredJMjYF4Whcl0hTCtehWQ8kzqggwjDhyZq9jCCWyAGMKOPrMqE9aCsbO0 ljmATSOmqVzKQXFfrU6CWXWABLBWxqRpgJtvzeruN3irGQZtm6+TApCJIg0ViYKAGD5m59H44P1k RIrWR5KgyFKhF1wpgF+zaFYD/NI5ucZNk6CGQv7JXOAGKWhgjnJZqqDaSgmTZ3lCGJhcMPJrsuz3 oo0CIttUloKhW+pOpNkcIvsNMxw2EwLSbuoXAlpKzy6Hu2qltwAmdqWBVt+2NbW9gAhsoLDe9uxa yq5qQeFt2wgx5oKp7QKDXYAQC6/U4P3KsjCxzcOb2nqZhcfWIpfvWDSXHlUljlooN8Sk+Yg/cer4 8VIr1nWfffp4BGgYbrop6jJalzuH3LOLKZZWT5ykPufuU50avYAtoM4QR87L2XFafY6d3UEykFwd CsZ9CzgAP2IIP4G7vIKqOfnAElw8EckWa9B9bZVD2FafUV9wx7mZF0LgxSDkCIUrNBTAZly+ykuG MIXYPrE2KviV6+kgrL36EHVa890UTSDQIKS/OD0MDKNgQZDhlqjn8HqBSsAk4DisBphSS8waVkLj CCbB0iquQ0K1IIA4uC7j7lsbGmRX5NWXvHhghSIiC35L8W2LIgkYSqlXMfHaA8aIUlBNS/Eg4sgR yXH9GqOZWwAR2hyLiIUgFIoQUJDIF4IjWDwR+k4tcpVbkEBmHBYsEiDqDP0oYkkX24rQlRE1bMop WJYRVDgOD4ZaSvmQqOXEyZmTNVHEePEzppTTmpNWa015sTZm1Nubk3ZvTfUq4BWAI5wTlMNDWcUD iDm/VVE8+06ZzKqMjKQmRRDbEChHIVdhEEenQYelN2ahZ4zMMyYeEc+AboWK2VF2aAY0kGBvRGNh Q57BNoi/mhMYzLCcjMEU3RBTdvQV7JGEJ3jFoQPrCGgcyaMmOKiQah0aSXoVYAbZhxEpKEFoSzAu hDiopDeggBbsMKaOmABPkqi9WaBNGxCKnb2KVyvAcDYItMCZqtQDSFXUqzR1dItGYACQ02kGpHEs ghvKvOvIK0515oqOHZqjK+sbsCLIBqAUBXS9yImZc8TA7RLyKK9dM8J31aQAOmJ/VWu9hKzVxVTE s4hV1wx3K/Go/staw1XXws0w7ToakGnEwk4yhqgHMVbUOx0yLPWgY0+laAcGLoYla0B5YnLGkEtW oKvBKporGthF+UitVwlPtshSmh4kpTwtSqJqKU0f3CK8k25SOyyoOufHSWp83DJEa4/K5d3zcRSU ++dj14LzW4n+qU7qB7z3tvde++F8b5XzvpfW+1978X5v1fu/l/b/X/wBgHAWA8CYFwNgfBGCcFYL wZg3B2D8IYRwlhPCmFcLYXwxhnDWG8OYdw8mggIKZW5kc3RyZWFtCmVuZG9iagoxMCAwIG9iago3 MDg1CmVuZG9iagoxMSAwIG9iagpbIC9JbmRleGVkIC9EZXZpY2VSR0IgMjU1IDE0IDAgUiBdCmVu ZG9iagoxMiAwIG9iago8PAovRmlsdGVyIFsgL0xaV0RlY29kZSBdCi9XaWR0aCAxMDYKL0hlaWdo dCA5OAovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEzIDAg Ugo+PgpzdHJlYW0KgD/gUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUriL9fz+fT7fb8mkvf0siEvfs7mk1nckfj9fjhd7neD2ek2hk2fj7fr6mM0nc7qEzoL0ej4b zhdLccldd7hc72dLkejnfD8fL2fL4fL7fU4uUjdDtdadVSpXC1W70eT0h7vdbydTmdtLl7yez1tj xqGMeb1eTtedwfkGc7kcC5Wi0VqjXDgbbjfD1fD0eDzoT9hNSdrueTzez3hLWcTWRitV16XjrdDu eLxetSg1Nfi3VDHS6HWDFXzSbLgcqKT6tWDAYLVbjiOyPUJ5SygRrETyVYKiSq+UjpeTvbTicN1w 9z+kefD4e6cUStRaXUpoGsbRaGMYJZF6XJynKchlGIXpdl4VxqmybBXl+XxQl0WptnQcRjHAZRVG 0VxyHkcpYGmWZdF8U5nGEZRGEMUg8DqTBuG2cqDHWdR3EYS5SEOSpQHGchzF8XhcFeUxSGGZZjFb CxsHKb5ZmiX5pnQa49FkRZNGWUB7n4eyDGMZRmNmesymmP5Fk8RpQleapum+gybGOYhik2TpOHMd BznWeJ4FUZJclwaJenIdxzlGY5XlCYxVK4cZYlWXJpmoaybG2bpxnTHb60+ja2HsWBjFoW5lF0b5 ym2WRcFObRsmoc8OGWY5fGgaRjmicJnk6YROFeaRYHSeZ1E6YZOEOYZDmWcpmGGa5lGsaponMcZz EwVJSEeVpLm6cJuoMdh4nUXhklqXhlFocR1G+Y5sGGbZzGyZRvGUWZqFmYJtGEYpuzIcZnkcYhLF eaBSHsfTAIKZppGYXxaFcWxZlTfRWGmbhoGga5lqUgSbGbexbGaWhzHfRB6HcUJjlIVRkFUa5yG3 QRXFeYpcFYW5TkkThNFIU5MnkeB2nOwp4aFUGkoudh6nYVRolSXRrludB4HOVJklI7JgnflJXGQW pRF+V5cmYY5ZGQYBKFgWJmmwbpOlWWRHEeTJlmSZ5TFcWhSFYUhuHKbJWmOU5amoWJ4nseCDHEdp wF4apcF4ahcG+dZvGSbhjFWYpZHMdx0G8c5xEuWJYHqe573YdZIFQWy8L6xiDLafBrHCaRyHWcJd mmWxlG6Y5gmwXygsugXil4aJgE+XWvmwaBuHMchRl4XxrvgZJsG0ZptG2Z5sm4aJjGOb5sGpt5n9 QeZ5nweR7n22mlfkiSbJclyXpmfZ1HkdM/naVMdI7x4LsHYPAeg9R3jzHoOYdY7oFD3HlAUdA2Rv j1OAVN+z9R/P3JsTcgsHYNk6hBCGDhMR9wNHjCODBO2PEKhBByEZA4NQbhZC+GELX5w5h1DuHkPY fQ/iBEGIUQ4iRFiNEeJESYlRLiZE2J0T4oRRilFOKioCbD6LUW8fLxYmQsKnF0nY9x8D6jHFgoQ9 x9MJH2PknUWCoRZH2fd+Bby3RrKCayKpF1RCiF8KsRgtBDjPHCMweI7TUwNH4VEoJbS4kUHCOEbY 1xqjObcM4eY92FkEKsPkfMjSFFTkiOEcQ3kcEUGuNwaowxrDKgc4slI7h3jvG4N8cAlxQCiE6KgU Y1RwDTEmLsRopRgCsHAOccYnBeiZFKL8UAqBgChEcKsSIoBYijFAKwUQ0BnjahZHkihUxUijFcJc SwmRyDnHOKESYqRNiLFGNMZ8khsDYFGKUTg2BrDQHi0Ibw5BvDZHQNsc5ghnDdGuuMdwzBmDFESJ oQohxLiYGiM4aokxIiaF8MAYg0RkDQEoIITQ0BkDTG8OAcaKReCxSMO9QArBaCxVgNguA+RlDAFw NQag0BqvPISM8ag0hPCwFmOcdo7RtjfG+aMcY9y2znHON0cA3isDyIq/kYAxxeQMHII4VIkRfjIF 5LAdwqBVizFWK9DSchMCSEwIYOgihnDMGeMUXIxhJiJFANoag3RhDAGEW4fE3iJvFF0MRUwyxcKd HGMMYguRqDRGaMYYoxRxjjHCMQX4ux1DdHENocI2hFCkEiLGvolhZiWDAI4KgoRhCbG/U8VowRSC zL2LkXovQ9iEEQJ4Uon5ZjcGCMYYafB0DoHSOVJAqByDkHCPqTg1RlyUGOMoqA+RgjSGEIcUYhxw jqHIQkeRsRnjSGmYwewnhUNxFyKoaw1xni1FoKoV4rBPjWGwM0gY7zf3Ok8QmLQxhqC/HcPAd9QR PjEGOMMdg6x2CiFCKpIIoFNjZFsL4WQvBgi4GqNQZ4wxhi4E+JsSb2htjLVq6l+NgiIOpHqLkV4n xWYiGzXEX4nxSDMFcLcXQmxWjsN+JwUYsEfCzG4N0bIsBaCeHGNobgthZCvE8KETYuRhDDGEK8Xw rBOivFKKoUIvxji4FCJERYuhQChHeOkdAtREiXF4JUUo1hiDOE2HQRlYBkFIPyI4V4mRNiogSOwX g0hXi9GGK1Z4zyE23F4J4VIkhxGiFmKEUdiBgi+FNoUVAsNLjGlQNogYrBQizuKOwhl/BgC1F2OF OIpxCCcFOIYUY3Mii2GMLUcQ6BvjPGeMIXEuhiOmGIKgVoumeC8FILIWAnBYi3X1IzFRKR4D4aOP oeY6BwjmF066SY1xxjfHGLUXIwFpDUgEPSFA7lOj4gUO46Q8RyjphoPEdJlDYD1NMOUc0BYFEJho ykdsECsDvqoQjAg7x27gHlA3LIwhjC+GiMkXwzxqjPGikwYw8B4jzvyPQecWB9lLJcNYZw0x4yxJ Cfce47B2Dp2iRYm1TExcviEP0mcNOaQ8G8NIbYoxFihZSZEeg9xtDT1yb+HBAjLDSGc6IdI7hojR G+KcTytxpJz5z1mwQvRcDFFHo4ecBhkqxFJoUVwvxgRjHyQYexbBRimF8NSXgnBJCzEmHkTwoBIi t6132KouRonKFqKkdw9B4jKGuNKAw8xmDSGooAeY4xtjpi8S57w4BsshFyKNfotF1CsGD370UUbP DWUILoqwzVpCfFKLsV4rxhToHaLEVIxjjYoFmLIXIsdmi6GOMsS4rRWjIw56P40TSp8I44QIyI9x oQUgYO2O8jIRxjjEPp95NB6GzJk8b4/3/wfh/F+P8n5fzfn/R+n9X6/2ft/d+/+H8f5fziGOQeNA R2DgGqOYbioiVIriZCMCbBytdJOB8C2B6ijj5iOIrubCHn8htB0hqosO1mlBxB3BvBhBtvABxhlI 0CkN2CYwKo8hghoEvBThSBKhThMBfBihZhbBVhOH+nch5h0hUBmBOBihuNDBtBckohqJKBihphoB mBhEjhjhbBeBvhqBtiDGuh5hNhcBZhhhqBhh4sGFEk+HRvrBwB2Btk/h0B4h7h4BYhoBThOhYhCk /BwhfBjBYBohtBkh4h3B3BiheBfhjBchhjGB7hnBtBwBThfBiFbhmuhsUr8h3B1tiBIhjhdtSB0h xLSBRhmBwhih2B6B0hYhnBTBJBaA/jgB1hmBiQ8hYhXk+h1BfBZhgBhqRhVhgBkJOuQmPiXjJB4h zKkh7ikBzB4BxhuB1BsDTJMiDBhBsBcA5hMAshPBghIuKBjBRBPBEhfGahrKoBVBfBjkBhlBUQjB ilohghoheHURhIflNhrhJhQg9hMBVhBg/hVg2AzBNgnBeBrBZhfhoBeAsBJAsA3BMA1hbhmr5heB Tk8hPBrLxhQhUMohVhUG3huCDCsh7BRhchWhtBuhsBjhnhehGBUA7xVBSnfhjgwBOgqg/BUA6Blh suJBqhdBNBfhHjDBxBnhkhihoLHjYh5BJBTBKhXBeBbivBvhVBehfhehrBihMBZBOoyiDDYh4I+B LGMBlhhhqw8BshfhZBlBXFoBhu4yWBShOhwhyhxg7BCA8Atg6ArhdhkhehUDOBWkHBUGbouRZh+h OBdhGAzhFAlhRhfBKA+BXg5AuBNAoBnhwBliEhwrmBIBKBJhvrmFrhxBThWhThThYBXBnBthsA3B KhDg9BPhAxXBZu9hFGKhLoyLAohBfrgjdBbBIhIBMBFBAhDBKg+hDBoBihkrIhoBEhIBQhCA+BIh sBthuBRhUhQTbhinixVkjhcBWvuiDCphUBdhfBNBUBaBghjhkhYBYBXh1oGBlBlBmg+hHhJA6A7B BBhqvp6hZBGBNhMhnhrHlBgDPBXBRByBxBuhUhVBNuuBYBlhkRUhdhdBHBTz6BchZiEiZB9hYhSB YhZBJHXC9BRBMvhS2BkBmhohRBXBWhJhOzgBthqG+hOBKBIhBhahYhShwJaBRhUE9h0hxznoNhOB WhMBBhIA8hBhAA/hHhNBOg/hIhLOohrCEhmBoBlBRROBaBdBXlNBshOhWBNTJBShvBxhvBWBdBVh TBehXBrBthtBHBRBRK4hon7ohh2BxhznAqoqSDRByJ8huh2h1B4IxB8hwFrN9hzuhoLB1B0JMJLi 2hPhbBTq9hqt/CXh2B2h3sjBvhphphshPhPFghpBsOWB3hbSttxhehvhvLOUXQCByh3h3MfMihxB qhrh5uTtchuhyB3hxh1RMQiBqA7A2BAqUhgVCh/B2oAhvhtCzDIhsith11QD7h8BwBwButsBwQEh 4DfEFUqDfhyBjBphkBRBchNidE6CXhphmBqBWBUGcBXGcEMhbDnOCOCiDjBB1BwhohphzhvBvBsB vhuBeBlhihwUXFbhehQBRhMhRBKBSBChChIhMhQBSBMElDhRxvRCpmjh3pOwRogC3B9B1mji3xZC 5B6h8uPB8B3odC3nFDUIEh6B2jgjZB6pLjVCfv6ImIYiRpLh5ItCMCph3Nsh7uNiGDTh7IIpXB/2 WIXIQCK2ej7DIh51QCeB0UUhsLoWkOrhnhmMSh2DJn7B5NrB7EwiTie14BqPrCEqmB8DhB5oroxC NkPhonNBmCehmsShjhshiiuTETuhrhyhxCjB1hqBwhrhvP+DSh6r2hmVNhrhghthfBkhnBgV0hxO kh/n1h4BoBjBf1jBrOZBdBhhYg+A4grhmhkBf1sB/DDBxhcNfBdBdhfpOh8BpByhno3VCh+25Buh zHuiYh9BwNIrwh6ibH2B6h4t2CbBxB1hxxvhhiPHUB6hHhJhBA9A5AzhrBphpBlhpBjBFhRBEhVB bL6BbBUBNmKBjLIByUzhTG2L5hXBtW8BnhmwqhnhgBbBmBXhVBihSBkBthjBwhxhwBUm+BgBlhgN IhxhSUwBhBnBih1h5h3DmhfBIhSBOWRh3CDDLBahWBeJtBoh21DhMhOBHhchjha3hhXhdi8rRDMh wCGBzHpBmhqhmt6h1g4BJBAg0BHA9hYhjBehghpmSBkhhhpBuhrBIhNhIBZUF2m4MlGhMhYBEhlB lkIBHBGhbBUhRCZL+iBFpBlBUhbhNBVhbhVoGh3GohZhPBfhUwLpSiCC2h8hc4fBYL0hcyJhphwh mhLhPA/wDh7Q4BnhRMxR6haICh2BMs+hkhpBlB0MFg/BOluBkheGjh4hGBTBShBmeXu04h5h5Trh iiPQ5h5O7hIBAAvA+mIBgBoHuhZLGBShcPNmx34BmPQBehmhnBuBi21hcBbhnFpndheBmhfBcmXh YhchNBVBWhbBYhaQkMEBhBiNthahhPQA8Aug8BIhMBQ4ShrhjhqhoBQhbBaIEh4jiidzcBsmNKpD ZBShShdPMD4oGA6g7BEg5gtA1hrKR1blOBzBlKfk/B1BSQYBFBRhOGopnxXTdhXhbR7BJhOBahOB QBcBVhWBhhUBMvdhRhbBchUtxxrBXBNBYh4IHCDT3hthZrJMsBhDYB4hdhqBghUhhheByB1NTCCv r0jhfhKBMhZhJBIhXJCh46DBZh3B1B30lBfhhxXhSBIBT05johvBmpJWuhZkmhvh5U2BxA/hHBSA 1g1hMBhhjW4hyh2hXBYBhjSzTiMpOB9hbBkhiBTNUhaBphhBxB2ByhqhxBshohxBqBj54BtB4F/1 3htW8hIhABQBThLhZVQh5hZBPBgBPA+BThLA9hVz6BhhKhQhT4YBgBOhoBVhdhsBghn0PhGhcUJB hhZBnU2hIzmBABWhPhpqo4GJOheBMKzA+hRxbadElhYBMBevMhuhE5EhGBVBOlNhxDWihBdhwBeh PhlhUBzt6BrB2vExfho3ZhlKSBens3CBvBgBfhohl5UhvhqhvhoX1BtBgxqOrhrBlhtkyhtDYuZi CWEBmHwhvNsB8I4hnh1hpBcpJlOQFiBn7htJeBkBcBkhqhiBpBtTCBKBEhTBgm8BZhnhghOBkZFB fhah9CnhbhvBdBThrBVh3B7h37aBmhKxHFEB1BLhYBdBIBJhV4lhehhBThhBPg6hRjbrviOipnih +B/caiXiHimCYubcb1cDB00B3FYEpBxh1hvh2bjB8h5hwB6Bxh4B8h4otKBBzEbh0B7C3VVE+h31 XDTznid10miPJoyB9uTh6z7B1jZh8hsBxSwizinPvXOcapEubUyNoipoTI7hrhzhthBhYBHBahkh jCbB98bCndBiXo7io9BCeiZ8eceC1CnCXWVdJCL9CmEh5Cd2LIhn7Byh6pjReCsmU2RB4IEI0EwC hHi3E2gIQ8cCEINI8CLConch3IviInihrB1hrBhhyhih3B6h2hyh3DSI4jKMfL9Gu2OCECphuhyi xi3Rch6BpKRC6hyibWph5iiBwvC77iHCpRY9UiBCpoWibB2h8N1B7h1nin8ibItGu4FiCoxoxi4C VB2B5nWBfhGhDpABshzBsBfyphmBuhnBpBwBrhSBfhbhSBfDQk+BnZYvVBpB2B1B1V6RuhoBmqWB 2hqhrBm7TBnRgldhnHMhjWXCDHPh0X1Bfhr35uhh8ZUhqBkhphtB7DIhkSMBmhmBp0EjZB7mKhdi 3B89ShphxhoehBob36uiBujBoBIBcBGhRhjBQBahmwpBmm2huBphXBiBd6XmDKDCE36ByhMBMbXO Nn9h0hOhfhL21hhHihbhqBag/hXg/hZhm0DiEJeVoDoG3hxOz3oBThZBmBoqcwiXnhiC/B4hkBkB ghihpBf2XENhshMBhBKBUBmhSxiMLSAB0h4acoEBersCBvth8BXBgBihykddTqchrhirJDGWEiMN 9h0hThcJ7BTBPc1hyhbsKhYL0BjswBVBShZhcy0vAhqBShAhNhXhLBSBSq0BZBdBaBZNbhrVdhRh PhJ4ShiRgwqECBqhgmj93CCDthyUnEqBuBwBtcAhVqVVuhcBnBeBkBcsthZhXhZhxriiBhgBmhk+ fhyB2iAN5Cq1CoFSo52PF3P+GQ13u92rRcLpyOVxrdWrZnrljMteMddKtfrdYsd5PJ7w2VQx7vR7 L1hLl1O11vp9vpgNJiM5rtV3PJ4LlirpPKZPK9bLqVyphMJlp1JKVTJdUrNTrtlNRtLBdL1DJpOM RpsF5vZ5MJfrhhMpcvB6vBruRrLBkLBoN5nMloMdqNVptNrNl94NgsBiw2XPhXKxduRvuN2Ot3LF Uq9ZLVaM1sNql53PZ93up1r9SKhkKxZPh6vZtshpsBQrNirZkm89KUuG9QNdsORKqRbH9LqRGJ9a pBXJ9OMBNM5vNFCLBIMJksV+9dtNprrdcLJqL1jUt3Ot4I9ILJIpxfr5gNRBI9ZoVJrJbr3oJpVI lQKluOJ0m+dxuEGWJDGUcBlG2bBskwSJKFCUBOIedqlmIV5iEAL5DFCSZYGUW5ilMRpXHIbRxlSV JhkWSJbHIcx3s+a5wm8OBLj6UJflWfp/H8ahsGqYZhF4e58nuZxdF8XpMlEcRqG2z5nGgb4+EQVh DkkWT3lsL46lKUhamKOZMEcYBtl1HR+mWbpplGVRTGoZhkGSZplFMVZQmUXhjFiR5PE2OJJHGaZu GCZJtjYORNGga5yneeJ6j+RxXEkUJbm+ch2EUUBVkaVRRmKaJqM/UVR1I8R5neQBRkkaJtm4sp6j 6VJGlCYJVnSd52GWcJlmsdRpncep3mGbZnGaaptuufzVnuZJomudZ0oWlZ+OuZBoHAvRwHieZ7ly YZrWsbaXHuYhrGOZZtmYwZ9nWex1mMcpkG6dhwHUdR4GQZZoG2b5vOufqlnoeZ8HSdZ5Hct0dn9U tRn0fh82AdZ5nyeWGYsf5VmcVw4k4RBuHCdB5nqfCZnmdh6HcYhvmKbB1mthWBnqYpmmmmh2msbx wl+ZRommahwHqelgnaeZ+2orRzlaXBom8cWTnqe5dmKaBhGcZ8hnyaJwGoYhvGMeh8Hpi+x4thWz R2fZ+H4cBzHa1Z87JuO5bnUmFWofeFbpvW9ngfR476eO98FwfCcKlZ8H3imwnqfZ7b2dp6HXah+c MzsiH1hFHH2euLHufR6l+aZaHXyJ5H1kUiHYeZ4bVynB4Ueh3rMt2gnweSyngeZ6bzwejH7g6ynt sPNm4dRyHieR7X+fB8H0pfJ4d5zPbSfh3HmeR47CfJ++lyrOn4fx+G+ehxHIehznefB4G2dhvmyc puFkZxfmcvxpmwbBqHCbpOFgUwsxdi8QQMwTYxBPjQHGMtbg8RtDof0PEcD4B+jdHeOMT4zxWD3H 2Ph9I8RsvrHgPceRMx1IlG8PAejYmxjbHANwRYuxJijGmKAbLLmgDjHCPUcYvByDERGLUdg+B2i7 G2MER40hLClGkLUSwwBThuFMIgZo3hpDKGuMxL4wRsDbGyNQb41RQi4FMMEbgwzPttHYIMTgnRAC pEwLEaQvhJjJFGK8744x6DlFAM0WAvxojMcnGcdQ5xcC+GCLwZYvRfHfD6J8PQkhhCUGQOoZIcBO iMFwLwu47RyCSGUKIYyuUzjUHcNUbT63IDvFkM8X59iOjcGmJ4YQrBKi0FKOQdY5nvGeHIO8dAph siwE0MgVYuBqi7FkL0XgsxaCwFIVYVYtxTETFoOMc43xbjMFcLwawthAC0DeFwT4RxHi1D2OMdw4 RBCqECKEaQphzDzHU6YeYthtjAc8PgUAwxXhuFUHMUwxRUCaE+JYOQgA3DNGoM1sh5B0CMFqH0RY tBDCfGaKITI2hRi4HLK0cIxhkjoGeNUc42hajSFuJ0ZgnBuDbGsKEVonhJitEuMwbgzBijIF8MMZ gw3rDuE+MoSwXhQBJEuMARJnxuDvHCIcZAmQ6i8ESLMbIvBcjeGA9lfA4hlB/FYI0T4rhQPCccZ4 YQ3BeDJHGMkSowhFCtGYKIPAnwvCTFeH8cQ6xwi0GQMEag3THjxHMLIbgvRxD1HIPgfg+BeVoGrA 6sgpxbiuGIMsYgshdiqGca04AliyuBl2Ut8o3RcDKm2M0WhshSjIUGJ8XgjxKitEIKgY4mxcjRFe NUcI0BBCYDoL8XQrhZCwFaIkSIhREiWEYNwco35niqNoMQZg2BrDdHEN8R6NRjC+FoK0XaEBYCOF qMYUqlBHiYFKIAaI2hlLyGKN4dY3FSDeHGN0TosBNinF0KkVAvhciuGCLscQ6Byv/FEKESohhsDS GeMMXhdBpC7FYLOJs/BOC2EYroYgphkiZE4L4SC0RzivFKKkRQhBDi5F2LM0DuhSDAFuKUXosxSC kEoKcTYkTtDNGaN0YohRcB3E4MYSA9R8wqM6MsZ4whMCHESJ0TIlhvUtFGJlOr/3kD0toMAVoyhh O5HkKwWNYRRCWb+O4Y42Rfi2GgKscQ7RvCbFmIsVYyhPiUFyIUNopQuiQFgIIeg9x52hKWPbI4vx si3GANgXObxvCtGcKIZI3xgjlHaOMdA8dLD0HUOAdA3RdDMFuPkfQ+R7D2HqOYdY5BzjwHKOUdg6 BcjJGILgZouRnDcGaS4eg3h0DZnmOcbg6RsCuGWKIXw2hbCyGkKgWIzhUDvHmO0Z43RrjjHUOi+Y 47nCxFcMMZ4yhejOGMKMXooNLS4HiOgcN8W0j6H8slHaZ2FJnTOOYeA4hwjqG8PgfI+B0DtHe2wc jwnOGe3rvHeq/1qMK3eOkeI5x0jyHPIEzw4x0jkDmI4PwpReCrJsPpf+8mz8ldUOkdA8BychF+NU WosBoilYkOjlI5dWjkG8OkboqxhCzumMg67rtCdD6J0Xo3R3vOtHmWUfI+R99I6g3sbQ4RpItG6P wmxDemub0Nw57jiB8u8H+PB3JNB4NkYUPp4TRuhKkHs58dw9x1GfH6YPsTFnfD5NWPoe4+G7Np7E Pt7j2+/I7VIPN6w7zyOEH0TZtTACGb23iZ/rHIm1dR6iObTwwhUC6HANgbw3jeCnQcMIWov2RDzE 2KgUgexIiSG+OIbwsBbY2EsI0cI2BvjWGkNkU4ohXDFF6YclbCh3LRHS+jxo+xsqCE6HURcX0nEr 1OPQcA3RsORHcOoeY5haDDFYNIYIzvl9vSKMsZupe+DwHkM8VYuRmCqF1oLg5KmuDMEoHMQ4sBMi keQHkFaFgFiGaGyGQZEHkFeFwE6E4FMEW+wG0GG++LyGiYcH2Go9kFMNQF4FY5gFij8I4puGwKWW 2HmGOGUGYG6HCG05CUIGSZyHGd8ymG6HIHSHGHiaEHkNW7AGSF8GOL8GsHcHaHc3i8gcs8aHYHgH Y6csU6wHe+OHiIg7u8wH+FQGGFmDOEaDiEqFWEsfKZWGSF6p0FyHIG4G4EwDkDkEqDSDcGgkMEgD aD4DyC+DSFqFxAEF0uCF0FmGCGKjMJWHaHuHcFEGEFOEwF4FOGwHUG4EuFyFEEcFmEeHAHcHEKWH IGqGwFCDMDsGaFMFoHu1OFMEmE8FmFUFoHMHOHKG8GyGyFCFGFC38HyHCHCG2EOEaDoEAEwD3CQH WKWGUy8EcFiEYFOFqEoduHiFfAWGuGkGWHOHGHEEiDOD0EYC+D0FWFAFEDMDUDCDyDmD4HKHMHMF mGIF2JEF0FwJIFaU6FWFoFYGWGcGkKWuqiqGkF+GE/AHuHuHqHAGsGqHGGuGy70HuFcESE2GqGaG eF4F8F0EqEgEkFGEeEyFSFMFaEiEnFaFeVsHk20M8F4GcFyOEDkmSFQGeGCF8EMDEDAFGDyEAH0e ZCmJUGKFqFkEwEkD4EYD8DmFoFoFEFQFCEeFGE0EgGsGuGiEyFeEsEOFiEWGiHCGoFAGJEgF2FCF EF+FKFcFgFOFSE+EkFUFcEyMGbgIZFQHEGM3EGKGWFyG4GwGmGOGGGAGSTiWXBGHoHikQFyGw24G 6HSHEFCF6FSFkF8FcGYGiGSUcHeFeF2FK0suuGuGoFCEaEHEKEcIUQmJXIUFWEjCyF6FkFKH4MGF aFyFkFSGEFwGwHEGyE6F2FcEWF4FKFgGcFwEcE0EOEIEeD2GiGgLqFyFAE8FWEYFgFGEuOqu4FKE +c8rKJUGep6E6FojeF0FZBwGYG8GYGaG0GY8aH0VAGxBMGSX0GaFeF0FkFiF8FeFIpoFCFiExBOF 9Gc+mM6FmFEFEEmDiDyEaD8DyGCmUEeEmEAEmFKEU38HxJeIa7IHaGoGyumpdF2gWaEHoXWHsSGH i1RAqsUHwHsca76HsHG5wGmGyQQHGGobuIa1QHoFSf8E/PKHEuuFAE6E+EwFwFKHEHcHOKW8EH2T kGeK6GSHcUaG8GwG6pcGxFOHMG7SKE2E+EyGCGiF0HmHWHaGwGMGKHCGyGud80Kc+HeHqHbCWIan mHcWeG46c74g2HmH2hSbCL696G4GkHSk4ZAG0GgG4GQHCZ8FQE4FCp0GHCkH+LKHoGZH4HBFQ1OH uKSGAFyFqGCHgHezCFgGJFaFoFiFmGAFxA8F6F0F4FMzGFAF2EwFGFkE2KAWkM6fuhmJCFSGQFsF 2GgGKFDJkGaGuGmTPQHVnVpVql24VRmHaHsLLVtV7V9V/WBVqhCHkGwP+KWX+/pT3WDWXRqbSHNT aeEiE2kF4GEGe3+HuYVIDHyHoX+cY76sWHusW7E6CcRQgSHQgSI38agsUOuag761LWoGgNFS3JcM 8d0HsHKHQHWMgHS0M38cTCW6CVIGwGfFkG2HQYUcQeYg26CSIeEd0aCHmGyG4Gy6mHGG3Q2tsFmF cGSGA5Ee6IcewuIFwFyFWGAG+G6HKNUHwF3UbHwHycm+rM9RsH5HyHq8aHyGqG6Gy08jwc2HNI0G oHaGvX7F4JWX+G0G2HKGmt076HzX0HcE6FNLuG4HHWYIabaHWEeFCE0FuqtXcFVPKFiFaFAHIHQH BE6E0EoFgESG4HYG6FUGkFaF+HAJGtJVkIYG2HWGeFsGuowFaMWW8E0FWFWFeu3R+GsEaEoETJ1E GGOGCFNPkFyv2cQJSJWHOHiHUF8GuGIGCG+GOHKsEF0G9HIGsFQgaGivmHCHHR+G4IUHWFKFAEcF FMwHEHKG2/eE0Kqw+GaFwFOF8FUEoGCE8FoGoF0EAFuEQEqGGEyHiHytAJU6aH0FIFOFsGYGYGuG KTkYVO6GXXMGgssFSQ2GYGkGFKYGeFMF2E4PsFwhMFcGgvwGcE4EoGEEmDoF4DsquKUJWHYYQFA/ kE4FUFuGkfwE6vKEGEMD4J6GnauIYeaHwW+F8HKHUHEbAHmF4GoaWG7OUpuEwF8E0EqF6EuG634G OG0GSFeGQF0GwHKGw7E/GGSGwG4GquEFUGy9yKcF4eSHiGQG2GIEaFgEIEsFqEUGIGyGAGMGwGHh jMKHtegIaeaHzesGGE6FuFmGeOyGTKIGK3JLeGWM+YUHGHaHCGsHIGmryG+EuFwEaEUFsELSEGwF uGgFuHAHaHKGiHEGsF0GaGSxeFeGmHCGuEYFWFOEqFkFkUcyRS6HaHOE+FMEgFSGAE+1ziaHgFsG UFe32G+GQG0GIHGHMo+Gxe0G8GWGuHOG8UKGiG6HQHEEtAUF2pwFBUgEuFcFG1CGQKWHY8UGEjiz SGGG8HMG3Z0GhQOGZE+/rWYX+GTTkFeGOFq32HJL6FkFUGCGEFUGAGGE2FsF6EKE6FeG0G+HMGy9 6FAEwFTXXF6GUGKEYESDsFiGIFHjw2hj62GG0HIHaHEFSQqxeFaEqFsFOE9Zbd+GBijWOR0GehYZ 2MAX4FjISEWEuEQGmwYM+eiF7gyFYNOryHIjGFrKoFeFaGGGGEUFSFdm0F/BSHGDdGiEuECEoHiW 2baHe1gHceoKWe2H0HgHzUUHrppM8dUXeG0GFL0G0x6GkEiFgFdl4GkGOGsGwoqKQJ2r6GUGOGKG YT6FCFYFQFeF8/ekHaMJU8EH4GoHKGkGaG+GUHcHoHaFYGKFkE0FwFQG4HNatgaIadbiiX+eESI1 IebJa1IMSdaGEmzUoPCM8xEFSFiFRR+Gm3eebXC7qYUaxr7XWSHJa8abI8eFIFoGJlUGsWpCKKXW ycTgfWQ6bsrsrXXr1JaHwHAGYGoHWG2HC4U6IbSH60CcQdbXaeEMHM81I8qSIHvYEblsi3/XXprr ruQ6Qcm3oOuJu3g8NVs8EYcfCcIbsaMtDgIHKusHZsw7qXmGyYdLDV8G0GrHAnQVIcmezrSHwJqc acI8eGeGWG+pwG5QgHwG7Q2HUIgNkGKwAFrhuvlaO3iGKG0GDs4FuYKHGGOu2HWUaX+8Rp5cxSsb 0YUHIHcGwGEG0FkG+HSM4IYGkHQa0HaG6IbBprTt2YcHUUYeuHsG+G2HTIUGmGSGUfzZQELOKF8G YGgW4HgpO86GqFMbBieYYEmFEGCFcF0GgdapyGuFmFmGaHWHYHkGJi0FOFwGCUuHOFMGaFcFaGEF sr4Frge6OGYG2GaDrogE8FqFGGUGkneF6E2GMsKacHIFUGEFAGAGcF6HkHoHliqFG+AP4+uF0GOF yE6FqEqQUGgFYpSEoQcHObaM+FWF8FmCsD6DSEhIoF4GmFsPOEWFiGeFaFOGEjCGgFeHQHeHJWOR 3fNpCGWGOHaHkHeFJcIE2EoFqGaGgGyDWECESCgDSDjT+GsF8GgGGNMtsGqFIG+0+E6F8gLfLuOH +YUGBDaUKGIF7JJxLX2uYG1FQHcEWEeFYYKHfD2GCCgDWDcEME8EiGcGsGsEKFAEqFQmQa0GiE8G AE9jOGqG4HIGuDqE7G6E+EAVuHU1I1IJuVJgIG9BThaLkFYFrM2F7ceGmoExWFgGAUJOsGKGoGGE CFQEDh6GCbS6e6MGMG0F2EGFIECEwF6E6HC0vI6F8F4GrKgGgGCDWE6EWDkFQEkaIHiFqGYTIG4W 0JOEkpkEYEeEKFgGLKUGMEUC4EeDyGqG8G+M+0cF2GkFyHkHwHYF6GqGUGmHMG51BhEGAFgFYTwZ iqUOyFUGJs2HUGQFQGiFcGNfIFyGCGGEaFkEYFEGgEWHEHhvIHOGyFyGqF4YGHWI0GGDcFAETEeF RX8IaYUFqGqGCFqGOakGeGafAH4GiHSGgGAHEF9SyHkF2GAGQHSHYHYW+F4E8GUEYFmGuFaGiHMG iFYGoFmE6GOLtNOFGGIFuFOGWF8QNcSF4FAE2GQFSHYLf3aGc9AGsVIFuFyGEEqFSU6F2FOFQNnz Z1AHEGkFTb4E0GPcMioFSGUF8lAFsFaGaF9TE6OF2HOGCEgGoE4FiG+F0GWpF1AFyFaF5PGIAz2M n1Wq0ypVG23A210zF4tmavnc9HgmWSlz0rDSoGMlD8szakmMl3U8nc/5RKZSuHAwUo0E2w3GyWy5 2+pmMs2U32o2Xc3226m8+n2+pVR3w+Xy2nc3nC8nCoWcnV22GOvW0yFy4WGpXCrXE9XIx3MyU2z4 S53A0XC100sVQs12vaVRpQ/rw8Hi8Wy3W873m83w+3uqWgn0uyEW2He2Eu1lCs3GunA8nGqXEsF0 6F+6Xu6m27nA1nM4He9nk4ni53C8XM8Ho9Gu3W65XG6H6/n7sHg89RR+A/3A53Q0HI2XC8HLqnM2 Hc3Hu+3w4Xc6Wi5W3gnq4nk53c9Xg23M432/H5wfR6fVR3o+3q63w7Xt0nu+Xw8ni9XlgKS+XgfB 4HkfJ4ny6T0nke7lHg6h6nYdTVnifB4rwfz0nge55omiZ7nq9cPQ/ECVHsfJ7HeeT/nuojzHeih4 QG3J+xC9J9H6fZ2Hydx4n0eUKRlH0fyBIMhSHIkiyNHx+ySd0cvNGMjyfKEoylKcqSLJJ+nMdJ1P qe0evQfR+H1CilHwYxgl0dx3ngfkkys3R8H0/sAHgdhxHCbh1nTLJ0nKXBflsahoGWcpznFNh+nk eR7Hs+pvHGchrGqblJnIdp0naaZgmYcBqG1LyVSSfh6nnHR8HvK57nsesUntGCUnYeZ2VgdsnvKf dPyqlMlneZhhGYa5jmgdpznYZ5imkbBssqep60kvxxG+XxhGCVpalwVhZlgcpzHNXKjnQchwF8Xp XG2bBonid52FASxGGAXBXH0fR8uAex8HwUJdFWVBdloebYlqYZYkYVpHGmcJmmschmFeYhZHMdh0 uAchyG8ZZjl4aZoGUej8GCXhaGgZpj4+WpPE6RxPlASRYluVxcmOXZSl8U5VmKVZnHAZQ6k0OBLF oSBWlkWJQEcTxnmEZ+WluOA3DaTRNEvXCUGqapoESRQ9FUXJSnckxNlcT5MFoUptnKb5iGiXpMlo ShjGyY7gHGdZzlyZZimAZRlm6bRrl+XxYGwahmVGeJaFWTxil8WsyOA8x+GQahmlKXBYHOdpzG3S BfmsWZnnEYDcvOo5wHCcJAD8QZOE8UJsG0bZMk2UJYFuWZunAbRIk2R5Ik4RWQFYUpWk5apUnseh 528lReFmUhBjwMOVkG+x72oWZv2VdJ5OAoh9FkZRVmObBh+QeRgmFuxnmOYZfGGSRCI8QJB18ZG5 G0bJZFcTZgloWR6F7GEL0YjihkCvFULYTwoxXCnFgLIYA1RZCvGaKMWjtRbi2FqMAZAwhBiTEYJo Ugoxci6F6zAW6AR3DCF+LMV4gxDi5FEJ1qY/xci4GEH4OghxAh3EOjkd4thiipV+McZQ1Rfi9GWK 8WQwxXDJGeMw4Ay2RDMGsM4UIpRTC6FkKQQgewyCkE2Ig2I8WXCoGuOMah9R8HAHqfcXQzxWDAGk LsaI2BkDcHENlfgpxhjDFwqMehwDYjyFIKoRy5hmn6HkKwSQlBUiKEenwcwqBTCzFKJ0VQzxpDUE w6wXgyBVFJHu8olYrRfCKEYJgRwixHjsHeOsZrehbi9FaO1JZ6RjC7GCKUSQqBqjNGuKUUIrxcDE GCKQXosRMCqFcJkSwlhojLGMcAaI1BrCpFkLIVguhTKVHGNaTczBVilFeKUYQ2RmDQHENIcI51zD XGaM0XjbxljYdKOUTQuRWigGELUZYzBmDKF4LgeA6x1DfGaNEZgphZDoGsN2GY3BvDgFGK2LAqhP jaGwNVxAoBdixFyK4TwrhUCpFiJoTooVsCuTY6Mf4zBcMyEtCASgmBfCzGEIoSAmhVC4FoPleU6R eDAGMKVbY4zgKpHsLMTgqRSiPFQNAYw0xpDOGmKmrAoxZCnnaOI4A3hvjfEIIcSYkhPCnGrRoUIq BNjEGEL4aY2hgipFAJsXIoxSChESIgU4ohPCoEwJscjt5SEoHmhwv6jzunRVOP5x4+YZkpPAPOb4 2z7FJKKjQfY+R+j6HWO0eDtxvIBVoUcd49x4lPHKOGyh7R6l4RqUUfZRbInoTGP0pSYbaoytgvNA tQB+HlHyfVedm0CjoHQOcco3RvjrHEOQ3STh/jhHYN8RItBCC2GsLY7RoRwHcHKjAeiElCDetmXY lSFB3DiHQOEaY2FTD3HlZ8cw2inDZG+/+QJRx5j5HoNgdg3RuDuNaPkqFlDBj3a8OocY3hujpG0O AdijjpFKPqP1NlhcNYbw5h1D6th4n7XnGvD2JcTEoPqPkcI6B0tzHQYMfCMFDoUHaPRrx9yUj0ja OYdA8EioURgjBCiFFDpXSEhQdY5R3DtHQO9IWME2D7xPlPKmGh0p0EQK93wvBQCqIcJij4pBfi/H UmkS4rRUjgHQOMc44x2i8FUMYWAmxbDmO8+cag5HLjtHiPQYIzhsDTHaNkcY9RykpTAPsWw0RfCp oEKxkgyhsDYEjBEWMKj6j1zaNwbo0RtjrHMdUcY7hrlsUmOZUg9hTiSFyN4ao4xpjfU4PAbGqB1D WKEMscLghxjfQoNYco3FYEnyrsXYyUV5D6FDVgZYzRpjVGwN8W7f1iDvPKPoa41hqDhG8OQXYrhk CxFMMUWgqRiCZFYLYLQdxCCaFgK/aojxVixFgNYWI0B1DSJSjAXwxxjCrFmLgVQshai2FsL4ZxPR hDFGWOwdY7hZCiF0LePg4xwa3GkOCmZcBajCHiPMeoyBpbQTsLQZAwxQDOWwMplwxRflv3SMEYCF BtjZG9kvJ2x+dc7SCOwvQoxVC0HfaAZG2hITjGmuZUY8hYilFBNoUYtxdCx3uLsT4vl9jLFuJcXQ oRKjAE6PUfI9RmDfGUL8Yos6gD2JTUAfYoBTi73SMIVouxgC6GOMwTgrKsCzFoXoeQtHDjDoEPcf A9hrjoG2LUaq5BoC2G+OwcApxqCrFUNcVYwhmi9WkMsTImhXijFiLrvYtZNDaJSOZbZgXk889d68 9dhx6DU1cUle50j8n/uHhgfg8x1DtHmO8dzlxzDTHMp0dg2hzDyHMaQag2NBmCHoKeI4xxqjRU+h Q2Co1FxtHqmBHY8x4KqPamEaQ5BojQHGM5OA+B1DzHSNkdWkx0DXHgPUwF8jBDyG1YMaTCIZL54U gVATIRQRQPasL1CwxJa4aUb2EB8CDKZJIfwcYdQdg/LtkCIlQdpBocoeYcwfZGsDUEcEkEsE0E8F EFMFUFcFkFsF0F8GEGMGUGcGkGsG0G8HEHMHUHcHkHsH0H8IEIMIUIbnggIKZW5kc3RyZWFtCmVu ZG9iagoxMyAwIG9iagoxMzI1NgplbmRvYmoKMTQgMCBvYmoKPDwKL0xlbmd0aCAxNSAwIFIKPj4K c3RyZWFtCv///7FOy06ZISAJ5JISamGapLNF7itu4ZtAIy+EDjfxXOmiqrTwQ9YRTLqkXiUF+cm5 P7flrpmA7r2vc8vnZCfQB9KF+BVcCWIWrcE8s7oFbPq9UahW0pYTgQnfaW4GOnXZv27uHHdRMyUS b9nNdEXHMpdviGoGnOwQe1V+go/0W09iSmvam57/rg7Ye4IeQrW2sj0guNoMyFZiRtnyOjVBnX+t dxtMd8laT0XdboeSJDnQRfKrUboBtAHbpjwQ6NmPlVCr4sd0PRe5GoVBrap7fu9tKkEnLPUoB5xk F4Q+pxmPUvxWxzlugFT0wgKePYCOq6vP0tfF+95hYPXlnpz/Lu/7hbY08zeJ5/mLhjcMFOK347WO qbFtChJj77EA7t/v6mSlH1fcqD/WM8UOQNrx972nhmdY83FrVmEcVlD7RTpg61m4yAL3nza9rXaX nm1VRfS8nucuCT6PJZXgIdsagcZ0OY92MS6s79sjhnqR3MCFmV9tyGirV45AN7AbUjHix2txPpyf 64t7DhL2n++2JIkVklF+PakMfuG8mjPufPtZ7jn2jSWCCTOU/9OEtfgNy4peScgHVUboEuEcAF0X WktRUNl20uKqZ+F965d2+GIAV6zIXgEPRxTwYxVOe2+azMBzQ5JW7fo4a+XP4d4y4jXeq5Tgutv1 qz8K+bp6k4c6B8vNXbnHlSSsZQaKmOi/dpNTV04vTPluV/Mp0YawC4172Os1n4FZS+Zg1n5JlvXd 6k0rGZkliPAYscKfYs0s3qUYE0WZbJGAzWj+Fv708+lBHwPbRIvMXT2O/J9cKX0CQZBH2v3ZWspB WeFATtUpkPQsbDm4OJb1x5OUI7wSJv2ibtifRzNqiI1Mydwh8mwWH9hP2BHmzdh5Yvw1dCIzF5EL t9g/IWHMbiqojx0VpTzt9RT/2+LXVUXUirr3vdGIyYhhCarC1RjtfqgKlE1HgUJcgB4/WHOELf4+ JLsQrYWYDo5D0WRbvuMEyXdREfmUbXqzrdMmMQAkcCXggAplbmRzdHJlYW0KZW5kb2JqCjE1IDAg b2JqCjc2OAplbmRvYmoKeHJlZgowIDE2CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwMDAxMCAw MDAwMCBuIAowMDAwMDAwMTg1IDAwMDAwIG4gCjAwMDAwMDAyMzQgMDAwMDAgbiAKMDAwMDAwMDI5 MyAwMDAwMCBuIAowMDAwMDAwNDk3IDAwMDAwIG4gCjAwMDAwMDA1ODAgMDAwMDAgbiAKMDAwMDAw MDU5OCAwMDAwMCBuIAowMDAwMDAwNjM2IDAwMDAwIG4gCjAwMDAwMDA3NDQgMDAwMDAgbiAKMDAw MDAwODAxMCAwMDAwMCBuIAowMDAwMDA4MDMxIDAwMDAwIG4gCjAwMDAwMDgwODIgMDAwMDAgbiAK MDAwMDAyMTQ3NyAwMDAwMCBuIAowMDAwMDIxNDk5IDAwMDAwIG4gCjAwMDAwMjIzMjIgMDAwMDAg biAKdHJhaWxlcgo8PAovU2l6ZSAxNgovSW5mbyAxIDAgUgovUm9vdCAyIDAgUgo+PgpzdGFydHhy ZWYKMjIzNDIKJSVFT0YK --------------060206060405040406080601-- From nfsv4-bounces@ietf.org Fri Jul 06 16:49:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ukB-0005zM-5W; Fri, 06 Jul 2007 16:49:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ukA-0005z7-6k for nfsv4@ietf.org; Fri, 06 Jul 2007 16:49:34 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6uk9-0003ap-Tz for nfsv4@ietf.org; Fri, 06 Jul 2007 16:49:34 -0400 X-IronPort-AV: E=Sophos;i="4.16,509,1175497200"; d="scan'208";a="79477174" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 06 Jul 2007 13:49:33 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l66KnWYO028853; Fri, 6 Jul 2007 13:49:32 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 13:49:33 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 13:49:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: stateid4.opaque requirements (was Re: [nfsv4] An issue regarding free byte-range lock state) Date: Fri, 6 Jul 2007 16:49:31 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: stateid4.opaque requirements (was Re: [nfsv4] An issue regarding free byte-range lock state) Thread-Index: Ace/Lsm/SVyLtVG4TRG7rplZV/R/HgA3+F0Q From: "Noveck, Dave" To: "Spencer Shepler" X-OriginalArrivalTime: 06 Jul 2007 20:49:32.0549 (UTC) FILETIME=[27A49B50:01C7C00F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org My preference would be that the server in both of these cases MUST return the same stateid4.opaque field and an stateid4.seqid. This would allow the client the=20 flexibility to send a seqid of zero in cases where he didn't care which instance he acted on, a non-zero value in those cases in which he did. -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Thursday, July 05, 2007 2:02 PM To: Noveck, Dave Cc: Peter Varga; nfsv4@ietf.org Subject: stateid4.opaque requirements (was Re: [nfsv4] An issue regarding free byte-range lock state) On Jul 5, 2007, at 9:35 AM, Noveck, Dave wrote: > >> I don't have a strong opinion -- a slight preference >> for the stateid.seqid on read/write to provide for this. >> So, whatever everyone else wants. > > Allowing the seqid to be sent or not as the client chooses > allows this. What I really don't want a scheme that forces > the seqid to be sent, even when the locks are not mandatory, > which is going to be a commmon case. This is fine with me. The final question I would like to resolve in this thread is the one I asked about the requirements or use of the stateid4.opaque portion of the stateid. What are the requirements on the server about the contents of this field? Once the stateid is established as a result of OPEN, is the server allowed to change the value of stateid4.opaque as a result of subsequent OPEN (upgrade), OPEN_DOWNGRADE? The same question applies to the LOCK stateid and the sequence of LOCK and LOCKU operations. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Jul 06 17:26:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6vK4-0005En-PF; Fri, 06 Jul 2007 17:26:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6vK3-0005Ei-7I for nfsv4@ietf.org; Fri, 06 Jul 2007 17:26:39 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6vJy-0001lB-Mv for nfsv4@ietf.org; Fri, 06 Jul 2007 17:26:39 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l66LQXLN000176 for ; Fri, 6 Jul 2007 21:26:34 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKS0000100ALM00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Fri, 06 Jul 2007 15:26:33 -0600 (MDT) Received: from [129.153.128.195] (sca-ea-proxy-2.Sun.COM [192.18.43.27]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKS009XQ0W87X00@mail-amer.sun.com>; Fri, 06 Jul 2007 15:26:33 -0600 (MDT) Date: Fri, 06 Jul 2007 16:26:32 -0500 From: Spencer Shepler Subject: Re: stateid4.opaque requirements (was Re: [nfsv4] An issue regarding free byte-range lock state) In-reply-to: To: "Noveck, Dave" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 6, 2007, at 3:49 PM, Noveck, Dave wrote: > My preference would be that the server in both of these > cases MUST return the same stateid4.opaque field and an > stateid4.seqid. This would allow the client the > flexibility to send a seqid of zero in cases where he > didn't care which instance he acted on, a non-zero value > in those cases in which he did. This is fine with me. Just wanted the specifics given the significant change from 4.0. Spencer > > -----Original Message----- > From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM] > Sent: Thursday, July 05, 2007 2:02 PM > To: Noveck, Dave > Cc: Peter Varga; nfsv4@ietf.org > Subject: stateid4.opaque requirements (was Re: [nfsv4] An issue > regarding free byte-range lock state) > > > > On Jul 5, 2007, at 9:35 AM, Noveck, Dave wrote: > >> >>> I don't have a strong opinion -- a slight preference >>> for the stateid.seqid on read/write to provide for this. >>> So, whatever everyone else wants. >> >> Allowing the seqid to be sent or not as the client chooses >> allows this. What I really don't want a scheme that forces >> the seqid to be sent, even when the locks are not mandatory, >> which is going to be a commmon case. > > This is fine with me. > > The final question I would like to resolve in this thread is > the one I asked about the requirements or use of the > stateid4.opaque portion of the stateid. > > What are the requirements on the server about the contents > of this field? Once the stateid is established as a > result of OPEN, is the server allowed to change the > value of stateid4.opaque as a result of subsequent OPEN (upgrade), > OPEN_DOWNGRADE? The same question applies to the LOCK stateid > and the sequence of LOCK and LOCKU operations. > > Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From wnigz@academy.com Sat Jul 07 00:27:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I71tk-0008D6-0X for nfsv4-archive@lists.ietf.org; Sat, 07 Jul 2007 00:27:56 -0400 Received: from adsl-83-194-188.asm.bellsouth.net ([65.83.194.188]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I71tf-0003vX-Kr for nfsv4-archive@lists.ietf.org; Sat, 07 Jul 2007 00:27:55 -0400 Received: from gqg ([56.65.75.59]) by adsl-83-194-188.asm.bellsouth.net with Microsoft SMTPSVC(6.0.3790.211); Sat, 7 Jul 2007 00:27:50 -0400 Message-ID: <468F1646.3030007@academy.com> Date: Sat, 7 Jul 2007 00:27:50 -0400 From: Mccormick User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: As part of the Dojo Toolkit project, Sun will be contributing AJAX widgets, helping with internationalization efforts and refining documentation. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.7 (+++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 VPSN WILL MOVE LIKE A COMET AND ITS ONLY GOING TO GET BETTER! Watch this SUPERNOVA closely MONDAY! VISION AIRSHIPS INC Symbol: VPSN Price: $0.021 BANGKOK, THAILAND, July 2007 Advertising Agencies Ready to Ink Deals! The company wishes to announce that it is in final negotiations for representation with some of the world's largest advertising agencies to market and reserve the blimps for there clients. VPSN THE RISING STAR, IS SET FOR SUPERNOVA STATUS ON MONDAY! Partial submit: An HTML page can submit form data as needed without requiring a full page refresh. Consider using the JavaScript technology DOM APIs to create or modify HTML elements within JavaScript technology code. The support for JavaScript technology DOM APIs can differ in various browsers, so you must take care when developing applications. We developed and continue to refine techniques for how to use AJAX with JSF. All the source code is included. net, is an open source JavaScript wrapper framework for the Java platform. Sun plans to actively participate in these two communities to help drive open standards for AJAX programming and increase interoperability across AJAX technologies. It is assumed that most users are only going to see the jMaki JSP tag handler or JSF component. And those environments are pretty limited. The CometSelector is used to handle the CometContext. Next Page: Pick your favorite blunder. This means that the widget uses the dojo library. The string representation of the XML document that was returned may be accessed by calling req. Please excuse my slow pace of speaking, I'm aware that we have a large contingent of European JSF developers and my tendency is to speak fast American English. Sun is also a new sponsor of the prestigious Dojo Foundation and will participate in the Dojo Toolkit project. Maybe he'll do a blog on how to do it! war file, I extracted ajax-wrapper-comp. opinion about home business Free sites for changing resoltution of images If someone can resolve this you'll be rewarded can i submit sitemap to msn How to target the World Wide Web! Sun also launched two developer web portals: developers. Sun Microsystems announced that they have introduced a preview of a plug-in for NetBeans developers so they can take advantage of jMaki's usefulness in application building. All of the same rules apply. You have to create these widgets using a markup. When the statement req. js and placed them into resources. Sun's philosophy of sharing innovation and building communities is at the forefront of the next wave of computing: the Participation Age. Java technology provides a good base to develop and deploy Ajax-based applications with APIs for tying in HTTP processing, databases, web services, XML processing, and business objects. Visit the Ajax Developer Resource Center. Any suggestions as to what I'm doing that is dumb? From zjxo@zoominternet.net Sat Jul 07 21:01:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7L9L-0005Sq-Ax for nfsv4-archive@lists.ietf.org; Sat, 07 Jul 2007 21:01:19 -0400 Received: from [76.76.79.135] (helo=ztbrlsp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I7L9D-0003QF-Jk for nfsv4-archive@lists.ietf.org; Sat, 07 Jul 2007 21:01:19 -0400 Received: from crge ([49.68.59.207]) by ztbrlsp (8.13.1/8.13.1) with SMTP id l68110gJ026268; Sat, 7 Jul 2007 19:01:00 -0600 Message-ID: <46903720.1070708@zoominternet.net> Date: Sat, 7 Jul 2007 19:00:16 -0600 From: swoon User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: Re: complaint.26de638d.pdf Content-Type: multipart/mixed; boundary="------------010304070706030804050703" X-Spam-Score: 4.3 (++++) X-Scan-Signature: 3cb75504e283d08ef0543f38ba481a75 --------------010304070706030804050703 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------010304070706030804050703 Content-Type: application/pdf; name="complaint.26de638d.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="complaint.26de638d.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDM5OSAyODBdCi9Dcm9w Qm94IFswIDAgMzk5IDI4MF0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQozOTkgMCAwIDI4MCAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDM5OQovSGVpZ2h0 IDI4MAovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp1PqFRqVTqlVq1XrFZr Vbrldr1fsFhoqNGg0XcDs8DAcQYYDZawtcCH0YZcFucCGQ+H11ACwgtxtzicSNu8HCMOFkEvkiZa 4CIeggyyWFKEFtNey4AviNgw0y1bZbBweFeqNetmYN4gmpg5Bz7DYbLH1xzUIxcM24Au+St6Rs9+ gmA0OjhOs1YeEj6wq4gZl5gA2Gx2cbYONXewgQRAe84GVglpXdu0WciPIhvR3MIDzL9npipQWDTu +ZzcGesFGVR4FqtHjZZIoEyCBtYabLuMgrXNWtCCvcAEDoWxqBho3bvr6/KBPCgTaIW8jVl2EjCI GLiBEiwrYFuXZIw2hL2IZA5huygjuv2RrwAGXb/EiMp9A8WRZIUYMPw6AERoG58TxShgPOrFsHPY YMgru6pcQegxdvgvLDwzDCBSGgRZM8gT4qi7z+S4gcAABASCt8ZqBSqgUEoGxbMtqg86oUZYzLq2 EKQWAELwdMyGS8gcYIIMzdTSgVDoeXb2oXOBaRkgQoCg/IIka1geIKfUdR4WVCv7LrC0TI1GTRFb bIICxcSoYIBr8cTqz3Rs7oIw9YPBLqDhotZGzKp9LwG2kNzSIlQ19NAAGacQAR+g7EsVQaBQbPEW M07E/TPQLjAGwMOIRWwADMFjC1Qh4IrSYNzoNZyDUmgbu0AWFczOgwioYzNF3LU7oQq3CDwPd90I QzN7F2s641EAC3YYpkaOCZbBEbRZhgsGhhzTNJml3aCDWktLFxXds/oatMwuBQM7FgvzSoGVdwIV NyD3GN9zILjJb1Uw1poTgiCWCu7vOA8hd5i3LnoVfaB5uu7nzDe88oO2+gQhoIAaNmKBasglFqli K1YmYISIRja0Y+gtpL5kaCsOg81oZTk1TO+l5AA++YIdrqBaigV8h9r+Mrahu32qhW+aFSsxV4AG jrcgulITjxlhoEjF8BAGoZ9q6DXOwQeVdzq5azmC4zhEiqlgutMuDnu7t0gm0oIZPDztf9cPUh+5 wlDSCML1kFIbhm/ABfIAEjOiIANJZlh5BuuIJQ9zr5OujIRySEGCWXK8ugfj+S5+7Rcg92nEHlW7 yhFzrnIa494gz9qmufDd8gx9CIMrrrTc/Z1OEE0JtToqPIGPUHwUBYo3IG3Ehb8AAJhO2DIXYsFF l6fqMtG4wQeNle1AYaYwWaMNIK8czRrFrkJMekx6AAHzqtGCocWAUIIq7II9cg72WBQ1e+nOExaI VoDaocUhTX32uuABBs/4uB9MAKo/Qgr/kAnKaiud1AyQWGuMaXVwcBCBQGFgr4y66j2slII1ZqJk ghvydiasWSODBnFMIgVZyUBdj1fVEtOaGItw/guQscULmgg0MlHmHTjntxuX84ggkd2fC7i2QwCM YmkucUEQl5IUBaF6dKQNaBg4kx4ftE2A8TyPLSABDhwqj1IE4jpHYhcjjYOQIVH0kQA3ty2YInJn 8iyBygTtLBcZCJIyqciYowSrZUGKCgAaMhYpCTOJxLQlUPyFQkduRp7JogLAWmhN2b035wELD7Jl dqPjREER280hiIAfPqIjAiWxOmHQUF3CEh6SJqNuIK6giUJyHt8KSI0/4ZU3kFP2rMpYuwIzkP2j gWUuDmv4HqYtIa7wfDDBIJEeqpiDDLnwZct8CYuEJVfP6fst5eqfCI3lhwUE2yGovRlvK5QgiRGC kcYaKBl0gIYu2fhEafxBjKQqUxKRbjDB8LQ7aYjfULiBJxrgjVPI7bwQU7yzUcFKNvQ2oZBAiSkI GzRr9HEGM6LdTyZ5BwzC4YnQogQZqb0eqPUmQQMghyvluaxioywi0rn02gSIwwhCRQFTQ3zm2TTU NzQAgi8VIkRNzPZkBFphtsc4CwcVcDn1zFpIKpgy5lpSdk9GHY9aCJfMODJmgsmvlFQawMgofSCj NcNWIiAtyDJDp/WRAQo6bi4BpUeGIHo0WPTes5h4AH6qGmKZ1zlyXbEDaBb50RA1g3WAMFAvkcwL RQIKLcSNtGOLPsC5GopEQfSRLcXU25i7MXUOZbhKzWEHMEk6QQ56cmaMrtaURa1XSB3LHEBG8c1y GTBndbsg83HXr6QGs6Dkwle3NL/LFJtVXOqmaABYRqrqWXpqWtUKAfQoSaRqLsCw4pg3fB9gNjj2 3u34vOw2WJC3qTXMLLo5mKzMneGWjW0jQL83SNVWkopd5yMmhZX+IAPhprMdsMEKEvman2eEQgUZ B2GXXcnikW5rASOBlRO53t+BcRXO/AOXjncsybS7NtKjfYD4hjW6RIJA75EKjUM042ESBPZp3moh LJb2nNvwdAYaEzviwB8Lucbh2E5L0ln8gT+i+oEhBjApKackyh0mQLKiBBdrvNZAbKhBsERMIPm1 TTC84VWIcAMRo4svpfiSQfMjUgAD6zPLos52M1tTABqxIwjc4HGjU8ggyB88uTIK0DP0p0GHX10g wKEw7ou3B8LjYyrToC3Bo/KCdTVlsN1naTSjpDLxyShUEnxhZNaeQfqEtGpCBg+1OQXVOSiDYMSg XGbeHdYENWKam5Kok675LS4SArAdjZZOM0rOLiy7O/kql8hhtFZbB3Sd9wZDNrximu0rbfAW+kHr uXtrxA9z8XABad2PGsrlGL3aExZobuzxRIMsMoEX1WwQdHWiczbmEFEapoDwsaTYM6C40g2XFVoa 4MkBW5BOFNi5YbgZZ9xR8TM1t26oAEyoX5rMy9loyFy2GCBHjfDdQa8zQ7bGpDuzyJZK8UgVdzNJ lXPv4wde05rKcZU8pFoADZ1Qdd1tJe+eprMycYYJ5uiMFkX5EWKHOumhNZd7yZihg+Kqj4y5acEH xKC5TUvjK6KENMW9kWU29pIBxAoHw2Pu0V4bygdNevB9enTnBLub2lpm3aUngAZsAPXp7zdh0hA+ mMUXa3F+W7irmZpMQnFZEPMyV1klTr3nYecthZQJT5DfS+9ivD+7xGMQE0BlC/7KA70wpM11sRvX d+IOpyhNt7K7ZPELoJwifAaMOhgq4N7wBCerQJIk5lMs2tqwEwIwJQJiuALJ8wKQMQMiYKBCaPLo jCIAPKjvrvEFniCNowNQUCdwLiIBcNciHHik1hllMqODMjyB6qcgBmStGwEMAAAQTwUwgCWtGNHE GCDIkL+iHB9N8iGvBAAHmFqwZP7s2kDt/F5Fgwhv/t4mstoQgwuiXI0qmrHMDNZvyHJDUQAwliGI wOxQGJrwpkOwqrrCBo0jsl4qbHHEvQAwvQ9iPO9CBPDpEqCiBk5AfFfEoC7jBEoFOwiuim4HHC3s MDbwpvIiBMGHJEyw/QnEBq2Lcw+RPCTRMiCumRBLonKnTpDFZs7pexGPKCCkBMwNswpnHDPRLOLP liBxARKiDrGRPxeiMxMv/xSNsmvpHKslANMxFRVpKP4xXiBIORJRBAoGXvYvmgAAhtxwiPCQexfR uCNIJJ6QsjQoAlqmKD/sAkMMfgAEClmxkouk2EBv4rlxniCRZG+jyGlNFC8RsRguXMiRux/iNRsN 7gfEmDVjBpfIDBXGHOxOZsyKbBcAZKPIUCCx5iBx6nGq2KclbGVn6k4ReSASQCTAygiAaC+A+rVG OloAhBbgPAzKyBdhcNfiEsyG8knuth9tsloSMtmlAL6RhR/SQygiYyUDLh6yWSXNyuTiJHnOtweO MCFGVuoShSpiiHwj2GeSqSswNMfsLytSvSvywSwyxSxyySyyzSzy0S0y1S1y2S2y3S3y4S4y5S5y 6S6y7S7y8S8y9S9y+S+idJmHAkHo5EOg+lkB6oGSGy/TFNnImTAOVEBjfO/iBTCh6hZE1hRgLRkk DwXLvnihMTDhYwVl9JbBlw/LQwtE3zIiFhRzMR2jMpkzFiknik6kqkDkhm4zWTMoQEHDjTOFDDYD bjTOkjMqJjQk1nAkmm4sIi4EoTTA+gIhgwOEuhgnkpziEzcx2zbRBnkw9TYieR8xrTaROndSLCCE 3I6RnGllDqRkAj7EmABuuHAzqyGCBtonZnxs3NPiERRumnGguIryHzvCkDCxQwSAAQLKbGrG4xRk 3DfkYQfiBn4DcrlsMT2wHwSlgghN9DPpnzuvnJ9hYFDm8kiuO0BCiKuOKqOnko3iBqv0PqwnHFGA eUNCE0JCCtcp3DIScKDCCUaRGsRJmFNEB0EJ80LwShhlOLC0TClhYCzsgUUohCBx+GgUG0I0fOUP jmdjctcgSL1hd0dAfAggZEEhYTLSYUrncE5rQkvTM0ViGUjFoUZ0lUlilCzooUKRRn4UpqhjM0IO 8vjzgR3yKAPAeAgneUwhphIjOBYPIgBhcU0Hip8yPthqwQfKZ06ClC/T7pxx0vnBxBIhInzkSA+g +hhloG0jUztCExMk6r+my1CvhH5MyHiwkUYygTr1KsMKyVMCii4MyNHBaVOrpD/kOhIsRlkEvzWB RoA1VGDImBGgeBIoYwTFqm5khi61ZEJVfVimDNZ1iCFBZVlDFm0loKyPqVeCbysCLgLTWVzpKDaV oDe1qFq0nC9TkT6R3FGC4QCSkrchxRzVwV2LfRtVyz/vUV0SvJ3H+C9E0lgzECXrDWEWJWJ2KWKy 7zqCTES1QWLRuPj0niIw0mBVapICCsnuxI7KRgaESgghpjXVs2OQU0mhhka0ClCCI2RiFrl2TBYB 6gSJiU0gAWXOOWYQMH5V1CE00TJrM0jNlLJiFh6xcnAxqk7JggoOmTfWiQBGeTgmsqdoWFF0NBI1 SEvg+hGgzTWRWEjAWMZiDRcj9lzkEtw0w2GtuNQWswNSSpzSnQfWusUVPk0sw1jTCwSzypKFqsz2 SPBjdDkB61YExW5kAODD72Q27pwBlkfUnn5Gyq9HUlnmlKvm00jD3TYFcLZVpQGgSB6oT3Ikvh63 KXKwBC0j92epKjyE0kh3QR6J9iLPDjbpdK03WIu3X3YJnFbITPDAI3NxBXbumXQI7QpOWI7DZMKC F3ep0GqAhhlggqauXXh3iCwtwXLhZDjPDW+C+DWE0o/hcAgvlFnjS0LjTAI3pk5hl0SCFADX5NDu UXtEEjb2sXvpoW8mPm/Gyjci+Ef313fiHq2X7JZ3qNhV84AW8Umzn3/iMwR4JSynVgIxciYO14M2 YGSQZYOyoIHFgLu4QJwgSAoDUHhiTFvghu9NGQ/0KCDWWVok0FgNuE10/YUitASAPDw3L2bCSFvg B4Y3FLlCFgaLThFkEmvm83aYfCws/H1EYNGxg1hCKLJCEC1kNlg4aiCG/GzqoB9YpYpivs/DjBYh h0mqnISk71wuYEfEfSDQA4jTTCCYSCDFjLckfol4e40CrXUxikXxcRtEMABvX31k1Y6PXt6w9Y8T 25DiFY+kBzo155BCutWoJxF4+Nl1qOjhZMzlz4MFeG3kmjq203CZJi+oFJC5NCuTfFRFVGu5RALG cCIkcBGzLX6B6kHsSjb5ew2FqoyYLZYio5ZujCyxjCBJ7GykhtfGTzotoymjLRxoFhhvkiBi8oZF LO3ZkCtYwz8lnkwZmlmFYBXKMX3ZePfM/v3iHV3IyNEjIi3kbrZEs2P5wirZxiIBxABiyoCru37S ITRCRgZF60hZ9x/mV6F6HaH6IaI6JaJ6KaK6LaL6MaM6NaN6OaO6PaP6QaQ6RaR6SaSiuDZulV3a NsS32p9oHCaQpMfhgu8CSkDk3HuAB5AsbJ4ZTaOJyHWjvjx0Sm/I5GCJ3JQSrPKadIazWFXi4mgH ipBsRNOoRHsN6MiJW5jiFaaCDP8CLafonk8EeC1Tosnaey6xc6FFnmFjOJdIp0mxE4IwlE4yrSZF qv1iFHs6oCCLiK7UgQtXVgggym4x2o5oCvwatiG6vCKTTgoEOq8iCbBAPKWRD0m0TRcxp5WHSueI FxzqnkBN8RBkKlDyuwWXdlB32xr5KP8msi7jHj+m31UurCLIpsjRqVbv418MMOdGJi5C+D1qDazy 6JxoLPbnSkdG3yilbjlbIjIl/hb6DX9RtDL5S0pUOOja+EFh6i/bZRlCKbayf7bt0WgL57PENl3t CoCtkzFbiAfH5JzGKNlaxvVn4kQG1bnETiLNABxPvDjbqzJ7r5YG6H7J6NP0PCDkyjFkqocGgbcn fjgbzts1m0BHDVGEBqH6hFjqJusnHFmi5Z1iCKij878iK3RLMwDDFqkoIw/PRstKpn8FBjfNPsIq N22SKHYHbk8WmGCSJCF6qENjWSEE58Dy7Ey8LRhDOFFrTKoFABmrbLB8QkKjPGdiK1dqi8UrOriu KZEEuq9q+0fj8oQrBIFl+iFgSBmuhpnk8VdoWLNceiErQtVXOZwboy6plrtO+kFGvr9KwrbXFiB8 roHkNKKa1CF8rbpH5Y8xtxhRgtm8wmPLys/h63SQTOjjVv5pZCB82Nhqb9BEWMuRjOdGKzJkBLwV MMRsSxRc9bmmuMCAZBxGaDFgoDn216kjaEmhZZfiHVdsdFqOUrQMSOWGEsUlDkDnDdHZ0HubpCKv 5uLwZhRnP2htrMSbAdiGvBIjHM8XvlzuYG8MnMoJrpQP0oeo8gSdciK9ux8CCK7wsLHEg2/L5H4Z +iUwHVllWOwKf4saqUDmu9sHpaS6lwJOwaJply8AfOH9KSQWjikvDJm+F+GSpCPXvCIOt12OvCK8 6+MKBJHCj+HijHVlKoya8CIpk7hCOnV+CiSeEyl3DCJ7ELnCJyuIJPzFHXLz+CIZVQXmwRbVciLp k13d5p+jgNHk3oAmCJPFFjU4Wqw3xzNocSIIXyKdcqg70iEtwaWnPJr1J6uCHeV7wnJjZuBCJ+cw medynDQjOeRiH9Jh6z/56iHrri63oJ+rGi5DqzotSekLTqJlfVOp6hxEcXZps6CtgHHdzZfqTQo6 m4xQCs8KkADFjQiC59ok8++8iUSpXlHEjaVeW+kGcmwDfJMEpD2NZr7ts/LUYBdkQkAgzca+3yKc 0Vrrrl2B6h9q1pegaEfqfxMl4jC7Hu/nkou76RMlz1dyYSI/CkPmaZ+/afbOrfcrNCBLOGop6fRP ESPxTVhKsQAocC68z2FbPTGRSLOEZfQ5VjxvAMyioEU+Gro4UNJjFggmMrwm38ndIFG9NsDBl/vz PkBo1CADxlgCCLiCMFcDRZGZgwSHQ8AENdpFllADQQfMsLMuGwdxMFGxSCB6Hs2CDKIQ8zRBdrhl ssaMOHiRmvVMSmIDwAPV9xCEwuEAAaLdhrAoSSCLuHAYfACmwcLTiIDSIDJms1drJI1KHQaIS+aT aHUoABEI1yDw+O0Oi0exxSLQ+o2qPwSBw6qWi9Xu+X2/SmyQQoXaHrKCOKHVuCEGhpFxWeCSaCXk AV6U3eHMt6iSCPWH0+HTqHXPAqO9RKM3GnMtG5gAR2CYqZQ7EACUYmH5bCQ7ZgC7o1656uaJmyvR wpR0GkAAoZAAYHmavWsG52jKSeH4qubq7Zjhc9gj7nVzoR0PURd82x6mLw5GymPiTtZO//X7fe99 BabsABbanEnQfO0Mrzh84CHMknyHBYh7XM6EhZO+jCcoe0zngshTqqkIaHj6jDWGWwJgwAEkBII3 oAPeABpmCZpglku6KlwerLGWlxlgG3rNQg4K0NEAAzQs/q5J2YZbgG8SxocPr9t81shr05bPGnBq 9O43yHu+XbwvGqToRUesjSQyCJFgHxdw89yII7Er5uW/E4Tiv79IwYMQka2oAJ01wyyzBCcH1QJc QY16Xl3HSCQim6HNA/gAQskAPAGvbboJNIfB9OxdxUAESMwIi1IdFsXocfQoUCfS1UNNceL010hE bSRGgsucjKowakzNND90bTjyGHLcpyqqQgo4l6Hug79JrK9quNhWa0odXFKzRUK6B4Ehlvm6E5W7 by/U1TraSfUofBpLdOTyiFBMylxdsojkeUWAZdoq51XoPWIaV8nFKrKjBI01flv4JKN9w0qRYEip VeYDO6+XOjppl2cSPtglIgool1kT8gllrLLs131Thg1soyTiHhRdshAVwvccVyYLmWZvrgdzAHi9 1PuZYSBJZV6lhCScGCYIPYO++A43mml5lpMHL9ii6vtj6dodqmhTXorrqEolcII1Doqdp2mbJsuz bO15g3eWWEbRt237huO5bnum6r1tQoaxu2975vu/b/wHA8FwfCcLw3D8RxPFcXxnG8dx/IcjyXJ8 pyvLcvzHM81zfOc7z3P9B0PRdH0nS9N0/UdT1XV9Z1vXdf2HY9l2fadr23b9x3Pdd33ne99b759/ pae6hOXgvwIPDEaYLUIrsPV0anHj4LUHXb0rkEr5bksL96b7eTwuiTLM4ASb6CIHESIZNr7xxAsU ftr/FCHaNLfDfd+EG3Owy0aozpfgInFFGHQvYAxYEpeiWg+ROAfP4L4FxQjh06LdS2i4wo9RGkrg g8lOxDyZEcOcBEGjOGCP+O0pguQ4hlvrQCcwPr1Tni4FG/Bi69EIl7GGsAjhDhMQiZxAlCoZQytP ZmVuF7/CWwzfsABGENnrlJJSyEhzPoOllEbDNPpegaQHIeypJhe0SkpWBDJ/JeoIJVhy/NvaHCHM NYuMtFiPyuHJRGLIjoAxZCygyGaDbGjMJHhAiqH0VTnm+GWc6LJgjyEQhOr2FRBE9iRChEdjz746 KiF3HiPRekxQ7IIotRxKRRxCk8UI/oJDelKbVGwggtFMGKMClQxMkwiQ3aoR1okmY8lcRDDkW5Di zj6h6RBny9Tfl/i4Q5lQEXzFoaeK4AZc2Llcgib5Q6Ym/ysAAUxlpXiNsTZgXpIRr2PEqC4bE/iR yHHCHqpIZciZjSHRVIl55gIoAAPm9Gb5ZBgnaf42yGbapMLLieQ6X5EJQAAnpKIMqmDYAeOoEJIx SWcC7IkYKbjAXuIrOzMkzz/Gsy6pAZdd9EzOnBExO0mY9ZjEEYGWiZJuFwE4oBOMtE1UQtWmyQ8p hXSCAWn6xSl6FScNUDMcYxUfzKGepSB4WKNixneQnMqRb3FGqNI6wsxCvjhIoYvSIvlByH0JSuaM UaApS0sN5RRJU9SBmYnyYUAFXloqJLRNqk79FGHBpa1WdBentxAK4wMpEM22k4pwQ9rbdptJpWi8 siiI5xLWOhUev5mIckvGCZ5ThLZ1sdNALumJEIDviABTFi5IJ+w7V8Ug5Ao6gKiUTDeTlskUztFj Z4qSnFjv/rXadjlbqN1xIcYa19sW0tql2VyvE5K9VTkMZ2K6JiuMmapMmKSomYXUJHccvVRwuMZU dGputjVrK+Z1KKoAuxmoqkyI0EkezFkFrWvUjrMH6mWQkcJAVkbRmfIURG0SlhaEgMwI01pirW3F sMWptQA74Q4FvfY9z9S0XTEiSKu1v1GlkOhW8zKw8NiywaqLB5p6DV1AAcsHxmx6yEunJwW4NFzR dYXF9ZzMFtEQA9iSmxOLwAsfAbqsTfJtHjI6rNbVki9XreyMMYLPkgIKROTgRsIjK2fueAAII03k 3/Iex8wMzEDREpcQ9N5UhgiwygX2QB96zvJfBEyD10JCnPzIk8l+SjtGupGnAGQPJfYqPGBHKWZm kMrbnkRv50GvXOP6trRDBLyFSQkUhRuYHTUjNnTGVhFkDGZOpPhsugjesXoK8Jx+lS/A+CCDIIIj dH6q1o7IcRxm65dEjUPWuvXGx2rxM0+uJNaxpdvYJ7LfJpuNAHBgXcEz8Y/bhYJ/zhJrrAdtYLXj Mo5Fo2W4xj+n9hH1sOVKc7GbMTYQawrLIAJimusFYsrmszaNnMC1QgW7D7GDhHqkv+CaYx5febRi xfNJm5IrlKYDAwoFHMoTIou1S+7dzoSnb7i34mqVDpIxIPoXkP22RAM2QmNHPRzm8w4y0BDTIG0G llvR6qYu4TveS72Yz1SIXsz1AT7vxHrCrldCid1qL03mEYHjOVz2fvJBR1C7swJDx62cGIZmvYq0 Q0Bnqj2JK+cFdU7+XZoaEMHho9YRkEBIehd59hl3pz+Wngu4BYEKmms1UVkJPKYCgEQ5fISVQRPe ENHMIzMJ5MUo0u49UzczaMTjuewC7EWCgr4kECAfd7nXFe2BsE7KZmd4IYZ10JFbFxi0Ei9S9pSr mMOA2ASCQH8kaMjlkOrCN711MghpmiMWO8Bbrb4DW+gMz1411Za/Yhp1u43vTEUkQRVKUgnfI8oS 920Tg7gYt90IhY7u9tltST76X7XE5CJDDFcFDMa2t9eIraSlvXj3mGxTQBHyi/ME/gulbYeoEeVG sO2/KFcIePG8OtsLQW4ZM9ctOxu/o+QSwRG/uuK6oIORa/2MwviQWIOFw/K1ELM+K0sK+sU7RBCt 2+dAKUsx6tpAnAacUsE+4xUIa/uD69UL6NcIam0/SEimS/YPopoJSxo2aEalYfi+a5AzQt8seAiy SruJxAGzsL21mVsB82amUO0VSlCYuVwf4Hq980g0g6SIIgiO4vtA6Nyy0xUo2xXBE+SUAsfBMJGa GWscWv+YWzIxEnIU44+QiAjC4PyVCCGB4AGBo/QKWaAqSby5eLwIclkw2zqpcMDCG/sIeeq+omAn 6sEIcuaWZEKlC6KIgRQN630KdBW9qH1By6nD2JWbUvbCSimIfDCJZEI4REOLsB4GCBoO0CCFkKMF kKRC+AA4kqnCVDOAAhhDjC6cTDmIqp7BWIGwQEi48VAJqAi1uL4X8LICGCGFiTeAMXq6CtOM2OgG HGe1e9eFhF4N0KKUOEaMCwPGNCI+jCOSgMlGe4ouCJTG45UIcoWL0tGSNHSlSLhGWSgIe6gPnGkT yKsGamaCFFcp8IIFjF+hBG4IgDKaCMzFrHE5AFhHNFa/agQRSI0nItWnCIchgOcQ07ecO00JwNcL uCEwyABBcZmAM/5Gee846zmCgAsViO4FgZKo3GU0MpcI4uQNfJeEiD6TSpGQtIUK0B9HrFGLQ+ML 8KJJ9CNGVCKYLF9DCGXGxIgkMM8uybI0MPeOmNeIoakUsGGGaFkscnHJS18IJJrJWYK/mPcRCP8I fKPJkiiHrHycK+YbdK7EybnC++vLXLhLjMUTg1ZMWd2TtKmcw3829LEZlK/MceEgwRsmqcUyYKkY Q79MoctEvMwcmOXM4MuJTEWbo7awvBKTjMmaZNCL8+vNoKlNrMXLM8qI8AtMiLQzSmcJTJuL5CtK iL64uzPKy+cJenObuJw9KM2bLNnBoYIzNNwrmdshGBoNc9CpzKGTsJAPfCkj0FwzmS9GkasGGEaa UPII4D6Oce8IECG0mO4Mw8HAsN8kInKx4l239PUJcjO29Oe9MM8rfPmYIviWMTgvYM9OQPqY0xaI eIEL8a2IbO6dWBIA87mGWiQ9CFgWq3cN2KiEijwVnH2LUvYyuI6UORpCGqiGCLMNwJcOc2fK6x2K kK8KQN+UOi2LIM2WMNcf8B9BQR6k4RpDBOcJTRmylRrPmz6FkKbC1QypjHW9CSyWzP0KlSJRRFXR XI8UPGwSVRhPgRskOWQQc5ZSgmIzTSrR6imh3OucmlQi5S8mBDULvRGveCFMiV8U5MbBAkY5YDKb yKSF21eB5JuK8NmKeV9PwUcW4kS/2L4A8Fwt1QEIhUFFmzu1IRXFyFgAsMMRnTmLzPUF2FiKKJmL 8lrPROSiskg/aYWFvGwjZDHImIJNWIfPMy7U8Q0lQ+dHYQe+tTicmKKi3I8Vw6SLmKjA8K5JQt+L 4gSB9EWOEkzUPUS+UgOi5UbI6JStHPNMqyqhjNRUAIfWm6S2qUqLnVFWKRPHWnvDUL4D7MRJOrkT 1VgF2SPTCugliWJFc1gp/E9NeN2O+3Kc26SYixVWROSKi9KGGB4CE/GlFXqlML6NAMgpjWoOyO3O iCgXPEYo3F8M+IgznLaL2BoBoJcUGK4TMM07tQhOjYpXK12CgK9VEBJY6uKGCRymJOMIcCDXlLZL cmAf4JgMqrgRwAHX1FFOFDMy5UxZmJTZCpGLvLI/8dEM2A8kyLvZ09CfI4qNGIxYdIYLQhoGaAiO /OAK4IyGDPe9fCMOeBpIqCGEWLROKMCjs8GNA7efcB9YdZ9aAFlXAMmNbMjZZbYK+9LRDZiMSYCM CV8LIf48GMKNa5uYwuKOdbLbOr1W3EwUYekRtSGKTbiFgjYfAbUmnalZELKj1WGcpQzZwLHa6YKI 4JqTghAqoy2BoH1K6PwbVStaaMOI3Y8Wklra+bgsWwyI4I6HqH1awVwODd8a2Wy5CCC72jzamRa+ PEDUaAHe7aUsEBlcTdFd3dLeSaIVLedaaKeFpR/OnNKPqpi3odhfNN3ea4VLlUrMuPtSGMNMTBGz De8i6TjfMIffs6IK5fZSxdbffMW3QaJfcdcANR/SzgZgrJYFgXodOX8mVcEuKEa9Zdm2fgrfkbev TOCdye3gWIfg29fhIbQAGRCiWdXhUsAbtQdNSaXhucbhSTlhZCdE4aWY/h0cUYiNgJMAGFcN6gwF lOavoIhClN2KSaJZCaGF2UzhMbPiGIwFwBlJ+ZlhuJQGXgwPxBRMCW+tzinZ6L9jDjHc8nsPwGGZ 7f8xSJxjQjukNhoTlZ1hFLuK3CsEa8IEai4GaHFECBoM4xbVAvDi2JZRIU2MgFiZxFtjNZ0FhNag 8xo7sZoMC9FkUUZi4GXT+Z2L0BkBljFgy9e/oNgYiXUH0x7kAUmPeYW2SKlGfi4L3kiaIXgN9AYV EgM4PlLlOMCv/eGN8EiT6x7CLlmMnkO9s1SSMImaoChlzFsKETsJfg6Znj27WU6EbFKDLj/kCVxk IrWPmUIFhDEYWYoOEhGLJjNU3AEhyB8Fo+YFhAZlQMPm8n8KFhgrbm4nwHqDMFu5HIcgKS2WWKUI 4qxXc+uWoJPnseWUmXeS3JIAAH0lrlgRSChlmTyN61wQFnRlMgKMvoUxeXyPTkuKllK/bmIMDm/o uk2pdo2vYMQhGNnmewmYXgE+SMDNIaYweF2FWMPAaQwGGGXbMMizqe8O4AHnUHEZ/Z0e1CZbe8c8 nqA4IJCLuGHqLqOJOKuOgEiA9oFoJidoNZ0KomMIEOEqAHEF2A9oaJSBkKMeWKVqCWWTyFwCJq2J jLkT/XCymYBnQ9QL02qt7CIRHrdpSX7HszAY+RUm8QQOcMkUPJerCgYzDXebk2cXpqEU6JBJhYBT sXErWUbFfswTVYpd9D7qHr6y3W7OSMCI+JCO0OqNqfWKwM/UobZtNOwK4XptVn6t8OqA9OGOwtIK M2cIIFXhgXU0YX+jFoLpARvpHXCNc+frbuJiwJPodbcJTsdidtrslYoCFdCL0yLjcnvGAbQS0NER IUaQwFugaOEXUg/ZoRoMsoWXpQ/N2BpjQUOPzuJM8UbLElkvcLtvdtpNUIOY/WYoUJfZ2Klv6S3v +aoMgQ1uKNtteSULI7aR+FwAjr2oOb1jiOYMtPM+vv8NmYu+fHcIgAHlKB9ksOYFgGnQjtPcVsgM O5iGmHFiOUOWzhdWewBv9P2bm/okyF2NEEaWxRuM6WA85BGVOH0CKIwB8iGNctFj5IfkkL6A888M yA9a7hdwKnuMxyaYHEXe6IIVMUCCKN0VW3mVEKoOuMgMty8UpW6GnohrrEANYjkAiCIQPHjVS0eC CUxyuL5y4xU+eeXy9QcUnlMKeChxpnsLHz6Pe6SK8ZIKcRYatkPOKLQ0rmmhJB4bpojXsNeB4RgE jN9WgUxPYbLzDWMK4NvwMPB1Vya7fNWY+B9zaPsFhkjoPcXzqNZkqPxrll6T1t+L2qGZ8ei5l1aS 9OVojLoTnEAfsz+pBi0c5AeJDROcrg2REnCO1NiW7nbF/cWNBeUuAb/3Kcj22c4Yq9tgt3oaZRd3 r3x3zffhl3136cj3vhf4APvh9394KW6ZDvUZoYWJpFg4sTj4J4N4iPu3p4SZlhgF2LDHtQkL4IMJ iN7mCu5I3UJ4l5JH4xbXcnKPig9vhr7tuLwWzg6apceMu26gbrcNyFxzC2wOfxh0lI35P5L6DJYP F5RIjvdLlq2POgPx2VGN9kORkhwqqQajkrPHXzup+MsMpg30mmP6F69vQatWBosCIDKUOLINAIaR wviVP6iuLxvDsFH2KxpbBETuMIeCgUwS74r6/3qgTanzWA8H0ZvCcbUOD16hwvsQh7fBWFGFwaIg N7p1KUqK2Vx6IVEFl4F75gqtDY+nntOeiYv5iJepAZvsH8Z7v8jt6NsBkbA1A8uZIFl7381gY5Vu TeMnmAjreUltakw6R8EPwXNjQasJet78alyMCQ0RR9YMCAMChL/7d9n4j8t86mBreMCawbUBJ1AW 8oh+IK73X+j/D/F/H/J/L/N/P/R/T/V/X/Z/b/d/f/h/j/l/n/p/r/t/v/x/z/1/3/5/7/8IAAIF A4JBYNB4RCYVC4ZDYdD4hEYlE4pFYtF4xGY1G45HY9H5BIZFI5JIR9BZPCRIkUiuIGNIIkYUuHqu BYQUiy4FOoHPBIjXq9Q8sYU9WaZgtKQANFko2DLoGuygERlAl2PmWUANJa5GKwjZ4AGGwXEwZXI2 Wy3rP4YPLUzYFSgAsoEuFwHluw4GMhkQ6vPCgy6/A7pAxJAz6wyDMAA4oKu67I1hKABYF2FsdAh4 JB9LQjAg9BLlBppdpvPLCAJ8sqCHsZCAijTMox9maYFkaFoGtwGPgiA6qu1gPl2fbjBN1AnFm9HB 2CzWDhcjGR9X2XkLFZOYAFwEWGZbxzYfaQHetVahJrIUy7dsTMALlhQtNGHvIFwL9w4EtOqy7A5S CMO7jvPAW7KoKYKCigqDpow/S4pOYLrkacUDAAHiCH0qzzPghsGJ2gjsQEhrPoGRqCROgkLIEqrj oGuUUu0EhlpkhJpue6KdBIfQoH1H0PtU7AAF2ZazOkiBGmCRoPAGghgvq16ELk7EVoGXB9CIMpdm HISER5Hx9QZCTrmGvUunq9aCFG1SCSaADkoExk3IKWiCJ5CrDLqgi9GDNCBOhDMew1BqMRrDoAQS wkAIMHwaOw8TSIK1MRIfEqBRTS6CyqmLRUNFMu0Mg5pycACgh9MEPlw67GSJI0/SRJTXStJ5bhoy aEvFI6C0Ghh61PH6ez3IaCVeg7UxAl9M2SpaDzrYLGlk7EUw+xlMMygSgoFH1CIupSU0SgVEnERp GkiIMXgAAcE0ggsgVXMs3BIEh6kwhgfNyUZcXBA8VGGKAoNDdEXkjRNE2OhVboPYqdqgGi9TnUqK X27iCCghTq4JMUi2ugdLIXEdJWEAa03lhdJLTe89WW+ZcBovLQL4IaCANjCnoE3Ui35c9l3Bjli1 5biJqwAADYs1QLSKC2ekarAy2QXZg4mhF3F28phzcWSfnohi1AtfKC10sQPN9IS5J0ZbdYMh5Yag sqC5M1OHxRiSCzghrBbQnkJLIg2AoZkE7ZEtOs64tJ6t1ambvm8uOl2vuZsDoeb3CcTMtSxmoyHf e/ABoGgokmTjJ3vdMILp02XDqSDyBD7zZMhKdEbNe3oVOeE0PvdkXHdkWRxfcOWegS9GGrC19KiG JkaXEt02he9ITziFXkYfPbisTVdehUTw/o27Y6g7jOrublMzUMhQTFqBg96cw8+ivQ+CgmOdPj3j oQ96Cda+7xoFr6CJReuQN2xoietqMaf8hzvyDMZBkk8sR/ABseIi1JfSUCFLOWQ/Z9RDnpsLVC8M +8EiDL7e2xVlRBYRAAdE5Jfii1QlhROqNisHX8PudALtSx4iyCNH0JF06xYNEGhrCeAMOBGgRExC kga4H/CyCgDR5RAz6vED6k0GRwhIqPcC6gyrnoUIhWEQWBgy4QHEItEF4UFzqg+QkzctMOyCPRIS 8BTkUoAgANiQpIiRWUr5SVE6IhiDgRXVvDlRLpXyhlH0B5XyJgItGYEQKIcNiIGpUguNcpA1ithI PJND6FojRIeyuF/JAhZCwKZEMvIPmjF9FgTlFyyEaQ7jRHgPoMhmjNS682D4AJQMeBoANLpCmOKI jCrg6q4GkMEXGQQIhDo6EDiy8uMkvnxuwSKWFVQ4jpSTIFE9mKt5ITGnIos+AfQiMLhEqGb0lCJO 8ncSJs00m+OAINLeXKmoFv/msaBV5Q5hurNqI2SBTxlsumiRZ0RDKElWVUweeJGZ2URopRVQhRIx JtjuxFUpQyGm0XHOMuw9aGkkgBRalFKaVUrJHKOllL6YUxIQlkHwrmoJ+S6kIfQZgzBcIYVMesXq ZVDqJUWoxA5XjLRKZ1MaFEULgCIBEHyTElFWjAqUmtPQWMXF3Ixej+5NEToQ7ckMxaj1nrRRQvxW CtHwKwqoYKcJMKhAA9GnK2CCVbVwQReoAKMV4IQxNgLLS8i7Owalox/UgQHMQgh+VabIWRkozIgZ W4lmPUS+J75BHbqJpcZQgYMCBCxSFPay6xIiK3X3YkrEbSoxwABONYdp7JW1tsVyyhziCvpAAqG2 VnSrE/p4QsOiGU4tQIFaYnZSimREW/bmLToydotP+FChdNlSW3u1dsjx+Ys2OIJbxUJo19rgXnTy nxCWPKDJgkQAFyjuB0J1E8wqHyUiNL9VZQ8pIuOoD6aGmpj7uYDwIRcIcr4cXZIGNMXa44ekEV06 V1U7bNkCRKYwrMoyXBBlOXO5ymcD2znnf1XgRBZNhtzgXFWKyHzjWPFkssmVFHIwgiwgmFMLWoWY QIWGGpTY/YpUhZQu5YX7dQMHGFVY7EGt5izJ2T7VxbmlHVP5BRRy4l0YUXYJAPC4uGQkIhWKvGgx 0Qc5KMYiLSReYCLeSAhllZBQnJuT86YFGCfmMz8be5UAAXAx44lAGEcPjjNafYN1hIQ7O0586SNX v4i6DECGOZxIPQHOul7t3etA/GeBH2PRyIHoq/R3FaW0z2AA/h1VrIBmdpXTGr9YVD1FbF2sddUq hY4keZ+sdea919r/YGwdhbD2JsXY2x9kbJ2VsvZmzdnbP2htHaW09qbV2ttfbG2dtbb25t3b239w bh3FuPcm5dzbn3RundW692bt3du/eG8d5bz3pvXe2998b531vvfm/d/b/qIQEAplbmRzdHJlYW0K ZW5kb2JqCjEwIDAgb2JqCjEyODAyCmVuZG9iagoxMSAwIG9iagpbIC9JbmRleGVkIC9EZXZpY2VS R0IgMjU1IDE0IDAgUiBdCmVuZG9iagoxMiAwIG9iago8PAovRmlsdGVyIFsgL0xaV0RlY29kZSBd Ci9XaWR0aCAxMDYKL0hlaWdodCA3NAovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25l bnQgOAovTGVuZ3RoIDEzIDAgUgo+PgpzdHJlYW0KgD/gUDgkFg0HhEJhULhkNh0PiERiUTikVi0X jEZjUbjkdj0fkEhkUjjz+fz9fD2e78fb8fsvfr8fkJfste8qmUufr+h86nb+mT9e74fT6lsnoE2e 9DfD4k1Pk8vg1PfknoNPitPfD5fMsfj5e77osun0wfskkkxs0tqtRl1IoNoi75fD7ejze7ydzxbL ZbawXC0azVbC1UKnZTFaTQZrXbrbbkDcryeLxez2arHZquT6wbzecjqdzwfctcjmdEJZrabGsbTM ZDaVCoY64WzLcjgdjTYjQVaoVi/Y7BoOXerkcjhenLYK3WbbcbeZjjbDKwbWWK3Yy9ZT7fL7gdFf TZb7iob5gbyebyWK5WrZYPbVrLXa3aTRZLcarSazJYRmFcVxXv+ZL9maex6nmgZ0tQaBlGIeB7Mq fJ5HUdBxmeVZZnCcBzoM1huFoYJjmsb5tmSZhnG2bxvmibJpn0pqBncdZ4F4WpoGMX5lmsaZtGea ZoHgeJ3HMbjPmsbptGqcq5IsebLGaY5tmWYpimUYBlEuTxNmSYxmlmTxRF8X5pFMVhWmIX5coGaR 1HKZjWmUaBqGqYpoHKc51NOdKUnwaxnmuhJfmQZJcFCVRgFoZZrmicZfl+Z5eFoZBnmSZRTE2Uxx HKcSnnmeh4mubRoK4fJsGCYp0HWchKmCV5qGycJjEoUJvmgbKkIGcxwHIVRXFtHxvIGdZ2nSa5tm odxynQb5snEZhmG2XBWmUWZWluWBVliWBWFqZZsGkYZlF4pZ6oGYRemIVZVFaZBumgVJml8XxkF6 bZimaYximigxznSdZlsIbBxG4WZdF6WpdlmUpZlEeR2nagcWHKaJnm2WRXFoU5MlQXpbFydB1HNi B3loWZgnadh4yciqYGCYhomnmRvGs8jHnWc5zlwVhZmaZJrHCch0G4bJqoGaBzm6S5dFqW5aFsXZ MFIbsjlsUxcmwZhrmAWxgGIZ5qNKmaBNabZ2HMdRsmUbBWE6YhmmgbxjmUaZ0HOdBVlOVhgmAXSc nrBBYlkWpcFyXpaFMVpxRMapxG1fJpl0TJVGYXRhqNsh/nIbRvlLxRkGnQSBHieZ4FWXZTmeZBil +WRml0WJmmwa5v3+cxfFyXhUFCUtZG0bZ0m+g1CmKYReFyaxuGiYpqGeV3dGCUZZGWY5nIMbpsRC XJgHi5ZqHAbhmecTZYkzVcPIEbpyHWWxdGWX5imMcJuG6YpgGCURZFgcc9m4NccRMGWkUH0PkfQx mwDXGyOMbg2BrDNGYMYdY7h1DJSsO0dw7ilj2HePEd41hooqHINweI9x6jrhQN8Zo0hzDlHS/8cA zmwDlWYORgA9B8D1HAOM5SCVQDyHqO8vQ6h5F0H2TBsY3ngDqHSOgcI5hzNoHMMYYwzBdi9fkMIY Y2xqjUHSPEdg1BxjiGyMcZYvhPiqHQOkdg9imwmHscs46eilj4gwO0ohYSWFggMd8so/RwDeHA4w b8QkhoIJ1G4fA6h2DnHkPId7gR5jsHoPAc47GIjhHKPopZBi9DwRYOMeo+B7jtHoO4cQ5xyjBGiL 0drdxyHQHOOYd4y2gDsHZBom474KDEGcMoaqSjKjwHYOkdw1xsDUHXLiAZDR1DtHgMUZA0ZkDjfu vsY4vhxq8Ga/Eb44Bti9F6L8XwxBeDCSuNQbw0kZy5GIJgUQ1xoDXGUoUZAxBly5HcQMao6hpi1F +LUZMMhRiwE4MAToqhUiUF2Occc+yBF3HqKQTwnxRigEuKRbo3RrjVGsfxn4zxlHxGAK8WYwBsjG E4MMXY0BhDGFcIMSQyBlDPfqNsgw1xvDiGuOQbI0RrDMRIMNNIqhpDJGpUEbo3hujmGCL0ZwqBWi rGCL4Wg+R6rnIEO+NgphSisGGMgYS3RSqsHEMMcI0h1j1HkOEaw2xxDNGoWqfg1C/irFuMEZw0hw p6GU9kSwuBNC4FOJ8Xwo6BDDGsKITwtxhC/UMLoXIwhhC1bhZUZguRjGLF2LYXgqXFC5GCMiZpDB 2DvHmLMW4xxZC5dY/EYAwBcU7HEL4YIv5AjeFwLiogr2eixFmLS3ZBh0DMGgPoeg9XVnxcuO605A xrDkGkKUVwpBZi1Fa3wUo7h3jweyOQrFER5j1FCJwTInBIiMFAK4VI5R1xsvfLMcY8JoLOG+M8bw zxUjQGDCAbQuBGicUaNUb6SyDDQGwNsTwuBODGGgMMUIuROB9FGHoYovkqi5weMgbAvqoCwaiNkZ oyh5DrHUQMe0QBciwF2LwXovBoDPGO48aYuxqC/bsN8U4lBSiyDwIlPxAxpjTL+KgWosBfDFGvAx 5o0ROi4E9Z8UwxhVC5GiMsbQkRICsGS0AXE5xWi2FILwYYtxfDSGRbsYgyRgjQt8LgW4vBdWlIXE kbxqDRDeOiNtJZex5tmWNJiCZyByvhG43gdJBh5jlHMV8fV8RwPKLEPsp451li1GMLoZgyRkXWFA NV/44jQkGK2PpdQvxon4scL1JI2ytykg2SpiI7RwjrHCK5cQ3zQjyHgPSDFzmcyeuTFEc9qB3jji cNwdDwVVjOGGNFnQ7klGhHaO9BA8yinoIEVEcI3q+6MQRVkeY8xtDmOgPEdbq0eixb+S0gY2RtDe xWLoWgvRgCzGIK8bo4DdS5HMNoboyhXi5G8Nk5GtTkjpmgPGGw4XtDVHPMu+mvR4uBHqPkyrLM6E JKCOIcMRLUOhGe94ejeBzDjHSOorw9TlkwU/WyRg5ioczWIh0dGd51o/i6NUcO0BzSzHWOMZIsHX i8GSXce5+zHvrm2Ocb43xsJvG5AUe/G+rERJgeInO2eXEm6v1YdY6B4C0FcMgbIzhtDRf+Oa99nh bCuGG9YZY1BIiDEjcAWgmBOCVNOOPfY2B0bVZzF8caTSBVpG0KwT4rxeuDl8NAXQ0RbCsFUKrewt RgDOF9R86QxhsivFL5kY41BVC4FjDWBSB4Tdf9Z631xFUoD2FoLAZI0hmjbFcLoX888Oo6F4MYYb RhtCSEEJITOPBACADwNIxIxBjCyGgNwb4nBPinG3FUgY7E8sjHM84Ygt6wi4GQLQZQznVrpFiL0V gzRYZWGUN8V4pxjDcGoN8wg1iYDZG6NMoY9vXv/wAQAiCinizCdiyioi1jSteGIB1B3hthshrh3h 0BzKdp1G8BOE0BxM9CBiZIjiXoCh8huBwpth0ByrxjLh6DKNeB8rkkEJOOLiboDCiinijB8iTCzw BQcwdQdiNwaDSrwweQgwhQhwiQiwjQjwkCFOXQDCZIMh5FVh3iuB9BxhyBywUsStRCUh6ihililw QCxB9CDNHCokYiiIDCJCcjLiVilCuwPwaiuCDQawuCcizCTwkw7wdh0BxQShwh0BqhoBtsYhsBgB kPopvhOBRhShrBqBoBiBThXFYhmhSMoBWBXBUBlrKB1hzBwiBnTB4hlBUBYhut9j6Bchnj/hxBwB vhbmohmNUhZj/lnBwEiBzBxEVhUBOhUhtmghXhUhcBmBphqBcBgHXLJI+iBhmhvhkhWLPqOhsBsh rEehxhrFqhkNiQ8RsPWB2h1h4t6BghrhplnonkjwRh0hyBMBVhWq9hnhsBhMEHlnlBnhXhXBVBdh VhUtup2CBIlBxBYhGBPBhrRhxpBkLB1hqqhBJhKBNhUBZBVBOhYhfhWhSBahdBcBRkaBxBus1jyh zrQBbBoIuhahghchThbhbv+liB5B0hqrpFGhnBZhQhPhfhmhaG7BsuKuNRsydLSmxhkhehkkiB2y DhrhmBmhmh1h3h1BXkyFYm5haBjBqhotOheBPBjBlBjpcB0ruh1iBm7h2p6EfBpBshZhdlUhkhth wu0hThYLVLbBOBXBfhcBauzPbBwhqhshbBOhWBuFeobDSDShgBhhfsqhdCtuqiBEXBkBVRHRVDoM ChkhshfhUhqBgBvhzNEydzMrSh6IhBzBvhwmxiEjSiiixCdihB8h7CYNdB0B7jviBiXwECWB9wVD lh8h2FVmihtqllfBdO0BwB1B7FQB7jlociVigidjwixCiQwiCw5TUQ6CXi6h7hwB3h1h7QzzNTsk nBnhhs3BQBTEOBzDls/htKghpBpEVm1hlBlKeBuDtBXBxh3hwjGjdOKuoyBowQODShuBnj9hpByJ yBnBRBQhRqqhjhPhVhfhVhdJpBkBgkGBxztUJUJsRBpHeBOBhBgBmBhndBUhThNhRrfSRBjBTBYB UhfnFBaBdBSBnhwRMBiBhy+BxhoIyGz0IttiTK3Bvhcn3hmBqhqhfhehclYhvhLhYBfhQhaBgBeh dhYOPKcUJ0oxsint/hvBghdhcBoBkULBKhTBnHqlmB0hthwBwhcBnqURRt4BoLUB2jHvAJnhoKOB tHhDvCjCWhvwRBthsBuh1h5h2h7kYpHh7GYwIQRhwhwhvkiB2QgUpVGwiCWB9BkSTBghdBgB3E9K jhqIoByhyKHCnnAh6CjB9I4h5QOruh2QCh+kYh8hZhLBYhhBbBm0Mu0BnBrCDQIMdFKBjhphuhXB ZhWUtBfRzUoVHViwgoCh8GrhPhahVBbS7BrhjGvHnBqkghpsTB1hXBYhTBaBfBWhCBDA1mBBnGnB YCVKtB/o+BPBCBLhchVBdBjlKhpq5DRkKtqhrqBmLBtBl04rfBYhnhlhgGCx9VjWCQcwwBuxoibh 8Ehh3PBBrhnBmhdhXBbk80yhThUBhBZBThHBQhBhkBwhrhbBcBiw1DwijUMhejkmangIUB10yBz0 9uPpvhoBcm4BlhuBUhNhbBghbBmBeBbhcNJ2C2hvXin2hUcCoCYToB+pPiUh7B4GICuh8h1B1B4C 4wBuaWsOZwCOXOVi8OM1GWiWxWx2yWy2zWz20W0iECnpcNejlicpMB2iWwPCzI625wCtHU6h9TYn NNSCwBwFmr3uVCWC1CkICh+TSNS3CuZ25icimh8NxpLIaQyiGKsh8HmBpB4DRiBwaXEWwiDiYQpW jQZiTDSzRh9w1Wr21CQtJmEhjBahaBZRdhqBWhWhShbBkBfkTDyq4BXBVlFkqzyououBVhkBmBZD shtBjhmRo2BiDB4B5h3hTBhBSoqBiFRhqBxBsDyhuhynEs2BfJuhehmhwBtBxI4h7DRB3BbnjO/B wBfBeBfhbhdBZhYqpj9hniGCmh9BiBWBgVOStB4h5Trh7BihuBi25oOo8Eh1VTmB/tQhbBahhEXh qhbnB3thvBeLYhls1hOhNhVkTPDXViQDvB9heBXhhhThTBbSrhgBNhNhGhMBUhWhahXhaBnhpBno EUrhehbneBPln0XRalXhjBbg+BFhymhD1B4oBCChsh1BsIvh1MIhVBRBbhTFChphRhIhbhkMzhyq mnaBtB34yGbBphSLshqFxs0hihNBNBWsuhhhphnK9V9TgB4XOCTQNBphkhhhmhlhpBsF9hlpHh5h khwhkTWh7DuBbBiBbBbB8YBCByBh0MXhlhmBghmhnyisyNUE6xGBpBgItOWTD4RiPivBlEyhohpN DvtDUByBjlcKmhzFZBuBS40BYhbBWyQFSJkhUBohmhVyKBqBizuIqEbhUo3iDB0h7Bzh4B8B5BqE LhshzhuH/huhpEpvZhkMyhlhnZvvKhRMrvaqPByt4h4lOSohuhbsjnGBthphvBoh6pOY8h/QJs9F OkjhxMLhjIxhxhLBbBIBwB0hxhUhe0CBYhOIc1ztOBqBVhSheBrBrhuBahahVhtjIBYhgBjBvhpB qByy+XP562tvXCzCXQeXLBfheBnBrhrhwith8u/OpijVU391RCYOKh4BzB4B1B6CVImB2Cmo3I4i no+CYCiCtjvCdCyCY6mKmByhjBgBoWGh3hshuBtIMh1s9BxWoB5qHGSJHoaBwh4khtkBwI3ITtZz LiUuShxhvlTZJm8BJhWBJSoBlI2Rah1Bw6dB0uJilh8hxOUNkU+q2TR07CwB8B2IbCciEobB0Ffh apIEFCCruB3i2CDGIh4BmV/wth6CGGhByjzo+zWuMDRB2OUQeELB3hSBSBfBahbKYBdhdBVhWBME VqdIXBlhjBnBYhVtcM0BfMWhmhohjDEL2ykBfTu4BB4BbBXhNa3Bs6GoMHTlshchpBaBkhjhhhiB kBeDxCBmPhllryRheBihChLBIBdmugyg8g4hXszVmP0sX37PaRgBkhsBhuxB0BGBNBOhQg9hFBnh iBgBJhCg34kxOCBIdhyhGhPBEBj4DhXhWhRBIBShFBYg/hFhWBIhToIBtBWhThfOBnjWALTsTiBB 2JnhUBLBTMhhqBZhZhXE+MUCwBjm1nAh7hfhiPNxGtNsEKgWjh/jHhwhfhgq9NNhfhKBRht5WBZB ZhkkHBsMEBrIJh2hUhYBRy9BYh0q+h1BvYRQcoPB5QHnHkShXsvhVBYhQj2hZk7hsXahYhKBDBFZ vhg6rhrTLhx1YxfuChS80klBu85A3hmmu6KhiJvhyFYhuhmBuBkhGBChBUPBNiyCBj/G1hiBphXB ZBgAug5A7m6BjhNhQhN5gBqh3DTqPBrXkBZBlIILRBdnahq6NBgBcswjHhsyHBFJX4RFih3BolSB rBzhpBYhWBSBMBThGhhhOBRBiBZBgjYBqhZhUBfBQMjBIhRBNB2z8iBTUB8KiBcsVhghUlthosE5 JoMhPBchZIXB1m6BnBshoILBdhihduBzh1zmqhvBfSTBi1KBQgzg9GrhfBEhBBUWchahehjMOBuB thVhXhRhJBPBQOwoMPAweWkwELu4BD1jRpTOWImh1n/htj1B4CuB8CYNeteibh1Jlqsh7BtBrhnp Ghyyo4xjRoDB97OhThQBShVhRBPh9XECBojNJtqh5BmqPOLabzYQbiXzRiXzZW6Cci2WjCxQgQCQ biTq2RPB3TZam39peB5BxuIkkhuW5563oi9B2B4BpEg4BSc1AB9NLJdIch5LkjKe0pKh4i6B8CBu Mv6BrwrhxBnBqB2tLRoQqBxB0q7JNB0h04loOh4aSZTCLNJ8g/KfMfM/NfN/OCJCfif/O3QCY3P2 uQcCGi36RWtCdJmichjyrRWBjnwhyTjidmx+riTYyB3DjD1h3h2B6xtvYo3+74BTgkE2oWlCZWtw gXEC2B+CiB+B0e1rxh6y7htpqTPhxB2I4Bqp1k9Bzo4JIB3wgB9HAhzU9oNhxv9eQZ6h4B6jLCm6 TCfCvWjI//aiXHTEoXNBqZsNZhrj+CAO92Ot/wV9vp9vN3vJ7vV6PJ3u1/P1+vl7vZ3xlktFfuF1 uCCyF/u10O5yN9zu13vNyuV1xR+yF+Px9tBrt+YONyOJtuVtTCQvd+PllOhvvl8vp6Ot2v19vuRV GpVOqSF/VdutpwshhNRgrplrNgsVeMhiolHpqVQSCvB6u9XrlVMJgL1frRYI9koxFrxaLplMxhp5 Uq5UKlcKFSpJGpZpNNsKxZrhsNxsuZ0ux0OR2yFyuFztVpNplNNxRttN5xuI9otFIlJJ9XKleMtd Ls6o80KBVKBaqpaKRIo2HPKQvRzOhbpFONtttZkrhbL5jMaQvZ8vZGrBNKVaLZmsRhspaKhmL1kK 9SLZsNFurBcMlis1qNtuOxuuF2rdVr9eFUUxYF0VRfGEX47DOOJflkVaQnOdB2FiR5QHIaJpmAWZ Um6aBnmYYhekCQpFFYWpSmUbJoH4ijPG2chrGYbZpGqcZbFkYp8HsfCQqQe5dmCYCLnwVJPk0RpW EMe58HukJ5H0eZXm8ZZmGiaxfkwUh1G2cKqy5LqpHcdh5G4a5yG0Zznm2bRTlqVI9kcR5yHOcSQn iex4FaXhUGEYRemAV5ZlMYhKGYcZtGebxsGcU5Xl0XJdloVRRlIUZRmwaxpG6a5rmMY5mkcURcmc ZhtM8cR0FkVJaz4aBelyX5kGeZpWluWpYl2XpyHIcJwGkaxal+U5mmwZZfF0XxREgRp7IekJ9nue 5klOWBnGeaBkF2XZpsfOh6HgSxYlQUxemMaZlmKc5omlYhlmuaRuLIZZaV+UZalwU5dF6bBwHOcJ y3QY8MGEU5rm6axXlWV2CmskJ5nkexdFGW5sF+YRsmsaZvGeahjT2ThOk2ZZomUYNYn3FSQnGZBn GOWJhHQdB4RqY54nYd6QnciLgFcc51niZ5imEWBjlPkyoIKc57HMUBrlqZhvG0dBwHCeBwHHL2ry 6dJynMaT6IEeB5bAdx4ncb1/Kfox/nMdZxGychqn1uKLSTHB8H4fTsHweJwnGoZ9SUfB5noejioe eZwHKdJOleYZwnEcyLHyiZ/JomeTHqersbimCZxUfsVJmqSDn3HB7quf0dySb5hmQeh3nifCk5Mm KC9Oe589ip56HieJ7nieR6+BJR8nmeJ6HLOJ1ncdzQHKevb8yfCD7+i2iyT0yrqsq50X6eh2ncfH wxwex2ZweCM2f4KFIof3cHzz+79imZ+2fyR+9QqPM+wifQoL747nTlSdA/B+DWIDEiJgL9PAuhYi 5HANccY6hxDqHQOlU4vhhk2G6LgVwwxvjaMqOMbBUh9D9H0KsbIwBTi9GCKsPgkBbicFYMcZwzhL inLqLxDAthdDEGKMwWwwBojsHOOobgyxpudGALRV4xhmFcGlBQdB+RtPKHTEUdg3xsjiG4NoaYuT yDmHMOUaA1RsOZHqSEbY2BvC2QmOYbg4BYi2F2LMYDGxiDAV2nMqLGxpDGFaLUZqJBiCvF4O0dg8 RuDWb4ZsWwwxeC4GCLsQAjhMDMGMMoTInA/iqF2KUP4hw9jZG0NoX41hcDLHONlHwxR0GqF4LwXS 6Rni3GOMIrgvxzDgG+mMaY3RvDkF2KcXA1xfjBF+JkUg4xrkgIKPZZaSR7FMHUL08Q93CDLki2Qd kPDpjDSA+GA840vEwGMLwZw4BujfGUidlY1BsjeG9D8ZophYiuEGHoTIvRTiqF6McWQ+ynEhIQPo ZrFlqDTEoHkS4shOCxFkK0XQchAJrFwMcXAtRcjPGSNIW4uxnDamaMMXYt2aDtE4IESQmS0i1FgM EbQ1hqjMGgMk/I2xfjFpyLVTovhdxIGPLEWoeRCCQNSN8kMpRwHRZm+UYAtxhisnQMsaQ0WcM2Ki OMbo5x2OJF0HwRYow/CRGCL4aAnBNC0GaNIaQyBpDPF8MQX4hRJCRGGL8YgkxIh2E6K4TBfBAjRo 4NAalPhwDWqkLEZYuy9iJEmKkUQrUZjaGFWUZKUhcizF4NAbI2xaisFuNMYYvYRDWhElsgo4idi9 kgLgX4thUizFmOwdI6RimFHKN4bgwGADMVi98zs5LhJcHknV+ZKiFDuHkPNzLwB7JxHKNQaw3R1t beUOh+7tB/uVG2N8cBCx4jrHMO0edyhvDZHAKEVgwxzjneWOsdY9B5j2XcORrY6hqjUGgRceo3hq DaHGOAcSllEDOI4MYYKsBjsakwMMaQ7x1DqHgPRso3hrinFWLMdDyjrpJf0UgfMvbv3LYcPMqrcW ij8HWNcbdh7umjGgMoa7vLlj1Hm7Ee8RR0D2WeOsdQ5sSW1HO4Nhw9R4DrWWNAbA2Bki+SoNdqA4 xzlJH0O+q48B4wUHW3TLSOB6kHKSUkkI8EwDNGeMaqlbV0jwfONoZAx8LDUHcPMdpxSkI6uHnkkL 8B1DjHQPHLA7XEjteUNIa41GNDPGsNcaoyRrDHH0TQ680BzE7gkOQVArRTDcvEUF2IzUqJgHkOEc g724j6wiO4c46YAFXdASshbhHljvKMOW+Q8hyRiHi4IYgxxiOVHU8gao1xmEZIGZp4I8RhjTGRkg eGkx7DQGYMskI2ItSLGhrkdQ78J4gbk3NyuRkmo5VyVm3TnirEUfG/AdcFhnDUGq3Rzro26todwP glw7hqDcG7NAe41xvDhJhjwfBMB5jrHYPopBJNtjr1NwrEEAc9cTnHeUdYoQ+iOFiKsWkLRcjCFq MNRoqxWC9FeIMRgjxBCSDhnWrA/zIDQFmLEUwzxfjAGALAV7hI0kFHkPIegpxWC2pEN4UIrRjDFG CMIRYiRPh4EOKceo+B9D3b+MIZItxhRMmQL8XAphZDMGUMcWotxXjgHMOdlcUSM0ZFiMQWosiYEU H5KsbQeBFh5GOOFhZBXBj2F+MMYxDh8CPE+KQTIiQ+iuFOLeH43RQiqFyK4WwpxRiQEAMPxoqxKi WGKKoXQ0xmjCo+LZHOeB/kCHcJ8QofPRDJXqK42YohljKY0NIbAtBWjAEaG0SowxgjOFyrYY4yxt WgF/BQdQtxlQ1GyOURIlxRpxHGNYXwuR34+FwKwVovRdDFFyLIVApxaCv6oPrin6WsENHkLkT4ox hC4GJIUwAvxljpHMN/Vg5hnVv2mF6HyKGqSJ4Fi5oaiHAwo2eKifmGChoGio6Msim0MF2FkF8FUc YKSc8H6akGwG0GiGyGuGmGmF2FGFcHCmAHaHSHIZqHUFQFWFWG+G+HGGCo+GgGIGCKlASFyGAF4H GwgJCHYTCGAGEGUeKHoGOGmYuGeGQRcG812HwDMD+E8E0FEE0FUE8EWF+FWQYE0EyF0EwFQHUX4F rAoHgYaJCG8MwE4ESEQGcGQGAkk/kL8GUF8GKqq5kFgGAEsD0E+GoGoHAHS4aHaHoFkF6GKGw9wF UFaFwF6VGDsEWE6GvBA5yFGHAGwGyHOHGG+xaHKE6EeEOEoE6EmZMH4gMdOKeH44k/US7FObicqd GbQfgbCHkzuHqd+6qHuuWHgduHxDMHkc6uKSabiuKHiemc6cqJ2gqw2bQxRFUKkfYemImfuKuuyt UHDGObQIOIWHm7SHSgKnGzCevGkHyZMFOFmQ+F2F+IiHUWWHmfOHeW6SaKQbIHac6JhFIIEHadw6 sIQJoIO6odGHAGyHCwsG6HIw2SSckKudkfm1OHOHKHiGYacHYHUHcYAGUIaHsd+HnFQGgGOtGFuF wIQoEIoHsbCR4Kk2CHUFmFcF0fO12bAIud8cFFJFXDQG2G6E6EUE8GeGeGWFMFsFvIkGQEIDmD+F yF0VqE+E6GEFaFo5KFWGIG4a6G4MgkYD2DmEM/AF4EkD4EYGuZUKlKSGAF2F8GAHc7SGMFYFygkH QZukSGW+KHCG2HESoGaGcGsNSvyGqQsVaF+GqGUGgGhBEE0FcEYGAGsGc5IFkHw5+YYIWGIFyGG0 RLAwM+oVuF84CHIR2ekFgFOkwF4GaFyFeGMFSFI6EE2FUGApIGUtGEsDuDuF4FmF2UcFyHigs24H SHHIoEiFEFqZChGKiGGFgYoo+F0kyFlKCzMGYEqEiE6ceHKJCi4HcE8EnEaGGGiGoGkHCH2KSGMF wOqXSFssynkGsFuXwFyRqFSEMEMGST4KkGwOmFcE6FgHMHEHSRKjoFWFuFM6G1IHPJsIKXMGGD8D YEAE0E6EuDaD8D8I2GYE+ESEWPEF6HEHAG2GYh6FitejuGWFkGQGCGyl+EiEME2GSmOEwD8EmGlA aKkUyG+Fqh4hAG0GGFUFwG+GsG8JCG6GxJWjm/CF8EQEmETRSFEGOGQF8GyGwGoFkvWF0kCXwGEE aFGEKGcHGGqFgFsFwHcyk2qGSGuDwCyDkFOEUE+GOGLDoWuFKFMFVEuasKiGqGaaQHqHyFME0F+E oEWEoEQD8EeEyE+E42mGIFWEcEYGmGCGGHQ0qHSpE68FgGaG6G2D6EwTWGKGOKkHAGqG8F6RIGOk yGpSUFkF0FoEGD+EQjNOCH+e4HaFGEsGCOkGSFYFGGIHQHKHQFgFAFiGKGIFuiEs2GuGSFAE+FEF S/GFSEWEgtGF6S+G2G8HaX6HaHaHiFsFLMkqgHObM3RQC5+HiHAjiGeGiGcESEwTgwifU1O3mKSc ye8bAG2HGHGdiSceAdHBSHYcw56JEc638IsHwHM2smifYbIHuIGHeHKHEHOzMGaGYGqG00IHSJpX iHzFsdc24z8HCoKcIHsKAIKHcHQHeGSF0GQHCGoG6eKcO0qGIGMGQzIxMKiIPFSKu/wHgHKHGHKH ANUZeHSdHHav4ctH/ZqG8/PIMHOwnZZXwJnXsIceeRwdeHet0G+fCHyz2RUvkWedueKHsIcHspiP ugow8fOHcG+G8HEWeRwcEblGeJnGkdOeCHqeoKdFLQCJC0IwggqHIG7ZoNW4VMakQmwIwIzaxFsz ZY0H+JgreGuQ6GCUyPzbuuWHoHS4Qx4d8ywHmHuHmHE0WHTEAF+F3R4HWHkG2GuHCIdaLbjdLdNd PdOdPGddRJsGWGcGuFwo+GWGAGQFMFKFEGSPEEmDuD0FyFKFqFWFaFmFQUoEcEQEMfKHYJlO8LjB uFvIKYKnkHGHMPoGwFKF0FQEeEKEiGWGwGateFeGiF2GaFOE8GQGGGGGsEOEIE+vyPdEkendZflf nfpfrfsJDIOHYFuFuFyGsGgGaVyG+rWGWFEEqE+GWF+GUIGHbBu80E8EwIzAUH+cmHAG0G+Gw0OG cGIGiGJOOGg3e8aF6FaGKFcE4E4FEHAHIHAkQJKG+HKF8FoGmieGuFeFcGAG+ccpqGOfdfvh7h9h /iAaufYfEctGOJpawHtFiIobQv5dWauxAHomhHIbwWfidiDivixizi1i3i5i7i9i/jBjDjFjHjJj K4mfmvgd4uYu6alE1XcHEGMQsvEZgJWeMSWIKvmHkF8GoGKGKG0G4QgHcHaywGw2YGqGKGQOy9Qt qHIGEGkF8wCHAPGkOtpBsGiGqGcG9U6GmzIHkdib1HcG8l64IJkRUHCHCG/WgHUcwHodvYyIoKQb xcjaxisIMIOvkHmcqcCHpH9lKH7LwGy2GGyrakyGbZDlQHKG4G+dGz2IplYKSHww20EPyGS7Eg+G lGoqS4C9sGOq4HYHgkRA+GWG617e8HArKGiG4mCGC+avsHEbIHVIoHIGpmqwsGscEHiHQ1XbJaZl rfmc+H6ZUG6+aG0E2FM/GFUE+7KFcFKOkQMZYFSFtbEHMR2b+GCGwGKGgHEG67KpyFVJCFQEoGuG U1+IQJCrYGgEqFeEfCSrgGEFmHW35C+FUGUGAGmF7kcVgG2++GMpyGCMmFscQLYH+TAHoFKFGFWF 2F0FmRqFYGQtEGnE2gZNGvUFsFeFCOKKqa2HEFYUnlEG4FuE6E8HBnSJDaUFOFtBoF/AsFGFASmG UGXdysWGBh4IKtoHKFoPKGqHAGoFyGIGSGMFLPmEoE25AFRl6ILQ0GKFQFvhHTgV4GyFIFqE2F+E 6FEF0E8UcFiGYa6GwEuFIFgFoF8QYN6F8GOFuGaGaGWGGFeFpSMGGzMNLsAGEGKF0cJdJh+GqG4H MGEnQFehYGQxiGTg0FAFmFYGSQ4zeGOmAG2KkG4HcG0HUHoHUGCMEGyFqF6FwUpI8F84hpOyWE2F yEw4AGqF6FiFgHYV0GEE4FSF8vWFksUiQG4FcF2F4Fk8DtAFOGeGqGfrMvmFgOAWxLY2GHsZwFqh /TqFKFakqFaFGFMHie+HkbGKlk+t8/vY4FiFIE/kkGUoIIQtcGVKAFuNkFQGKGWGIHaTiHbS4Kib YG2GSFaFCHnxmGAGYXajoFvCoGOF+F1cGwSGaE8FYFNhGFZp7V2GaFtAO6y9gFMGQ2IG2FGFYsYZ EGM9GFqGCh0GGSkU6LwFvYLuoFnRgFmEyHZuniwx4HzWgHhIOHa1OfKHUYJYYvgM/N23adGfcHRG 4HYHuHaIYHmHyuWYLdAGeGVH3bWcwHjFsKYHTdAGsvkHgHGGgGsHIG8HTD9ZoHRzUTEykF2GEF8Z etQH+b+H0MEoPmDaaHFMaHmGqG+iMumGyFuF+G0sIGtr+GogyKkHIuqFQFiFPZoHKFqFqFbeoGie 0H81JBUQeG1QqGyG6GzI1coeBBzniHkMwfZ0kG0GSsuHse+d4HdcHmkGyu8HAaiHEHEG/F2HgdOu qHcGsGaamznxmwoysmgLebDo2HCbCd4IzFQHIHSZoHrHYH3XviAGmGhReFsnOGGGcE4NmxYlQWKG pA+FhyDmMGXE0HP0IGgFwGEVSHCGBWyH+GSrcGSF4FrMq/yG+IVeUIKHQwieKHkwCG8GIFKFYGkG UGoHUKZIeHYGJv3INE0akGtkKwhnAHU0Ix9VqHGcmdOfYcmfhGobnG+gRlg4VHuIPGlbjdUezjN6 6JDQ+GoFOFII7hSGcW1O0HCE7qR5xRuGmGo4QHY0WGvV0tGF4FWFeG2FUhKbTkKX0MtKa8m0yur1 CF4Z+FWFSqlvsX0GwGCGIGZNMFkFkFhtpdeF5ZSFSFj7tSYGWFwGKGSFsF+HP38jX1D699N9OS9c MFMFFB6HHUW1ImCHZy0GiJue4HCGviiHmXrs3dzI+F4GIG+F9FTbgH+NEGzt6F4G/9oHCG0G6wgH UJCGgHDmAGmGTCWFuFkFN8+F9BEGrtEGcGEGGGfr9hIFsFskiFbUWGyHbmUHjHho3Ld9R/l/mKi4 UH25/lfbfHtiNGn63/8IA/oFAn/BYNA4G/H2/H6/IZDIM9Hw831FXs9nu9Hm8nw9Xs+Iw8Hm93E5 HU73i83m9Xk93s9H1GH293y/ZtCn5Bp1O55PZ9P6BQaFQ6JRaNR6RSaVS6ZTadT6hUalU6pVatV6 xWa1W65Xa9X7BYbFY7JZbNZ7RabVa7Zbbdb7hcaXAQplbmRzdHJlYW0KZW5kb2JqCjEzIDAgb2Jq CjEwOTQ1CmVuZG9iagoxNCAwIG9iago8PAovTGVuZ3RoIDE1IDAgUgo+PgpzdHJlYW0K////F5je xWvWZCBU+kIAE5vyk1uKsGCMvkI8OToDWsSr+NtE1qGvrQbPAQASAhSu9KgJflhpChesR1HmSquq 9qOGOnoo6ScuuSkuzCtDeh/rg55D7ahbmfCsgDpYKzD8sWp22VSeCA3HNtrzelQSZdiwqcZZBF9J seCECQu0BrwffZZ0G5+B49Vc1k+w6bWJmV9P82OvPRWPwR+adiVXlqLuCr6NjKFj6HizmWFoIvvH ce4rICxBr+1gSWSGofopjwTnHJCJf3kCMhJjmzRfY6VOjsZ60HZoMb/Mt2HG4fDKyQxbUozVVb/n uVobGL3BZ0yI4Rz+SU2+FgUf3OYPp68cAwKo2FdovxDC2ymAnJDNJXHqI7s44dE9Aa4kEFXULVnX 1jEuPvE/AcxogWn5T45rObImcZP4r5Wn1Kb9qNNWf6mHruh47ulFV2quULo8u/Pu4mWC2xUYgum+ f5KR1RI7XcAj1a8NGgZ3yVYyBhIl9PSLd8+gj1KJTtEb36cuGwTuP9qdTPWkxL769sQMHLkBpzHQ R8Ei0Q/07e+bGwqfCUl6p5ZvS1ouRlDyU2ysVBPeJVufSCyuPBme2DSoeD7y8uaIYjLikHgzg8yg LyCzDUYPrY47XMtV+qOJoxvIlQ6uHnDgAQBZNIMl1LNGiMGMl28b08vnKMaKsmmmev+1KB0lCB4m YlOqiChdzrEfW0iOdxxaXkQg6faJkHCIRZmmaqLFkQQYO4xBmFvyuLc7Ry5XoY2cwXaSSwYD1Eyd erc/QEhEWYPQmhwsjNTjyBsSH72fu38WTsodUp9p7xogLlppcrPsQ04IcNvdU6P5ZsK2Bn42HM0B OR+gow66xD0VLbDIGfQWImTx/7iV+R9XryXW5UGj5nvChx/RQuMPVxDAHyq0Nk0ZKEzSvUXxFfUW 7NtYj8LTUkryJIzWNOPn9AMRqTlew2KrliDxhzbnniPC9rOFygbPvSpbk18+elRCjP5768Hellf/ iN82b31ZMnQMuD4Sh/w944+cIgrwCmVuZHN0cmVhbQplbmRvYmoKMTUgMCBvYmoKNzY4CmVuZG9i agp4cmVmCjAgMTYKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDAwMDEwIDAwMDAwIG4gCjAwMDAw MDAxODUgMDAwMDAgbiAKMDAwMDAwMDIzNCAwMDAwMCBuIAowMDAwMDAwMjkzIDAwMDAwIG4gCjAw MDAwMDA0OTcgMDAwMDAgbiAKMDAwMDAwMDU4MCAwMDAwMCBuIAowMDAwMDAwNTk4IDAwMDAwIG4g CjAwMDAwMDA2MzYgMDAwMDAgbiAKMDAwMDAwMDc0NCAwMDAwMCBuIAowMDAwMDEzNzI3IDAwMDAw IG4gCjAwMDAwMTM3NDkgMDAwMDAgbiAKMDAwMDAxMzgwMCAwMDAwMCBuIAowMDAwMDI0ODg0IDAw MDAwIG4gCjAwMDAwMjQ5MDYgMDAwMDAgbiAKMDAwMDAyNTcyOSAwMDAwMCBuIAp0cmFpbGVyCjw8 Ci9TaXplIDE2Ci9JbmZvIDEgMCBSCi9Sb290IDIgMCBSCj4+CnN0YXJ0eHJlZgoyNTc0OQolJUVP Rgo= --------------010304070706030804050703-- From xbd@liberty-resources.org Sun Jul 08 11:18:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7YX3-00087x-RZ for nfsv4-archive@lists.ietf.org; Sun, 08 Jul 2007 11:18:41 -0400 Received: from p548551f4.dip.t-dialin.net ([84.133.81.244]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I7YWz-0006pT-4x for nfsv4-archive@lists.ietf.org; Sun, 08 Jul 2007 11:18:41 -0400 Received: (qmail 6297 invoked from network); Sun, 8 Jul 2007 17:20:36 +0200 Received: from unknown (HELO try) (230.80.175.137) by p548551F4.dip.t-dialin.net with SMTP; Sun, 8 Jul 2007 17:20:36 +0200 Message-ID: <469100C4.8020106@liberty-resources.org> Date: Sun, 8 Jul 2007 17:20:36 +0200 From: Will Leach User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: Das ist die kriminalistische Teamentwicklung. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be VPSN WILL MOVE LIKE A COMET AND ITS ONLY GOING TO GET BETTER! Watch this SUPERNOVA closely MONDAY! VISION AIRSHIPS INC Symbol: VPSN Price: $0.021 BANGKOK, THAILAND, July 2007 Advertising Agencies Ready to Ink Deals! The company wishes to announce that it is in final negotiations for representation with some of the world's largest advertising agencies to market and reserve the blimps for there clients. VPSN THE RISING STAR, IS SET FOR SUPERNOVA STATUS ON MONDAY! "Mitarbeiter managen ihr Wissen. A big reason is the rampant competition on the Internet. Das ist die kriminalistische Teamentwicklung. Dossier Wissensmanagement: Warum es immer noch wichtig ist Wissen ist der entscheidende Rohstoff in allen Unternehmen. Den Kollegen fragen, in der Kaffee-Runde diskutieren oder einen Workshop mit Experten organisieren - die direkte Kommunikation ist nach wie vor besonders wichtig. Die Autorinnen regen an, immer wieder den Perspektivwechsel zu wagen. Ein weiterer Vorteil bei der Entwicklung von Innovationen: Das Feedback der Kunden und die Kooperation mit externen Unternehmen. Zum Abschluss seines Buches, fasst Fournier die wichtigsten Regeln in einem Frage- und Antwort-Spiel noch einmal zusammen. This means that you can theoretically run Rails apps on a JVM. Aus diesem Grund spielen das Informationsmanagement und das Wissensmanagement eine besonders wichtige Rolle. Maybe even more importantly, how does this affect entrepreneurs and other drivers of the technical economy? Ofcourse, Blackberry devices support secure access to Domino data, and Domino with Blackberry is one of the hottest emerging niches. So, how does this affect the average corporate developer? Die Autorinnen regen an, immer wieder den Perspektivwechsel zu wagen. Anything above that will get cropped off of the image. , he clearly explains what these two terms mean in relation to the IT industry. This report includes an analysis of the latest chip based loyalty schemes and concludes with a "Key Learning" section. Dabei ist durchaus sehr wichtig, dass der Manager freundlich ist. The presentation starts with a question that summarizes how most people view the IT Outsourcing trend to India . Aus diesem Grund handelt dieses Buch des Unternehmensberaters Ferdinand F. This journal is finnished. We see more international names, recruitment ads that shows a distinct increase in the offshoring activity. In Deutschland hat Allianz bereits einen wichtigen Meilenstein auf dem Weg zu einem erfolgreichen Markenimage beschritten. Read this article if you are considering going out on your own as an independent contractor. Hinter der dreisten Methode, Original- und Markenware zu kopieren und zu Schleuderpreisen zu verkaufen, steckt System. This rebellion, which Turner believed was directed by God, is one of the most famous slave insurrections in U. Ofcourse, Blackberry devices support secure access to Domino data, and Domino with Blackberry is one of the hottest emerging niches. The creation of blues music marked a new era for black music. Dossier Wissensmanagement: Warum es immer noch wichtig ist Wissen ist der entscheidende Rohstoff in allen Unternehmen. i'm sick of people prying. "Wissen ist kein Selbstzweck. Das Wissen entsteht im Kontext des Vorwissens und der Erfahrungen, die der Mensch mitbringt, der Situation in der er handelt und im Austausch mit anderen Menschen. Hintergrund Innovation der Innovation: Vom richtigen Umgang mit dem Neuen Der Begriff der Innovation ist derzeit in Mode. We have always known it in running our Lotus Notes Outsourcing business, and it is good to see the trade media recognizing it. Access Error Headline functionality has been disabled from your intranet. Der Kriminologe, Bestseller-Autor und TOP-Trainer bei der Deutschen Experten-Akademie Prof. This is, again, to compensate for the fact that person may be a Hibernate proxy. ID MSN Jabber Username: Create an Account Forgot your login? i'm sick of people prying. Die Antwort lautet: Vernetzung. Zum Abschluss seines Buches, fasst Fournier die wichtigsten Regeln in einem Frage- und Antwort-Spiel noch einmal zusammen. Und Innovation basiert auf Netzwerken. But the problems are typically what is outside the purview of Domino Administrator. From nfsv4-bounces@ietf.org Sun Jul 08 21:18:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7htF-0007xo-Rc; Sun, 08 Jul 2007 21:18:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7htE-0007xj-Au for nfsv4@ietf.org; Sun, 08 Jul 2007 21:18:12 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7htE-0008Ot-0M for nfsv4@ietf.org; Sun, 08 Jul 2007 21:18:12 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l691HV78022949; Sun, 8 Jul 2007 21:17:31 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l691FASr021889; Sun, 8 Jul 2007 21:17:29 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Jul 2007 21:16:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Jul 2007 21:16:57 -0400 Message-ID: In-Reply-To: <4162.47852.qm@web31810.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: layout stateids and pNFS callbacks Thread-Index: Ace40q6yvAGIiatySESrJrqHjMGLTgI86Rlg References: <46827329.1000508@panasas.com> <4162.47852.qm@web31810.mail.mud.yahoo.com> To: , X-OriginalArrivalTime: 09 Jul 2007 01:16:58.0616 (UTC) FILETIME=[D8AB9F80:01C7C1C6] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [nfsv4] layout stateids and pNFS callbacks X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org > > > LAYOUTGET will take a normal share reservation stateid > > > (as returned by OPEN) or a delegation stateid as > > > an additional argument. If successful, it will return > > > a layout stateid. For a given file/layout type pair, > > > the same layout stateid is always returned by LAYOUTGET, > > > except when there is a server restart. > >=20 > > Hmm, I thought we're going in a direction where the > > seqid part of the stateid is incremented by the server > > to enforce strict ordering of LAYOUTGETs and LAYOUTRETURNs. >=20 > I don't recall such a discussion, but that seems like a reasonable > thing to do; consider my proposal as so amended. As part of doing this, can we use stateids instead of sessions to sort out pNFS race conditions? This approach requires the server to pass the stateid in callbacks so the client can order the callback wrt the sequence being tracked by the seqid part. FWIW, our existing system (MPFS) does this, so we have lots of experience with the details that have to be gotten right. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 09 01:06:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7lSV-0005h8-D1; Mon, 09 Jul 2007 01:06:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7lSU-0005Z4-3o for nfsv4@ietf.org; Mon, 09 Jul 2007 01:06:50 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7lSF-0004Mh-Rl for nfsv4@ietf.org; Mon, 09 Jul 2007 01:06:50 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l69561dK009119; Mon, 9 Jul 2007 01:06:01 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 9 Jul 2007 01:06:01 -0400 Received: from [192.168.0.140] ([172.17.28.134]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 01:06:01 -0400 Message-ID: <4691C237.6020808@panasas.com> Date: Mon, 09 Jul 2007 08:05:59 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: "William A. (Andy) Adamson" References: <89c397150707031130n35351248re5d8b7a10571ad16@mail.gmail.com> <89c397150707051002k4a7f4cd8te738d6e90144767a@mail.gmail.com> In-Reply-To: <89c397150707051002k4a7f4cd8te738d6e90144767a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2007 05:06:01.0287 (UTC) FILETIME=[D7F0CD70:01C7C1E6] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nfsv4 , NFSv4 , William Brown Subject: [nfsv4] Re: Fall 2007 NFSv4.1 CITI sponsored Bakeathon date query X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Yay :) Benny William A. (Andy) Adamson wrote: > We had a reported conflict with the proposed first week in October. Will the > third week in October work? > > CITI NFSv4.1 bakeathon proposed date > October, Monday 10/15/07 through Friday 10/19/07 > > Comments please! (Yay or Nay...) > > -->Andy > > > On 7/3/07, William A. (Andy) Adamson wrote: >> We had a successful bakeathon in Austin - thanks to Sun for sponsoring! >> >> CITI will once again host a fall bakeathon, for NFSv4.1 implementations. >> >> We propose the first week of October - Monday 10/01/07 through Friday >> 10/5/07. >> Is this an agreeable week? >> >> -->Andy >> >> On 7/3/07, William Brown < wilbrown@us.ibm.com> wrote: >>> Hope things are going well in Michigan. We're really tire of hte rain in >>> Texas... >>> >>> When you were here for the bakeoff, you mentioned there may be a NFS 4.1bakeoff at CITI. When were you thinking this may be? >>> >>> Bill >>> >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > NFSv4 mailing list > NFSv4@linux-nfs.org > http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From egqx@sify.com Mon Jul 09 07:11:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7r9p-00010a-DG for nfsv4-archive@lists.ietf.org; Mon, 09 Jul 2007 07:11:57 -0400 Received: from eng164.neoplus.adsl.tpnet.pl ([83.21.252.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I7r9k-0003Tm-MP for nfsv4-archive@lists.ietf.org; Mon, 09 Jul 2007 07:11:57 -0400 Received: from pcgld ([80.133.210.174]) by eng164.neoplus.adsl.tpnet.pl with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:11:51 +0200 Message-ID: <469217F7.6040402@sify.com> Date: Mon, 9 Jul 2007 13:11:51 +0200 From: Rowe Wat User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: thankful Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.6 (+++) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 VPSN WILL MOVE LIKE A COMET AND ITS ONLY GOING TO GET BETTER! Watch this SUPERNOVA closely MONDAY! VISION AIRSHIPS INC Symbol: VPSN Price: $0.021 BANGKOK, THAILAND, July 2007 Advertising Agencies Ready to Ink Deals! The company wishes to announce that it is in final negotiations for representation with some of the world's largest advertising agencies to market and reserve the blimps for there clients. VPSN THE RISING STAR, IS SET FOR SUPERNOVA STATUS ON MONDAY! , which must characterize a nation riding modern technology's leading edge. Knowledge of this life cycle coupled with a like knowledge of the Georgia coastal geography can help you catch fish all year long. Assenting to "go with the flow" for now, in fact turning into a glutton for punishment, I immediately resort to what is sure to be "all Pope news, all the time": the Polish press. Please contact your system administrator to report this fault. But, I welcome every single opportunity like that. You can unsubscribe from this newsletter at any time. This serial is of course in Danish resp. First of all, the Queen let it be made known that she did not intend to be there for the second marriage of her own eldest son. Reds follow a definite cycle during breeding, brooding and growing. Get a chart and find this marker. John Hayes, the CIO of the Air Force Reserve Command, explains how collaborative tools, such as instant messaging, are helping to support ground forces in combat. Well, at least "Yes" is currently ahead of "No" by only about ten percentage points in the polls, which is taken to be a worrying sign. But, I welcome every single opportunity like that. They lasted from predawn until almost midnight, and we always seemed to catch fish. So it's a tall order: coverage that can discuss the report, yet disregard its more blatant presentations of sheer horsefeathers. Sit back and do the kingfish troll. But by that point the pope was already seriously ailing - and then he died two days later, and the world's journalists began their own professional pilgrimage to Rome! Hint: search for "Amsterdam. Yes, it is that good. Corals stressed by warming conditions may benefit from the passage of a hurricane as long as the storm doesn't make a direct hit. I used to sit back and pout, which made me even more miserable. MSDN Webcast: Building SharePoint ASP. Cobia, red snapper, and beeliners were the catch of the day on this trip. REN Real-Time Sunshine; This is a "thank you", specifically for our return visitors! Trolling for kingfish requires some music, shade, and a few beverages to cool you down. MSDN Webcast: Building SharePoint ASP. You can unsubscribe from this newsletter at any time. And What You Can Do To Avoid It. Access Error Headline functionality has been disabled from your intranet. If you are the system administrator, please click here. MSDN Webcast: Building SharePoint ASP. First of all, the Queen let it be made known that she did not intend to be there for the second marriage of her own eldest son. John Hayes, the CIO of the Air Force Reserve Command, explains how collaborative tools, such as instant messaging, are helping to support ground forces in combat. Our NewsBite Tools are available here. And in fact this weblog had a discussion only last August of an interview the then-Cardinal gave with the conservative French newspaper Le Figaro. Action on Offshore Reefs and Wrecks Lights UpOffshore fishing is getting hot as the summer days approach. , which must characterize a nation riding modern technology's leading edge. Georgia's Year-Round RedfishRed drum can be found along the entire Georgia coast, from the St. They lasted from predawn until almost midnight, and we always seemed to catch fish. But exactly where along the coast they will be and how you fish for them is dependent on what time of year you fish. Hint: search for "Amsterdam. The name sounds familiar," I said to myself when I heard word about the Roman Catholic supremo who henceforth is to be known as Benedict XVI. Cobia, red snapper, and beeliners were the catch of the day on this trip. The purpose of the blog is for divers to share their experiences on diving accidents and fatalities as well as to offer safety tips from a medical point-of-view. They lasted from predawn until almost midnight, and we always seemed to catch fish. Rainy Day RitualWhen the weather turns sour on the only day in the week you can fish, what do you do? " Diver and author Mark Combes used his love of scuba diving, sailing and the Caribbean together with his background in Englich literature to create his first novel, "Running Wrecked". Each of you can help! Sit back and do the kingfish troll. From xbs@asahi-net.or.jp Mon Jul 09 11:25:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7v7Q-0006vK-Bs for nfsv4-archive@lists.ietf.org; Mon, 09 Jul 2007 11:25:44 -0400 Received: from [213.145.124.229] (helo=mhxfyb) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I7v7H-0002jM-7h for nfsv4-archive@lists.ietf.org; Mon, 09 Jul 2007 11:25:44 -0400 Received: from [58.72.31.149] (helo=cdc) by mhxfyb with smtp (Exim 4.66 (FreeBSD)) id 1I8R1j-0006cE-I9; Tue, 10 Jul 2007 18:28:44 -0700 Message-ID: <46943188.5000605@asahi-net.or.jp> Date: Tue, 10 Jul 2007 18:25:28 -0700 From: Elder Frederik User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: invoice.ee6c52348.pdf Content-Type: multipart/mixed; boundary="------------000501010201020303000700" X-Spam-Score: 4.3 (++++) X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75 --------------000501010201020303000700 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit --------------000501010201020303000700 Content-Type: application/pdf; name="invoice.ee6c52348.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="invoice.ee6c52348.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDMzOSAyNDFdCi9Dcm9w Qm94IFswIDAgMzM5IDI0MV0KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQozMzkgMCAwIDI0MSAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDMzOQovSGVpZ2h0 IDI0MQovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNoJVgrkjobqMPqFDclZT jxmRVKqyG1ZqUNX8DKkCKhUIrmho7axOAALBLWc11tkCr1ehx4gYPgRFpFXgdjrY2UsKwFohAOgR jgQ+gVuuAABMHwUJeI2gZjvkpy+OsTkTkKB4sXsLKp4B1Uh92WVQvJVMY+scHzmd0uRtBUHdrhgY twAayCud2gWvvOYw2NzrWgWnglngmXnF6gVZ64+eJCw4AIR48EDXt36UGWUC1hCgXAvwABsH88L7 UDYvqAB4J3tu9mItr6yDEEhDjLwga9NqhT8AeX7oIOcyvFkxiBiEckAgAB7JuEuy6vjAiFGK+rwv ygTyIGxKFgwgpPIK/aEnI7TuAA+qBM6srooK6jqoGzoANqzUPu/HcFoFGqDKg1aqMcgUMC9BqGRc rhSw++7wRFBjdv6c0OIKLiELo/b4usPDaQOg0goTEyCDGMYhC5ALgoE4qERwgruvu+8qyGsyGwqg b3oJDc5uugcfRk3CCrTEsWJyvT/tqrj7ILBTTysgjzvPJCBz5DE/ycADIR87yBrhITdvKhMuIQFd OP+1LaQQvszoO1gAS49gAC8BpPBXAcCoWzSBPUvlRufPSGVQgcmRXLNA0dUJizsAFNt2AC1J+2CC NDT4hSlUQALLRSB2WAAxg3WdjvbFdOxcE1nR1PKBBfai0h3U6EsrcMsumhsgPwhNTIHcwATdaIAF YBJBLrG6FhMG1t2evkExHYqF2PJSEy1bCB0/GMZWggod0Raz/08sVB4dd1JITfJZSSgVj3og1wIM sax1BGaBQUABwPPkGQoOyCEFZP8N16hkQPChF/sagYlVpaLgi9oTLPkzNt1DO9iN0hmmoI50BIRo EeAArmOZug+YKA6mMIJZ+zGtIiDRMy9j2lEcNbBQQAXZSEducFkOoU0aEU2u98gA2O1vpd2k6mgR G6dglo7q46Ftq9W26QX4WZ3QKCE4RuKxQggE7u+DB09YHMPAPGvcAn+Mc7SEkid1qDbQwROA5rhB GsDBrdaBInV4guMY2gU69pGvEoLuCC9rDF8tj2LNoTnreaKADR92gXfidg174khUexjxe3l+cCyd zrqCgT4OZLwsDsct47b035e0qjdeyABOsdocL99StAuO9XQQ06hUgTDxBMtxszOhZAvZAl2ADuiC AYAe8BThDn9p1bOWk8pyG3gAA4QWCw1movgIabVdhMyvhvIk+gppoSegmBM38giOwWADHNBAhAv2 3gmhGQMawL3akrNejWFcQinRLiYR4WQLBfhwF/EAiKy3OxNIlCYFaqENPvNq2EDgxTuv+AA+8m7p XDsjZKR8LkbSSOsNyQIacHl6DmBZHcFcUwACQjbH1qUWxPPCbsckhzbVYEITQQZipqCDK/INEEi8 hlUCsGsHiLa0W7mxUGzQgUNYwsPIKgyDxODisJAAchRp2HsuKRnHBM8d47gPL8ByPkbmVHGekAAs JoXBEFPANZnMp45s+ABDYgUtI+y2CcCsuTXj9mCiu+RaERUbL1IcuB5cSSISwhtElVCx1VQojLKg 46vzCOKM4X15Uw2lExT4uF7DqDruCFccyX71ZuAsVVN4hKXmEyoNgbOGSZZDvvmMQSRc1EvzxIPP VcbZjTIsN5HcgU+gHrslrItBq4i8GybC9mbRDgdzcZwQOb63RBCiLo+Fw9HTQN5ABQ5lrrT9ztJh QqeKO5VQ2kMQ2g66KNEDFEukg6ZCCr8MmeMWQ0yC0HIGJAgorEL00jRNFv6P1oKSpqFSiksJZQio yQs1yBSvB4NqaKo7SHGKRqey6NtUjhALpVSwq615OUVIEoVHcoibmTASqqMs8TBMlhXT0hlP62kI T8vg18vkPL8SHUqppB5IMukohhXavJorsNHKBaLKTFEDqdPwhS4DBP+QOj+Mih4azGmNEGZLFmht EpbWWmESbPWRSyvEmx7RWIqsC5R7BUipNAcEd+w5BLXkJWSruMttKGEFkMoYg9Tq8UIINcC4NLSF A+hqxxYKCUiW8uvIdyDKkizxQOJywxCByWtvLDaRcBbnoDrqVeL59GOs4QW4Ymti2pH7RYYIyEa7 CqQITL2YtormJwQC++K8vTOuTlWQawFJiDNSu2/djVnHMXmS1SFdDjyFTvcAZdA4Jr2XtIRCuY1g MSJ9AeF5qLAp4XcOsmOVVeSCvQJuFwBqF1ksIs0mE65Y2w4sKraKWN9CCLoqHhAhWKqsJ3tBTDJ6 W4+p+WTduMzpyBXHdWhhnYMAYUglhgsgQZyFiiyIQNDmKCDXsIc4Kbh7c2UIyCE5JlQ3w5xY1jvM Njmsk2yBBcgbpMBnWvwzS98CyGZnuVRQhOQS3tC0VKZ1zM4aXTl+826pBQlWxvQ5UgcSRSurIIOD M2Yb4WuIY+3AU8aoGD0eQrVmZtJTF0oQ3DWXy9kD1AUWwZg7vUhIPrsiADZKJMfa8LAcWCYlZo/d XXW0tsbZ21tvbhB8L7AYy2yBu3dyFAkoRqMJEtexUgE3SwBky7GXK/OYgsQWW7l3wTwLmGiLgssq Q7XtFwACNFfH17hnbgIaTAXkzWOxOU83zxEmsQOCYYIHM14jIwbKuIJSFWeytJt/BZV+SEky3lxp YXcwR8X5G1yVxLmBKJgb+xiseSwghPVUsbS7jmgyCKzkcQVdnIjhZqcglw51gKaYn1sgeh3MeoEq uteddD4NNUdFkmLcODNxsZzS39dDQEuVSr9jcWXZ41dC6j2slHU1j4asXVUvNqCChJIGhEg2kobd gIHiTkxAu4ojd/zsx5Bdq9s8QR/qZtVj5dbtdHLAAAUMAIRpLF3RogtcyAQLLrhac5L8T6Ej2d5W QCAbycgWRD9xDZG2IggKAUBUF+/sgvIORcjDg2RsKqM+MGQr6tfXovhEipJmuhHm6hMIed4TyPkv Y9TAB7aivIzSe9xv0X4f2Sm+w9j9r733yC/c/B+P8n5fzfn/R+n9X6/2ft/d+/+H8f5fz/p/X+39 /8f5/1/v4XtPoiBNrsmPqLFPUCHvxCBwDiHpjF0EPtaj3C3p3o0CEQDvJiBP/P+CkqnNJQAteM0s 1luI2s9gALtIzAigqQEwEh4lyoyNdMztYQPpJM9shwJCDwKQKqDg8QOQMChPZEdEONlMFNhM6OqF bs/MKAAAJwEPXiCPZgNgHEdwWszpeqDsFFjmvLtCGwKvnLQgAQnhZBIOQQdigDylZv/iBgYOHqnJ jQHD3oTE4HqwlQ4wuOPvaw0qDqDlziBBRBPHgwswEPYPJPKQxCjxAQVCCOQAYAfNegAMLpJGCuTw sH2AdgJgim0RAw5FZgNwAszRFKDsLo9tSAAQ9w+iFwtPJxTiBwLxBihPJnmuguOwmCBuSj3OipxC CDiDek0QtPnPZPaAbNrtdptG4BipaiDxbHbQlQEthxVigQErhCDKPpjJ+OxwCiDFZwkw5PnPYNhs ztdxotxCExIiDkTQKxACBRdxmChx0ANgxwfwWrlC+ogBinHu/iEJDAjQ/xTGJobwzR+wPG9JFNmx jiCAjRKRzxzx9R0iisEFvDxizC0k0EIFZghOOCxgTBaiErTtbMknFyGhzIIjykTSJEJCDIaBag6C GExK7mrkpg8AvMnSFIlivN7uttkCIm+J1HNiasxyYyeyfP3RLCOninUr9kLHNH0DyqbSfv1SlH8i IoDiBGGkooxnkm/wTQuSlvEtqSbCFF5pElyu8NBFuk5LByLJWIyABjEymysuIjQqjEdIQy0lSjek Cg8SwMwCCs/E5S8DajujbjOocjAS1y2N8RXgABgCBoxnWBfhfy5DynbxBJdCDqgqyJTpHEXBOBgH ZNVCygBgASgzCOYgquNjapesPvsTPSks4TIyaCHFrumwgmbm/S5TQu2H4yVy/GzCykTDyqFmliDQ jqOs5CEmILIzavQmgHxn+GzC/BexKmfC1kHDBQyolJGCCPDjDIxDHDcPoTjuJDOlmppMJyPFKEsO fmziGDqLVjtkooGyYTvNypckeCxGgDuj7LViFu8T4P+JNOmy3z90AI0sco1vS0AzvJcyVCDSGCcL VRY0DNutAJTz5tTzDCOlpHhmZtBGHLkD7pqUHtpJnn4JdjHzYkqHWoHxLJEiEHfPUH3OrlKpdy3j DkqUPtuFAL7qYNqtUtVJimdoeGtCFIBoSw3qWGFPmkpTi0attKqqirpCDHNIdLyTBukCCFVMoy9j zkyLvyO0lUQL0mZt6iDJgTGtwPjguMLkmEuMKFrugrvCCzW0uolm6k5kyLrT8TBt2lUOkwRy9zX0 J0nU4tpRbHE0tR5TFJgCCKmCGkuJJuLvrruVIJeG9IwhS04VAuYIahXNPHasOJOpkJvrLtvlKz+m SLCAWVNOX1Lv1DSpaKEK4Tqs4PW1VQdyuVZ1bVb1cVc1dVd1eVe1fVf1gVg1hVh1iVi1jVj1kCQk +Evjkzhns1TzfyottubjUJo1guDIhAFnwkNuz1ISKl1s2JDQniSEsktVOvKwdCIKp1q1ismnHAfV sForm0iscKdNTppAlTqCFuRqLgOBGjIQrPABRNvhzHa06U3AAO7CBEIwoiKjJy9FFDLmwy318gHE tV0wPOKV4SYqvA4IROLELM+U+LtkCO0vCjRgFTuiEJYg4N/FnmuRaPehPNf0jFsStvJAFD0IGwwi HrfVH1IGPS3gWQVANjO2Gvps02Wowz/wMQFmxmmE+mCMAvHvWPQIERzCJoCvdvsDKWfkcL8xzGyQ oCKsuWf2DS8DFiBQHRguuQP2OKSWWgzhivGWQsh2qBrPmWJlPRnJtm2ByRisAWfm1qzxtM1Q6CKP eFMnnPgvXCERDE7RuwzsFw7yew7G/hfo8whnINEWumJC7gMOVnTix2sW+iBr2AYI+FaNLMfH1iCg 3oZRUDpFZwHR+1FqS0iVHjBIXGkkiC+KoNdwpOjXMSetduiOfHIMgiBHvpBD93QH4XXriQ/lvXSr yqoQQ3OXO1YM4XoCpRT2w0uWeCDQGlUNLMaoMzhCvwJxdiqC+XgP/wXyY3i3hLErznvi2EWHRHDi wMsRUQFCCMulnw8mCn2k/gihWXnVIxLxzQm2ixDiGsVqEIL0LkbpCPwx136RvPpyfNdU3WnCSR0G F0HWPw2ElJLl8WCnRNixywKxewytWiRXQVZRtWwwVwoR3ujX410iTXSCGRvpOppLzoDFBxL4iCD0 KiO4DlAvuWsWiPa4X4cSFYdYoCNRd4QCh3wiIJlguS9CjVziMR5imWjx4CLpqYrCET8Cb4sCHi3o tyBiGYzMpiKE4y9iGBf181LCFt0qxCfmW3gL4CBWPMeN2iCEVKV16AqzQW+Quwz4pCGJKY0CIvYA kpjGWCFR/mgiBuE0X4KwliIwwg4I4xwucl8PUDBY4ZJy75LRF2P1XHa0PCcWxvogYL334IRhGtRp bGBBPKVHC2CmvAqpE4ltROP4bm9ZLpFN9w3Eu28ESwT4qvuWFQun/QArW2VLzkA5eOrjkRyZFNI5 aPppZVaiBQsC7HfruSrwJzI105qxYKTK3iCYuCd2LAx4X22YNDckP5cFREKrAZyiBgtYLCD47HqQ AQAAYY/iEWAwRldZevBi/gdwUW06DRgZxZ3LL6FrMmujX6AYZxyiB5o10aDryz33FPrjnDzgtUVZ OgAGuGWQdaDxFoCtRrsif4awN3JMGM8Z84BXztE4LYeOjZY35CE2YD3gvOcBPPfi65zTPw5YzZiR gaYGKXr5daksBPBl7xySD6tiEvpXbsGvri2W8Y3auIbWiwc3gMzUt6vkY59aSien92jacWkLyiCL F2f3svX4QWc2F6cZ7R7KwnW5NaliBR8QuYza4wwYn6RCFYSHJj9l7xsYFRstkrJ66iDna1ljhBrA E7DZ0iBa+QnDwW11722qnmKzgiapjWjZiryhrAWW5LsCCsTaWFD5FQtXD33CE3xkuLFuEiDHwZuR nbV4nYnx7MMMhZyalmuG0aPauPKiC3LCF67wSLg4CbPxLxVYxYcW5RiMsifDyu8bW4cG3wqrsn3U CgAQTYrQtH9j47ts5sMPGk4NoWoCBbJYZpq5pQv6JmjOLILvHL6m2gExJ50SE6uwOQ06prF2ILt4 3YlwKwmz9ZZbjKDoALDa7uYQ+bU7saQ41Q1vTXsb0ZBamiIaziT8CD+yEZu7iiI14iKZhNhXHz4b xiCxGq3N9omcY1kiRxf41aEwQ8dcWceCYxiomaIY4ciclcl8mcm8ncn8oco8pcp8qcq8rcr1dTYv 2ZIVkt5y3Ns1rCPY8P68wiYC8qBCxCtpfK1Gzzou7lyyolXE3jKEvYKcyiDlKTekTirYZE6Dbidn V5X6JGNCG0y1pR+TXH8Mjknj6LICDoPcVX9EjlxkJhBFbD3Ocurz+qzMdn9r2kajoDpdImAR2a3m u9NZOR7EQJ1FKCFk1EJiIJoOmqPmjkaSHCFGMUFkmoNNCCGDfFrS8Mkmjq1lKvKEklUGYPO1RtGS VMkb0kLCBTPFqC0SI9JmXBBAnG0AGpS1YiHIOMrFSG4r/AAR2E101DJLZnsSytqb0j8kF9pE5SR9 KE2lRFcLZ1OkXK082Rxyv9SibsCS8UN40TQD9jGDWFUHRLMLGNGMwH5seyPcS9pkCmMI29Ldklcr nERjkCGRXkzd+L/GA+LEL5xrMi70Ip5XGyGLxdW1RkIDGgx+KmcM+O40MUMrpEgdfFK9rCbSNKYY j9iiCyRdyGXPU6vurGi+AXGzDGIgWL/FTDX5K+iLZPemDuMiGKQkdz3jedfqH+iYBWaLt+e+lc19 3LSiCmAzPsha8EW1ACGlTX0lFrhxUmGuX0fIIzPi1rGkkuxDIi33zL6nDeezwpfFRkrGle4eUEK0 PKxmqGGlgSxlDyvTVvCmXvOMb0QnAFHe6LciFyvsMdsd0eiiHEydddiJTiv8xiXdZMsGGfSiBHOG 0DeuVOfPeILULr7GilsiD+PUgb1KOMKnIfbHCUXiErvFf9az0UgHcLzjJkMF7jXfV3Gm9e6DvUeQ 4dEGnaeZ4nxCC+fiDfD87iU4vVldE/M0CCGrye8EWEiFj0WCNztCEIIJRxniypIfFNLurLoDBfvV K8uFqCADsiuYAABZQUABwAFwuIJrBiEKwEgknQiLRcbRdODYhMWLx8ADuLQNZFWQSeUSmVSuWS2X RYuS+Pm9yTWZSprQglTeeScXjsqFSUJyETGCg9rF6e0sqQKCyaC0SFwycxGJyuDxcTPETTKBQSl2 GxWOySpZDZyTewTcXx+K2W4XG5Req3O7Xe8WGGXmQAOQEWViuPgm8Oaf3zEShWS2oYnHSq1zJisU xxYHzdIUablXORaapyuwXKHiLCxeubGyGVwwuYsACvNQVzaiEZwqxmX6baY+7r8TMVITBWNbSQUn bOL6nPbzH5GXCYOMVSxa638WCyP8HIbO17Yq1ma5+C9FSmPigAHr/TwigxcWA/L0XWcbBQjuOas7 azwjxSj4ru2asgAzj9rGKgiuwo4Hug7SpuGhAEms5Datsi60os8iEDwaz0uYsJRLrALlJA0KLDw8 7TlkaaEB268EoQhScPup7vIKHz+ILF7KoK6qCva0oWBW/7YuMiy1rAxqoPDC6QQ2B8XgAoKhRyAE gpSnIVkE+zuPy20drScipNE8zSvXHymuvKjxqKj5BRAyKSs6hAfSYAATBYVzJoLE8OShDyXgWUUt vxEbPNBKEToQ9T8RXKMXPcldBNkgs4zk88LxKj09pBKaERc/8GoQ/4ARCp7aoKmyUxOJz/xVKUc0 +xQHicawFtlGcB1OAElqkM7JiE4tWPU9igzTKtPTYi1aUC6rnT3OsxU089Rz+l4GvshEBJAmofRL Taj2zKIqTvP1qJBa9JgBZzGwvG7RQ0kC209F0XxiizXIKwl0wEqA8TpOqPvPdMo1hNSQNagqlNfX EkxtC8LhYTlfz2t6EBeoM74NIa6QhIyT4FJipCEhGK2ql+FXVbCU4AguRyLSd5WOyyV5QsERQoPF UnJbuIw1VaLW1F+hA4zNkoKVhPBXCbus9lkTIuXr2YMlMiAATyP35b6LTviVpDxVlw0hcCCsyvYA AbWYvXxlKQNTJkE00AGBZMluUS1gaT6duLzuwWQXhhMOxJTu0t20zl/P5bqLxPgTI0PY0cjORuja OBO77ZXMBirxCUZdRWLKilmqokQUj0rUyL3dgOKvxv9kamRolM1tAvZRdTuOTpudtDve6Jk/9Jcx vKQd6gpf0oGHAcE/yEeDtvDpvqKLceuUKpTuKjvUcDwdEkBWFFy+b9RpvFZbxiLe2GC4dwizlPCh Exbn3yVXQAF8Wci9QoRErzx6vL1n5lyGsL9F76iVk7JWutbaqQAHSfkYlQsAS5r6bDBIlMACPuqI KjuCy1X8QdhAcyCjeHMwgNQnJbZFzpoehQcuEJK3sQvhkS0Jx9VBlQgi76D75HeHlYE8mAxMguAN XwTE477VCp1W8S5yBjl7QzigQWJZRhrMlduhNGpJzoQxLkCsq8V4dq7feQk6SZG5A2iAShPzkzWR EILF4ihkTUnfBtBppxK4mlhgxHVgEW4VxRhkfFyZCyEI9Ocd6JInAWRPAAGNAoAI0jkRKdeGxIDi Gwaurh4ZpSEI7kdGiIJH0En1IUK9ZIeD6rNQoZw3CqCLmjJXEtIS3iYsIIKFwTyElbpxRoWgjUi4 uSAgsfFGJmm1qkIu1kj8DENAbAcHg3EQHkuKXouYiJCFbPCJPBoACYoVzOmhKFsSCSuyDkJMgkDT FKQuPHGUlc3D3oLPkQwxcNQFoRVuoRGkKZhRQOwk+UrlGrEXnUhY/sG2wwGgMWleifiYEIlSSuDk rl3gAA2Sw7CjzLr2KNMdlUJYcp4JbOI66HCECvKMTEurV4wJdharufs/j3pVA5OZIk95dOYW1QYi zcQHEFoVUBOy9CUGaLfCMk4sl/MPIQGdHISpnEpXIlWmcixGg+pSSctcyiQLdV8SuUM1SETmaPNi EiFELUxpkeiWhHwGiiPqWt/0YpmNxovI2oUkKYGrnoVV+sF3OJMRKL+qBKmMuQOhTarR9hrDWJLY ZMRKKwuvISRczTCmlITVJLx3Ud61N0ReHAl9coFsAE4CgBQLB4rfqC8ljLVGzIeiDQ4lbaxzWNhy tyJZIJQrkcgn4hjaGKiss1bi0tn7kFyBQChTtPwAHaoVJK5Jd4xkqnFb4hForLRDrndO71326TiK XGExMbZr3gvRekx94ie3kLjbRsqyi513vUY62hmyQAopGXch6chZE0IRcu5ZFgNgbUSQh5J7nINd gS+xGkEcBAAF/aslt9yPlJIkXC+kE4jknXZWphTcWqseHMYBXRF79EWwnhuvJYiJpHCKKwDBJkCS +ABgLAeEh44Fh/WGogXhfsSwbZrGcGMA44wnRYPCAn1YJYM8c0RwDLRVo8clOR4cUkFuXkklL6om 5AsifNyoCTkEExjidOuEbw5OVgCzKCJZjRVSNJo/WRyLXMy5giUIMGeGWN9IwixsJ8OYIgfo3GWc UqdI/KFniaRfzWJBUidEJc75aeNRbAxxZpQGNCsbP+UiC1/guhUtA5Mc4CCplCyWfLX5uPSaFstR tBE5PuVUzsj8cZZT/NLNuniu6gr6xXDp3YAY5y1rohEaCLTTWNm4FZviUQ1C4votZizvFZ0RpYk+ ewfKP2dqqopH6C6VxvpbHeBqgVBAAjdyGzzf4iJbkUkyAsU7Zy7AZBJ1xf7PNE/qKugnbsDxpnfH Ga8nNvVFZWW9fXmkgittrY+xtk7Lf2xok5w9pMDIJw/e2yOKYIJACy7RKZK8Cvztq5YSQWYFILK3 BF0lPBwQXRwlltwnGdMbvXAN1pRIuu0dERsxmOEfgxrlk0oMnWzuzPIgrsp6UCR5yfFHHofpzYNy Oy1EEeIzirY/iG9cBBJIxsuaevSV7SgodzORH+dY3yzAh+U05Jkg6diOj5B+c9f548untNuML5qT iiAOTMWpQ6xWSQs6epcR49c7Fu+LKXbOG/19kVTGki6/mqCu6d8R5JQhulk+ST9txxyogvjuQSQ0 6dfrBU+7T5zl3nt3mttkfuwUeYBwiq+hIvFbgrJpnhj6S8nmDUxiuxNi7ZLdjSR8E49Rbj9eqhqP JPwwgqb73XJ7CQXFn0q91UwsSntRBiEYm9n8/6LW3IHwt2RZy5KwqcST+A4WXws9ZseIMWBB2zq/ mJU/2+8iC9uJaE8aSvrAPARASy6qmSqAe9au+dKaxAVAmJexYvYLi0kLCtcza0guSE8/e6iJu+7A oumwo9SwUwsxHA+I+/2AmCKKE2M9++4wOJOocV83gVmJUqQ/QMS94XUR7BfB4ILBNBIu+xWucEgj SqAkU88bIJAFFB8HMbiB3Bc/i1O9+x2meKG+oVIyCT0KmbQu66aIu0ULuOAti+uoIMjCpCC8YxVC zCKu81Sx2T3CS+HCYJPDOSIecXUbiX0xM7a3Kx0utDw0uoqbNA6gaA2EFD/Cs+cwIbkx7AuKiMma KIs+UeEASIFBe8YyzDmvpDtDin62QPOoU2ZDzD0vkIvBMX0Am5Q52xuxWy6cEKkf0JQMmA3FaCKB 3Cu803OyW84/wIu3A6GY8QhE1Bc704gT2FkA3EnFEg62Qvo3Uqkcof8Lqru8w8w3seNCI0WcEygm CJBG88xEE6NG6tY14JPA6o8Mi+7G5GkgfGghfGk4mkhCUJA1UVDHaIQU1D/E64jGIIupI30PrHEw uIugpG3Bk48BsA5HwI/IE6gZKGLFzIVFhEEIQx4W1GfHmWq9+ReyZGEZmoqlu3FH6IKbvFc/OyPC E+8XmRe/a8U/c/LGXIw82jUniimI/D4OAcu/M0Q9oA2onI7I8T+GKWAYSo+okDGCEToa3JOJUs8O as4w+V2B8Hi5cfkHMKBDKI/KHKaLGSYg1KQOKC8PSekR9KNATLAom3WJ5KnKohw6sVQfKZaJAHBE 4g6a/ETLXL9L/MBMDMFMHMJMLMNMPMRMTMVMXMZMbMdMfMhMjMlMnMpMrMtMvMxMzM1M3M5M7M9M /NBNCg6kQgCSOwehyJS1VHKdyIsMqIaIgZMkObkX+IsI5C+JYK+JK/q+hJMMcgI+yJkS4yMcSBM5 cJcJILUfZNIqWPCm4Q0WE/CJWB2bTJSZVNIVRObH7LKVEygQEKC8wp2DGNYEE4eOadyc3No3XKyI 6a00gKaJIO/N4nOJCiqbU1GhaW4p6WAOLLQIsU6/M/q5YMUfAPuUISSsCZ3KyJuK+wIA2B9AAIvQ IQmp3PQSWY/L5O6MOSjQYJRPIB27WeCLAq4X+gYI7O2AAbAAAHAILK6KaXUQEwKdVBAN4s05wRw+ +IRKSbkJU/8POqMAwVnPKlWhQurRNR00nRYSnPAcPBGOMCce+7SysO+RusEJ5NWc2A2E48QXu3Es 5Lo8+Pce2CqJFO+IG3CIufu5MnWI+laZcT4ZkMaSmLWNITE9eMSnUMaNwW4WihXHkRYaADwyCXtR mw8xPRxOMZeYs8xTkJYrnNknXLGJ40VNQZIIk7Sn0aAJUh8OK1ULbP+qKIaLq2El2hQjoWhJRR2I rO6akABTNPjUEdkbozKpdPjOwfKMmOnT9LUQogHTqC4IeLNUMiUK4ewbmb9TIIK/8JRSAKTGMxOJ MJouqJe0UTjDEYTUsrOfHDyFKwOLqIPHLNWI+NYKqLq2oQCiQv+IsW7WIU3TfRVVZVa/JC6E4A5Q gQ8II2IpeooOwI9LcI/Woc+4XV+O2j2K0TuXsbmL9U9RYUpNQBesbVGiQQqLPWkJdDKJKF/WsY6m 1UMJAkYPPYVRae60m2obagWBMtfT6OKRfXBTMwkRgd8OOq2ZWikjIj+JO0ULW5HXsq0fFTW9sk7G GXVQ1Tkp2JPXKoIdPKtOcJTXDYCJUPrZks00oRIcWc+MNK7ZGGsOGC9ajZMmW4qgaT3P4dBT+YNJ kN4ZKXW1KQuKkOiJUUbWSspIOoJUMgid4MpJIN2U6+yiLbqVNKtLiSMCrbik4+qNaOIIKE9akfas NasXBLTK8UUN/EsIWQfcUeegAZCTWW+T6TNV2ZlZed8hGXXYpRuOhWDXhJiaJDRKicxc0PDbcOkO oIKTMSkQPVAzENfb+VzTyooJYRSWIQRBS6eJVUosikacYJy1VcKIu/Y0AKwiy+/KmQ5IkvU4QLE5 ncqkso+gBRIVUIRcjO+JQ1i/FJwYcKYTQZMPNbJZ/M3QK68mWM+TuqcAAc9SFMJV1NEn7PqWusyS 4weP5OateeKAARSZif+c4+/eQJRDKShehf3I8iHOpKXOvRvVRR2PQUXaMVgVGM0xGs068NsZzOwS oV+YEUXdAanOjgjCK7sThY6tMXhRQJUrEIKdjN6IvAiNkPzhmVSK6a7R1OgIIdcYK61hbL+vNJpe 6rTKhLubkWFBqsoDOXcxHQIiufGSUJsLSRLTdfC3Sm6iXL7iRBJiU8AcKpef0SYb2Q3Ik7mRzS1P nS4MJXxizCcTA++WlafIganjJL8NittZ9fc++0ArmTEReMuKJZ4KUImIrREV0IOfeSYRjfYVo/S8 jj9LWNjbVKXaoPDZQYCt4soePC9e4ABZLdedRi3bDW4fPBPcNkzHmQYpRdoZJk6RHPyNFU3lEYMQ S2gI+Nda8iuTkKgl9SrbEa1JfkxljCKz/S2ItSiJkPJX884B9kOIKDhIk1FUuoKIySWQvYRkvmZn G/vlg5LhznRKkuqR1nJnbndnfnhnjnlnnnpnrntnvnxnzn1n3n5n7n9n/oBoDoFoHoJoLoNoPoRo ToVoXoZobodofohojolonoporotovoxozo1o3o5ASICACmVuZHN0cmVhbQplbmRvYmoKMTAgMCBv YmoKOTcxMQplbmRvYmoKMTEgMCBvYmoKWyAvSW5kZXhlZCAvRGV2aWNlUkdCIDI1NSAxNCAwIFIg XQplbmRvYmoKMTIgMCBvYmoKPDwKL0ZpbHRlciBbIC9MWldEZWNvZGUgXQovV2lkdGggMTA2Ci9I ZWlnaHQgNzUKL0NvbG9yU3BhY2UgMTEgMCBSCi9CaXRzUGVyQ29tcG9uZW50IDgKL0xlbmd0aCAx MyAwIFIKPj4Kc3RyZWFtCoA/4FA4JBYNB4RCYVC4ZDYdD4hEYlE4pFYtF4xGY1G45HY9H5BIZFI4 k/pM+nw+36/H49Xe7nw9Hk/Xy+YM/JXOH6/ZNA3w8ns+3u+Xq7nc93w+H0+X3LH7A6W+5M/oM+5q /X3WaVU5DU6m+nq9nGz2a63I36q/KE+ntBqnRHy/KZDH3KJQ+Xm7no52o13i53PA6/Q3q93q8nu8 3i+Hu4Hc6Xs93pbpM6XY73E4nU3264Xg7nO+Hq+Hm7XrO6pArVdXrhXi9Ho9nq9MTPKxqJNqJJD6 m6nE73Y4XK1Vwt2AnEo3Vgr3EuF+52s4Wo4WY03I1Ha9nlA3U23Q2lqzW4uGCymY1Gk0205XI7IG 7HM6ZY/IM0FytWyvF03VCp2yY5pGubRqHgebfHkd5hmuZB0HGcyfHufRyHCdqBnuwxuGwZp5ngeR 4HSeJwGUa5XjsOpqmAW6DGyaRrFqZZXHsoiBnlDxrGAaR2G0dBymSaJkFyZZnmqbBuG4cZeFsVRs GeZJ0m+dhplqYJ1G0bSfHVKpRlYZZdGEXZil0aBxGsW5smabByGyyh/GUZptmYZZtFUU5fnEb5rm 8apqG8aJwrUp6BGqXhcmkUJQGuShNG4Y5nGibZnKUfBnHUcx2JkdR0HS3aHKmeZ3nscBpnMdxyHQ XJDEIYpNkuahHkedBeF6ZpomUVZhFEdi/oGdBxHGZxXGEaZSF8a5oHAbJsHCcZynMnZ+wmap5Hid advogRqFsWhckYQpoEqSByGEY8fmWYcbmGbBoksZRgm4dLAoEmR6GkZRqoGmp9GWZRqHcdhymgYh gHWcZ2GkXBinbZaDG2WBcmKVpdHnGqBnIeJ2nOeJ3qsfZvl6Z5gFkZJUFWYBWlaXhGEOURvG0aWO HedDtoK4JvGKRpEmqSpOGEVpcGQZphGocDqnOck2GeYscnQd5tmsb58nwfJzHIcRtmkaOonwgZsm AX9GGKZRJEebBGkebhkGjmJ2m+d52lqbBpnavNOIglZ+2oeS7HQbhwnodZ1maVBSGyWpYHca5uma ZJlKNCt5MMdp2r0vRjl4WJoGEZJXlWYZsm0b0MwyaZipqtqBHWcByHechymmXRaGQWBRHC/RqGma hmGkY5kmgZZsnSdCBnoep5lqXZTmuZRhtmexhmIZdM4Ib5vHGbZtnCatLHGd6DHMZJkHWaRtHzAt eYmVZsGkcCXnIbBymGXJbGSXZhGwapwFOUhYlkWZnD0HmYkeD3SCusLOMgYo4Rei5aaN8cg3hwi6 GcLMyy8SCLPGYMEWw7DMqZHaVkfgyRjjcGuNIZo+h9D3JYPsc42xxjMFQKcbgxBhDtGaM0cwxDzi 1GKPQ17wRzj+J23Uh5SR9DcGyNMdg6RwjsHIUYco7RmP6GgLEVo9Ilj4Hcdkd48h0jlHSU1a4/0Z D2GmOEZI2VRDIF8MoYwwhrFOKgUuLY5VPjxNKPUdY3RvDGFeKM6Qyx9lKX+OkV4thUjSG+NoZI4R wjNHCNoQ4pQ8CWEqHQYwsRciVEcLEZozBtsCGqNMaLoFjDlR2SglROC6j6KwPsezVR7juHeOlwCl x3kpHyOQdI6RujkG6S8dA7B1julGN4eA8B6G6IEVkfZhx5SDfKOU0JsjJDxHiOocpDDbIUG4pYb5 fxxtVHaL8Xb9BYjFGM15uIwxyjcHIO09o3XnjhX2NYYwtxridEiOVtI80ODfHMNgbQ6h0jXHcOor kRCCDsHUPAZQxxoDcG0NwcroUnjtHUNwb42xhDFF+JYRo0RgiuG8LYXI1BiKRakQMvQ7xSDIEmLM ZQqRfC9FsL4WYyR7G0IG9ccY0RmrpGeMobKcixjWVQIcb8bj3jWG2LYSgoxljMGOLUYgtRwuAGsO UZo3h0jYHMNsbwshRC1eoOgTwnhYDPGYNaoovxqtBHgOseB2mtkFG2NAX40BPiWGyeQWgwRWjFGm LgZQ5hwCqGeKoV4yhQiyFyKkT4iBPjCF6vcgo9ztDTGWL4eKuhujKiQL4Y50hmDYGSL0eY4RwDiG EMofg+oxjwMMJcXQixeDUFcNQbgzhnjDGWKATIvBUCmF2JsTYuSyDRGu0kb41RujdjSNIWIuxoi1 FenAXo2xbi0G0La7o2xsDBGkL0Xw2RqSroYQQdUxRXCxGALYWwxxrjTkggMeSl4WjnGMJ0TwthDi AGeLUVI2xWirfKPEgw4BujQoMOAXA0xWC/GOLBC49afjaG+L4Xgzhfi6F0N+JJqx1DgPcQUczuRk CWEkNoYozGvC6HHEwco5RszEHFM4aI1BkMTHsKITmHxlDaGQMcaiE1+0GHoh0gw3BoDIFuJkQI0x QCbGIKYWgtBdCxWYOMaYw1CC/E6ucXA0hs3AGAMQgy0x6xvGiYoeETh2jriaO6cY4k4jag0MMQYd 5n4aIEUwfOYhVC9GCKIW40xUC/GULMY4tBfjjM0K0WIuhdi4GIMZ542hqjHHWOLPA1hzDSFmLMXg kBFDsiQN8VgqR6jxHkMQZQvcejFhXe0qBTBojSG2OQcg5xxOqgGOkyQ+b95NHQO4bYwRfjYGALwX 4oxJE/HgP4lhAx3jfHAPVyQ3h1oCOgU0lRO1mDnFYK7TItRmDIGEL+AA7rQjzK8TxD9AxeizHoOY c42jqjjHOOEqxcS6m2bmOsuo/EmjcGmscxhcbZumhRXkghMaAUOYvssbI3x1jfHObIeI4xmjLG7U caA3xhjvHqOwdw8ILEDJYP4bI1xzsTHjZweg+UIj5MiPQdpmBnDLGQKsUFsx9EDNcMUT4lxw5HGy OgaI30q86HpEIfzk7QmXlobHWNs4Vk0HsdqXsQh+wpNOTge48iXbeNtrogSzyzJQnGMRpXYR8HsH dCgoRhedEoHmPSA1dSzv0KwXI0ZP2ZxkHyPQWo0RSHVF+MYWorhTiZFuM8ZY2BjC9GWNcao3BrV8 HTpQdA3aN4xGmLMWFoxgjgGML4edr+3ez9p7U3auh1C4FwJ/kQyhijAGqNqNQqBSjFG4Nscq9Rej pHFA8ZY3BdiNE0O8c45fNC8YmPJ0MLhkjT6Qh4VwtRHiYF4IUWIvhSDQGOMoYV9RRCgFmL0XoyRt JFHEN0aY1xmDXTgN3ZoYIZIUgUBvgaijazT20BEBMBQiYdYeYc4U4ZQSoaocgZ4bwY4Y4aoaIbwU wUQXbBwcrEIXhO7NCRTB4cDtL7QYwYgeYpYUwbYa4WpQhCweAeIbYYBYrkQWQZ4UgVoW4Tga53ga IZYazI5bK+SiIZ6jq3wazbpAoeIdA7IeKZQdrFMBcK0K8LAgY2wdDkIeDbzngeZqIfQc5UjvQdgd iaIpYxgxg0bsgojqokwWp1qdwtDt4lgsAeolQfaAJD4eAcwrKVwnYfQrJwAdo2Ae4uprQfLqyhcL MR0R8SAkYngr0SMSsS0S8TETMTUTcTghiYoc42IvIbzBwXb5YaZPYcYZIX4a4WhaYdgeBDJ+4cIZ wZsAodIegxgexZ6lwyQ54c4dpqQYodTlg2QcpPIewd42JyQcoZYZob4cQaYdUJ76gcQcIWwWYcoc IdAYIXwZYdJUhDIaCJYcAgwegrIYi94bYeQeaJ4dKgAeAdobyJ4bsOsTse0BQbo0AZAbxZIX4ZbD oYAdJ3AXYV4SwVAXwSAcr0oZgXIVAZQWIX4YIYQZgUIT4XIZAYgbTsLo5QT5oVIaYZwbqAYX4dAd QcZjQWQWQXA4jzr8IXQOQPAW4SQQYUYW4Q7YIbRzIWQbAZwbQTwSoV554awSgSYYgbIaobwgyFQf gXwc4dAWyagUz46eAcoaIWQYIchIUe8rcBAfAlgWJK0bQdAcAaCJRXwbIZK1YU4TR4IcYaAaoZIZ 4XsoIUgVgUoToWYVQVAXCzjigbg8QX5xgcQdgdAXQbAbIcKWgT524XIZgYodIcBmwUAUAYoTIToa AYoXAch6wXkh4cwaAZ4YQVYXcMgdoWwW4Y5rwbYgwyIfIYwaYZgZhZoUgbQboaiXspAb42DQUrk3 rXQqanoeotQfiXochiYdx1ScYcIb5fweAb4ZChA9irwZYcTXobAawZbiYqAwoyQxI14boa4a6eQc gdYawa8VIZ5PgaAVoYwUwbIcgbgd5jU+QeAcYbgbrtIeKFJC6zga5Jk+gg0MR6wbUeBXUdY2Qew/ 4awboawbk31B5TgqZX53QW4WUNjbAfgxIeocxHgdJD4W88DcAcweweIewbQXAaAdD4IbIXoXYgaA YwpGQgY7Qe5D4eQbKm4a4W4WYaoRQQ4c4YgZIWIVYVIXIZoWQYZOAcJBFCFJtJwqYaIWAWYYISoS Ib79QeM64ciHQXLLYXIZIWYW4bQZwYQcAbUb4dKpU2RN4cgZIZwgYcwcreSu7mAlSVDE46qpQWzV IQYdwbQbYbQWlIIXQXwVIXoTxd8pNJ1Rc3oqYdhgoagXQYoaAV4VoZIUQTwcgXgXgdAZZFoaZ14Z wWU6gareQdgagagZIeIdId8ZlBwgTn8LwyMcpUAxIfAdi14ecM6Lz0q5QcoYwaAbAbwawcR1NRlY 8e9Rx7gagYT/AXIYQTgKoKYc4aYaQdYaIZ4ewdiD7hIrIqaMRZ4tgmwgQrwk04YpaFB0ww7sgr7s IeA9gfY2AdZ54eYc0YcKjclZFfUTAmQd4awZgZJNUz6wYaYWQWAZwWgVjnwdYdoagbIaJn4zobIX QYYXVVgd4czOYm4nAYIXoaFFoYqBAaz3wXizgedOFBoX4SASAdwb7bgWoWIbAUwVIZ4XQZENdfdn MSMKQeEfgaow7wBmTgYsZDZwEIAW4b4YzZ9bAUYVQTQdAdZBod6Aggg+YUi5YTwS4W0bgZwXBF4d YdQdwrIfJgjbYZobQdgb4cIWgRgQMIAXYbIV4VgephdnVu0LCFAfgpIqQnguofZfA2DowwAboaoX oVUdisaUopA0geZ09qolYXIWIUYWATgVYZE6AWdraYhXUeBmIeIcQarmodoeBwQUoahFIaYW4Uge Qawa1u9192BNgpIernUXQnaZ1creonERt2N3t31394F4IwVc13ZZ5awppZ7sgnJ0yV7qwnNJtcIp kRoqZu93l4UTopVBIcwaqL4coXoWIY5qgdwZKwwcIbwb4cocCsgaQbrUNVr4JEQZIXQUQRqw4Vd7 YbLkQa4hIqcwbBwawZqjYbg2dGpDpIwdJac+obobguwyQfAqbPAcTgM+Iw0ZAeo8AXIbVzLowhiA YeAYkbsM92jnUQA3wd6FJqLv4oodoqeCocwa4cLxYe88oa4ehTQxAd70waxBrX4aQaVdF64kJUgb 4QwWIOAUoVoSgVYSoSYaQYAZb1QXwWgWJoTHocRPQZK2JSAb4dIbIbKUKzAUASoTIXYWgc699/gk wZ054VAVwSQadSoYQUYV4V8g4UIUQXwas3IbYaI0QfCWoeLowYwTgTAWgTISAUA9BfZewWQYAawV gWCPQdguVcYg5Z4ZoZz/S1IcocYcaAEdgcAcxT4eQdocYddFgXQqabBBIVafQXQZYYgRoSwaIUIU oZoZ4XIT4X4Q4YtIQWoRoPUZFqmIIjqDgbxwYQATgXIQoWoXITwbIZhzS8wXIX2EAYIaoVtQwaoa AYwcIbaXswYaQWwXYYwUATi1IbAXg9kW7BghC2gfK0gX0bIbAX4TgTYUwRYUmMYVOW4agX7WxaYe YZwZwZhHgdgZoVaxwQYP4U4aoa4UIbQa4YD3UqwYId4cMzYYwZAhIdT3wYoUQWDNZGAVwXkKQepT IcIwwerB7HAYgaAqYd4moVRZNQAb5wS7AVFmIWgWoXQUIR8nsAGiV62YgjUgQaoUYIwJgaQYYXAc 4d0aodYbw0Qezh+AlXYpLnYqxqVoCADnw1ovz7Tv8SZu6QaFDsIcJFgd1XUks5cjAdAcIcyRwdAb Iawcazge7G6sAc0QxUAcz44bZyQaQd8WActtVBrl1OI8zxF4YfzWIdrZAeCIybCL1ewY5BSgAfAa 46ckwd5Z7j4e4UttQZyWwZ0iBgAbodIaK/Ey1tQaYcodQboqY+bXIgomofkKgeN49sZGThMSbmAl YddDjZFx2xmd6V4dwaIZ1vQlNcCV8QJQMBdNoagYYQoSKqNyIS4QYZAajRYbrkhgNtgToVWXQa02 9SoZAcdMyoQYr5o78MgdwmoUMUdEYewdRUwby1IaAToUYZsywc0o4XwZgVVEodwgbhI/ROIYsJIb yWrZbYYbxlp6m4IY6Xu+AfIVkyIZm/4cIYoaodpI4awVYV1HAXYUkmwc4eAcQgwZIYwaoTy4oVIV AZgXwXIWTnD/R7BZgaIowWRBweAfIsAqKIYgoZAUAToazMIXwaAW4X4ZoXVfIgRLIe1IgZ7Oocjd wXRFhDIcYcIdSnrbQfAe0lQW4ahkQcYZECraQeKhITAVgO6sAaproWpagdYU4TwXkw+b2b6bG4kB IbQZoaQZAT4WAawVoWoZASgS0Gy0wboXYWAY4UIWARoPYXQUAV+PSRc95owckDIZ54JHQbBgpC4R gatBbv9DwdoaN9QboX0JIXwYIaAUYUpy4TUp1RQf4ogewXQR4TwTQR7ygUYZS45gIXxlEa4Yh8YY ZqobKAYXDfgcQ2E+EZ4agbAVQLINAXQOoPQUgOYMmeYgwZwXYZYUYTgWgSYSIW/F4XAl4dIXYWbS 8i4Yk+0zVNthga6AYeImogwZoTgT4cCuYXAZvEwZ4VwpQe5CxGToQa5qodKigbgZSGgUQVQYSYoy YgXCwZ1baOAaIXQRAUIXwQYSgcQYwZITYM4KoaQaAXyM4Z0Kgc4VIPwRxkAZ4bAa4cqZM3kBRUDW RDoeKXga6+Idhz4eYfDeYdCsgapXobSLdxo0ZyQe4WgWAaaWodek4djneAIdEc1eIrPaAegd1Dgo oeAbNzIUwJQKAdobdV/XHMOpYXIYFQwTASIWYUoUwXjzGGBDIc1BdDwy4wwZVbYbkdYxCHybAaQW AY0Cj4IWoW+xazYdHFAdIdyPgcTzwb8QAcnf76wbIYaUoYobz1J1oTIbckSFAg2DQWwbFKTDgZcC YZbtogSYgeQVwVIYpTXr4dwlwdoc33lqYd/g4gUFgfYVIcAcYZS97Ti7oYoaIexyfEIV2i6rcBw0 YeZRgXuG3yUGhqWStfW2V3Ynohd3M1gowcAYIYYoX4Af4t4mrQKRAYcbgaQ1F5I3ESghF6n741Ij 94wnYbFqYVwgDhcb6fr9f8HhD+gr9fj8hEPiD+iT8fb9iT+iEZh8XfkWi0KhcFjUjkklk0nlEplU rlktl0vmExmUzmk1m03nE5nU7nk9n0/oE7i7ydjxcLLZjXX65ebudkXfT3fMUh0QfD6fL6fT4fb3 rD0e73eTysL3fb7fj1er2gsdgr7fT8i8ni9ofV1gr5fD5ucHjkdkl1uMKjFWd7yebndkMg1Bk77r L4er3vsafsVxkUzGNjcghmBhdnz2AkcNhlxx10iTucruZ6tXC0Px5XCSRLtbjbZaER7cYTRhD2uC 6bbTbThardYzYZaZXTFSihVysXjParcV6sXzjcDYdzodrWYrddDacbHT6hcrWajucLfergb9ofbT b7PbTmarWdjnaJvGmfKpGoVpkHUbhzmEXhrnSdh4GeZpsGeZZkHmw7dHAyR8oyeZrmwbBOlMdRxH OXhml0dx6HU4LJHWdRzHsdp5GuU5bmyZRqG2bpxLGehznKcZ5nidp6Hgex6nge5zmua5gkmSB3HB KRZl1JpoF+ZZdmsb5lMqeR1HicRmG+c5mmoaRfmgd0ZG6455nkeBwG4Zx7nseiMnacZwnEaZonqd b3GMaR8LAjJ0HWcp1nYdB6HWeR0mmcCQNSiDGHccx4nMa5unCZhmHKaJnmURJCnSZppRYe5qm0bB vnUdUcmlJpnGqXBlmMXxnGWZZtF+X5kQgbJwG2Z5nmEYZ0G8dRvGUZ5qFuW5qlqWRyGaZjGGUYRj laXxQGycRtGYc5wnoeZ6mYWRjHKa5wlsVltGKa5UlIXJSE+XB2nUdBoGGYh7HmeyMnWcJumkXBZX 2a1jGGcByHAhBnnMcBRl8V50nCchwmQapXlAW5dl8ZhlmgapjGGZRsGqZhyG+bB0nAdR0m2cRsl+ YBwGUZBsFuWZyl6XxaE4U5dGQWrKnadp2G6Z9vmKapdlKYRZFgY5KOjNpvmiZhkzseWBNybpiGEe hxHEbxaF2fGAUMppxHhgZoHAaZXGQy6q0og6Cn9Ip6q2rp4nlQh6ZkbB8ngeCEoUdx3Ved8hnkd5 3qcsR5ngdh2HEcB1mRpx4ngeUjnidZ0G+eh4rXwJ2IEUwyC8adpoQe+AMOdyvHsc+k4AehsG2anJ Hab5wG0ahnG+3JxmsaRtHyfPbnGbzNIyrZ8HIa5pnnKRxFkXR7HeeaEGschzFAZxknTw/THn4hi3 AbpsmqcRfF4YZkmQbJzHGa5xG2bXZUIOwdw8h0O4YcO0aI0ByjBGUPEcg6yMjqHoPIYQ2RnjqHIO dl44hbirF+JsS4thvDfHMKQU4yhyDiHeRke7gB2jgXIO8dgyxWChHkOcciHC9DuHsPZHY3RtjRGu YRvDiR/O/K0Vd5hlTguQHILYWQ+XHDnHQOguxWh9D1MkOE3DzB8jCFmMYerayIJ1HmO0dY5B7j0H sNUXozB2MNGkLQV42Bki9HSMgYw6xojZG6OQaqtBgOgHqNodY5irj4G6OUbY9C1CwFWMYaAzxujH GCNROo92HDWHeOtFw4IzDeHGo9Q43xtkZHMOscYvUslgTqXAfRkC1jzeY9MrhdislYK6v9yA7B8D 2HyPEdI7h9j4L2PUehDCKQ7mQVeNJkh2xhHGO0cI1huL8FWKccw4RzCmFMLyGw6xpnWTWowd49lL jxKoOR5LsnIP7SUOVRchR2jnHyXA+kQyIFoH6LgXY0hysOGqMsYjb3EEQGkLwWQtBLh+HqO0dw2B hDQGsOBCAzXODZGkHwVwaB2DzHQNegI83KkZQ+fcZYvxxjcGyM4XY0xxvwdeLoY4phPDLFoKUbos xZndf4Ngaczx5qfHGOiBgeRUBkZQMcXYqRbNmHOM4Zw1HLjuGcMwZo3kJLJX0NscwxBMiaGEJgSZ GRrjLGoL0YYukGjqFhT4ZY5BoCgGEI4bY5RsEIeYPsWgt1jjBGeMwY4vBiC7FIOcb46BwPFG8MYZ guhFiETmMMX4fg3jgFuL0XQvxZnmGkK0aw0BEi5EQL8awtHOCyGuNQagtRYDJO4OcRwjRWDAGAMt xg6pFDlK2PoaIshbDvHMOQZIshODbhmNQ54vxlDAHvL2fBGiLjYU2/wcQ31ODsHSOIi5FxxDOquM xupDRzDCGCOVHY3xwjaGKMcYgqRHB9TWOZ+41R5liIyOIcI5RwDemyN4cI3BqDPHq6AaYvBpjJFM K8ZotBWjOGAK+AQ7RsjBGknYekUxxDjU0I4VAakxjAGcMgWg2BijFf4OakQ9xZi0Gc+4bY8B2jpH pOUbwyxsjMFUK8jI8hxDlMSOkbl8hfjTF6s4ZCOhmO2IQPgr1khqFqHsLkXQ0RfUyHK8YbYzhtDo yCOsb442LjcFUIANI4Rei5GYKcW0PxrjWtSMoXouBujqGsOIdlhz+i+FMloaQ3xaC2F8qEbI8B3D nfeMIrA91LjvHoO0d4wxLiUGILIUI6BjjCHUmR5o+LnkZIW59Cw8B6ZtHJAMoo7h1jx1QPAdEOh4 DzIuPNRY9h40iHiPEemuR5qvMvPYfBHnpFnKyPwrQ/StGQQENYY42B2jlHeRfWg8RuDFGGUYcI7h mjRX+m8c45xzDeGu7YjhDCLt2imYdcw8NGJHmNOVJA9jCDwHKOUfA8h4qEHlGoeo2BxjUKaO1tT3 yDjvT+VpwyMsllX1vCsd46cBjyMhsSeuxB9Dec4PEdA5h03rHiOAcRcJiUiu3yMwnJLtkFyYPMhb fiFvdHePnXJWx77ELkRbTpEKhsNG0NMaozVwjIGmzFPNPBrDKHKNpcY1Bz8sIaMYVYmxtjDFrvUe o4hju+48NUVQrRqC7FsNYcK2RqC5lehvgY7h4ixFUMcYoxBmjOGOLMvQ9yED0cuLwRgib1C8GkJY SI5BfXLEIJUYIghDzIIQNtSF/BtDVF8LkVQnBaC4FuMoW4rhjDTGcNNyCQ1DjpG+OwZ4sBcDvn+O MaWAkXjnGCMUfk9SMjEGiLMd48EDrgVkMwdI5h3DAF6NIbo3Byi+F6NNH44hpDFGToUeHsxd53y+ Na8AlxBj6TXzf7BJRojiGWJoVoghcihEuNkag4IBjvGlS62g0Ryjh8VmB0w9eKC3EIH4ZQqBQUPG 2NIWYvxtDnhlhJhMhjBLBLBMBLg2A/BUgwtGB2CELrB0BYhWBimTBoBvEdjKuYI1hbhghunOBxBo hlhvhiM4hNhVBshcBjjKurhbBJBbA8BShcBIhhhQhJBfDtBoBnBtiqJjB4l9BwhvBrBukABwB8jJ t6h5FwhfhbhDA4h8k3iMlqhmvTBxhQBgBGhHhXBBhqhkM4BZBiPiBnBYBYBkBlhkhmK0hUB0JtEr hrHRB5BzBrBphoBYBVOYE7vsw8iICyB3hvB0hsh0ByhxMmIrCuirtutGB5IAixiwtfiGhthghfh1 vgoYB1BXBnhjqeByhml2PlBnhThTBhBbhRCOm7lyh7hhhgBqh0pgiwh9CMiLh6O0NGh3QjI1B7RF GkB6tGCMtVB1Brl+ByGlFLhwh6h3OCB6NOCDouDEB5RBHjBrBtjGCEByFQhehNBHtEk8BtBth5kX BeBmBUBUhkhLOPBrN7IDKrg8A5BMBqhqHhvNNbFhhxjIG/h4BrhdBcCxGvFKp9C0Q9G8B8jEE/pe B9B7BtByhqRAhuiiB3N1EijDp7B4h3lDpUDJN6pnpXh+Bqh4N7izwhBrimtGB0mYhphqOAozLdNi B2vbB7sBiEDTD2ByGkh3BpBpEchqF1hgBkBuqoBYhxhyhkB1h2o/v0hZBkIVh5hnhOBQEih3BTBg hHhfBqBYlthPB7EgCMtCB1BoBlhcx0BxvFNmh4CGB9h0B7B7hVoXBdFjBvxOB4ncRNhnBzBolQhu hhhzB3hxnnhthYBFBNJshzBXhXBdngh0iMkBB9uGh5hxlihtkpB1piDfhoh2BzB0CMh3myhsBshk HvB2I9hmNCB2BoBkhth2FHBbhaFThnBoNuhwHLkZB2B6hzBphpkkh7hmqHB6izifiLhqBThVhYAv AyBkBhhXBNhehChjhohdheBVBQhmBeBlA8g5hNBmqzBlLGHMj2h0jcBnhwtah7hbhyopS0BGBkn2 TYBthuBwBghiBvBfBgBXBNBCBlBrheBTBdBOybBjCEHJB5BHhDBTo5BiLpLABhwuhbMtI9hkyhhh h1B1hchvhvBttSizh9huBcheEohwBKg+guhQBeBFBHMxzyGHiIPdh2hlBihpE1h3BuBrhpGaByru JGBdTLBaJSBHBHhMBgBNBYhlhLBOBu0NBgPxBXQWhfhkhaBMA3AqlOhnBchahlGkx+CHhxBuhwBj hahnhpBchiBfkPBfB0B0hXn3JQqCiHhrBWBXhihcRQhsBag4BNgwBlBghbhSwEhtBoBtBMBJBWBU BRhdldBhBzP2hzhuFEEthlyhg4BmU+DETeiJBqBVheheg8BBhphShUBdhLhFhyJFBmBnhiB1xuBU g9BJE2hxhtH9CFk4B2hpMQqRB6Bqp5JiBPBuBvhyi1nukfBqJtBmBnBxhlBl1RhahPhdBDBjBshe CpB7h1nzhOhM0FBkhphWhVhdhjBgBaOdhuN7B6uHB6hxi1nfB4hfBzJDCGkvh2Irh7U1hXhwBrBn BdVKHQU0q8LmhlBhhrRWB5JSBoB0ITiLh3i9hwJGBrnPhNBrFpBkhhB0hqBxCEBtBbBcBnsGOfBg BVhghMlyh5BhhePyhuzDiIRBBsFcBchyMg00BlFFBQhvBwBzy0CMhzhnhoyBB5hyGZBRBfhF2YBu BZhQBFh2hupJhjj91f0JoUiDsBy0CwBvqRBTHgh5pX1JB/I3hzlehkF9hqBrhYBZoVh40KhoB1h4 ByB3huBvB6tcHINYCJNuh5nMhyNVB4juTyO7Brh3mkpiDvB4BxSWB1huBxVShxNdh0hThMg9hZhk hPBUhhhPmkh0lqhlB3TuwKBskXB2sdkkiFh4nmCctesZuIC0BiBghvmktG3MFFB5os25ish2CyjJ hzT2Qni2CziGiuorolCRuVi9CGi3DGB+jhCOiJNPDROTipP5CGC9jKXiG8iLDTCSCPuZi5XmigBz khhWjphtBeBlhdA9BDBshZBahKA3AoBYKvCEB6h2B2rHBMBnzSy61ShtKHGHBwBkhjhehlPZpqhf IpSfhyhczLBYhZRL0vi6nmBghZhOBbBkBQBpBuGRBVBMhlhYhdhVhUYAmYiMhpBVBahjBaBnhchu BpBhNuhrSOhVCBB1nHBohcBjGZByBphSBUVNBUvECDhxGVBehJBOvdh3BtRAFXh5VoBwh2B1Bxhd BiBpBKhhhaBiIphPhupSN1BVhcBYhwkIhohWhdB2htBuuSSAYwiYB1CwhghtW0BshvE+F2BjhkBe A8A+hxK/iECxh3hmhchbBlBVBbtvYjhxEYMBobY1Bghkhot+BrERhRhrhtYAh0BXBuXthohkiM2H hqw4S6DzhRhhBKBthmBixnByXdB/5OhlHSB0BlQLPthwBWyTBEr1htmkBlzWB4JThchDBCheBDhF PXuzB/j/nyhkBfMBk4s8Cit1CiB1B3BrhbBihahUBghuOMhsFXtmB3BfhuFOBwhzhbBGBTDyllZs HmmA4xZyCV3fFxm3Paodh6u5h7nDphxlB/wjB7htBYhgEyhoRcm3h1Syi9B7B+JiK8k6myUJh8CG h6CziCDOSYNi3bjLr6h4aE4biNJN0yBwnzh2NGhxnMhpIDheBanZKRNHCQK6kdXKCMlykwj9nBXb DTCGh/CziGHmNaCwE3ownQIdpCncB0B2GczOnLJGP5CG5y6iai6jaj6kak6lal6mam6nCYOTNyiQ uTiPjCroCJCPOS6qrtictyuS6raoapaojPasCVYwCTORi2h+kNC4RS63DK6paq6zasC2iqDNOQB7 CCXhiF6XtxiFp6is3jCQCFa9h+21JdXmawCdi9RdlLn/BuGNhihOhO4Yy6hNhMB4TatdkZCxiEXV h7hjBqBlEb1fmdBvyEB0h0B3hqDjJ/zLox3Vh2ByB4DJB7huBhhgxjGkhkhlEDhwhf0vNXnRk3kj NbTGBlhtpzQ8B/0Lliy3Bk1qlslkh1oyh6BxhphsBhhPBMBpwl6JiSBshwhsnLkGhuhzhthiBlti B9iEV0B2hkwSBzr8BrhjBuKXhxheBHBIBhhMBKwjB6iEBuBlhrBa4mhwXZMwB1yFBxh1J5jKwhhz hdBel4vykgBzb5BvE5pPByh4nXhaBgBIhHWzhthtqvlQBrFf4zBwBrmIhyBfhvSEOPB36LhVBEhS BYBTBjk7Z4ieCKOKhtBln9mZhqQ4mQ7bhhBaBCA+Bt6PhqhIhIhzHlSYCFNrkRkXFwhsBWhUBNrP hrhNBJhZBwI+mBByh1BthmhuwfB5BmhUBTB2nMheBJBBBuBiBgBuhrH+i1hiyTBiIfEt20MtRd7l kehUBUBdFdBsE5JLDJn8hzhrK/BfhIhH84hGJ2ZRPEl8h1EhBtBkBtYPhctkCED5BzhPBPLSBphs hsFrF/h7BzBsBvB3SgFJiDhthTBWOuhjBlhohjlZBshXhohmhgqVxSiEBmhkhuhQBNBdPUlWEtnk hqhpBkhgNCh3huhmHhhahasvBuBb85YtBShoBaBhn5BcBshv8WRAkthqo/4tBUhLhXhKBLMYB42q hzy9hvBskGSgB4h2DEB2h4hjBOBOBoBcrWhOBFhvBZBWE8JGB1DEY/hxBrBvBohtHkhYhLhSFhhy 2ZhyVWFrKCJ1BxW1B5BjhYhS4PhQBvhUBVklB1EzBmO3H6BxhvhghqhnnF3MiDk6h8BeFbGTBo9o Bwi9B9Buhqj7P2BukcBohXBVmahete7wBwRAIABttvBal0B7DJdRFlBThSPf9r2GheYjBwimpfCv KSBlVmjELFhq7eU3BmhfhcBthsjMPEjuhZBNhQdgdfBXBfGU5tByZ+CChzBtoLBrhzxJlmBZBUBn hfhXB1pIsahsBfhmBfBhhqBgh2khDyByBpOw8Mk/HTWqrgh1nkhthql+I/hgJUB1Bw0+fOhpBXg/ A5BShNg7B1/TsL5k8Gr8zTHInbHHB1hgBZhTjihutjq82OoIxEpNoUQfB3hfhKBMBuNLh0EJt5GY FOFAByBvB2hyBejuh1oIxknIE1hahUhdr8B1+dm9IIuARkkBIrnFmcFriRCRtc7aJiOgyEzadiCD iAPJ4vZwuF0vl8vt9Pl9P1+vx+PuHP1/P+LRd7vV5P6HO5uuVxNdvOp4Ot5vN7P6VRd4PN4OpyOC IvuEPqIROKxZ8PV8vV4vd9Pd8T16Ph5vKHvyHv140d2vJ2SqOSqlRKHVKL1mtVuuV2L1dUqRgrBV r5zuVytlqtOYOZuM9vO9zu9tsBftplMNxtNlOhqNRvs5qLNbqtxORwxdruRmp9hI9uSFiKpVshgt WbudzO1hr9kNlpMt0OB0N1lNprrtgLlFoVgqVItFII1zM9rLZhq9itBdtFbLhfsVTux5OhotdlV6 vVKscrnc/odHpdPqdXrdfo1LQtFUpxbOl0O9sthxuhyt1osdhO91Ox4ul3PJ1u9xtBmsNOJNyM5k NRdGCbBpmsi5vmkZRqGqYRqHEZZYFoS5blET6IH4c5znYVhVGQYxgGIcZum0cxvnCcxsnKYZMk2W o/j0bpjGCbpelwZhRFoZ5jGWbZbl0cJlGQmx9GWb5guxIsjSPJEkyVJauqkaJll4aZcl4fJ8H0ex 6nud52noeJ3nhLB4oih6JHyeh6HGaJnnkcpwnGVhXzYdaLnOZ5ol8RhEnEcZrGicBkmOZBfImdR1 Heb5vnOcJvnUcpxnMcBtmieh4J8dB2GoWRYFuQY/G2Y5fHMaxpHWbRyHmc50Hsdp3Ioph7HdJlZV nWla1tW8lqSfR6HqiaqwoqSJqWm6Jq8majHmiB9qVZh+VxZ9oWjaVp2patrWvbFs21bduW7b1v3B cNxXHcly3Nc90XTdV13Zdt3XfeF43ledpoCACmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKMTE0 MTEKZW5kb2JqCjE0IDAgb2JqCjw8Ci9MZW5ndGggMTUgMCBSCj4+CnN0cmVhbQr///+e1jF7eOWD iFTeELtd5lD9p/If/Hr+SXU+PqU2q5gwSm9hxehHSXGbJ4FWhWingg+ZoQsUn1WK3pMvFD7IRIk4 pk4g7ZeSib8T30R7hsaLIGiXNAjsvuaA7vq/tj9I7uaXD9QuoV3utTwyMcP5vORhVBlqQddQwcZL gH2LyWxyYHtGjx2jfdLgrwOkqMCIChSidVZ6xhdAEZi9nWIqD8KmVlHD+c6W2n2ZfiZaBzFvqafF I23dZH92IRzYTCya8oLrtXy6S1Y45dRfP9uQroU4dKilUQwkxy5BoHptOm3wJiJs4G7DGFOXd5Nz CEL4QLah5QiuCs/cS3BXuarEqtHnFrFV2sqpckI95Up/3os1gHE9LnsNCsd9YoAoJir5DkGrZBx1 DY63S3MCylKOANL/PgF7TAxCym7D8pXu7KMwmAhMDRbaxWFOyCyhVixzVmt10beBFILv2HWFx2Eo 9/kxRAdHHs2obZbUDu0BgkNs9xUkeCmmZwIc7cl9FcB3RwV/jiNNNpHjC5/QDCEUeRgpnZFTRPlV YOYe3vzfVkPk1tEIIweZBxI51x9a65hzFTYEaHv9vdzj3LrgvBEjoef0qgv8RBIOfeku19XGS+r8 UFN3ThFTMu0OEqogNUsHKfYSJTolNLcOYo/kKdrPJSsjnXk08ash/73MH/IYJxwOOkJIX3b/btmP UwJqIiiVRcUOere5m7d2aNdpgP6FjjjH15g+1gYXZlka0HxDZcIIdDzALdh3pEFODcFMk1CFWyce mf4lsWR/zDT8D5q+GA772DzUT+AVne7X6oIncN1OjndMsyiwMvTlLwOA7RuO6fPKvkOr1OGaq8sd 0jz6IctybX+aHrKPBOGShM+uErii3XfliUvHJPeTQcrPPOuarlgaSHfM2Huta/98GRI1vO+sonn4 aZ3v/N+5zBulZsr9gBN1Tevw+lbwd3ACrCzyWc9rUTgJQTXo+wEEoGjOnunhEzbMBDEj9KiT9lXA 6K6PVADIXkL9Rj3/S95nGXwKZW5kc3RyZWFtCmVuZG9iagoxNSAwIG9iago3NjgKZW5kb2JqCnhy ZWYKMCAxNgowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDAwMTAgMDAwMDAgbiAKMDAwMDAwMDE4 NSAwMDAwMCBuIAowMDAwMDAwMjM0IDAwMDAwIG4gCjAwMDAwMDAyOTMgMDAwMDAgbiAKMDAwMDAw MDQ5NyAwMDAwMCBuIAowMDAwMDAwNTgwIDAwMDAwIG4gCjAwMDAwMDA1OTggMDAwMDAgbiAKMDAw MDAwMDYzNiAwMDAwMCBuIAowMDAwMDAwNzQ0IDAwMDAwIG4gCjAwMDAwMTA2MzYgMDAwMDAgbiAK MDAwMDAxMDY1NyAwMDAwMCBuIAowMDAwMDEwNzA4IDAwMDAwIG4gCjAwMDAwMjIyNTggMDAwMDAg biAKMDAwMDAyMjI4MCAwMDAwMCBuIAowMDAwMDIzMTAzIDAwMDAwIG4gCnRyYWlsZXIKPDwKL1Np emUgMTYKL0luZm8gMSAwIFIKL1Jvb3QgMiAwIFIKPj4Kc3RhcnR4cmVmCjIzMTIzCiUlRU9GCg== --------------000501010201020303000700-- From nfsv4-bounces@ietf.org Mon Jul 09 12:10:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7vob-0002gX-I6; Mon, 09 Jul 2007 12:10:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7voZ-0002gO-Vo for nfsv4@ietf.org; Mon, 09 Jul 2007 12:10:19 -0400 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7voV-0003zz-Kx for nfsv4@ietf.org; Mon, 09 Jul 2007 12:10:19 -0400 Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1I7voT-0001qT-Er; Mon, 09 Jul 2007 18:10:13 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx3.uio.no) by mail-mx3.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1I7voT-0005pe-4f; Mon, 09 Jul 2007 18:10:13 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx3.uio.no with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1I7voS-0005pL-OP; Mon, 09 Jul 2007 18:10:13 +0200 Subject: Re: [nfsv4] layout stateids and pNFS callbacks From: Trond Myklebust To: Black_David@emc.com In-Reply-To: References: <46827329.1000508@panasas.com> <4162.47852.qm@web31810.mail.mud.yahoo.com> Content-Type: text/plain Date: Mon, 09 Jul 2007 12:10:10 -0400 Message-Id: <1183997410.6468.13.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.139) X-UiO-Scanned: 706A2652B7836CC6736E4BE28925070D93C5E587 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 98 total 2777274 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: email2mre-ietf@yahoo.com, nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Sun, 2007-07-08 at 21:16 -0400, Black_David@emc.com wrote: > As part of doing this, can we use stateids instead of sessions > to sort out pNFS race conditions? This approach requires the > server to pass the stateid in callbacks so the client can order > the callback wrt the sequence being tracked by the seqid part. stateids don't suffice to sort out all the possible race conditions. See the problems that we have in v4.0 with delegations being recalled by the server before the client has processed the results of the OPEN call. Cheers Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 09 13:05:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wgP-0006bD-H3; Mon, 09 Jul 2007 13:05:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wgN-0006XH-QY for nfsv4@ietf.org; Mon, 09 Jul 2007 13:05:56 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7wg6-0005g8-9r for nfsv4@ietf.org; Mon, 09 Jul 2007 13:05:55 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l69H5Kf3023467; Mon, 9 Jul 2007 13:05:21 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l69H54A4010551; Mon, 9 Jul 2007 13:05:19 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:05:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] layout stateids and pNFS callbacks Date: Mon, 9 Jul 2007 13:05:06 -0400 Message-ID: In-Reply-To: <1183997410.6468.13.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] layout stateids and pNFS callbacks Thread-Index: AcfCQ6VMbeyEdCmySOiyoPO+I+lomQABtwrQ References: <46827329.1000508@panasas.com> <4162.47852.qm@web31810.mail.mud.yahoo.com> <1183997410.6468.13.camel@heimdal.trondhjem.org> To: X-OriginalArrivalTime: 09 Jul 2007 17:05:07.0848 (UTC) FILETIME=[4D4B8880:01C7C24B] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Trond, > On Sun, 2007-07-08 at 21:16 -0400, Black_David@emc.com wrote: > > As part of doing this, can we use stateids instead of sessions > > to sort out pNFS race conditions? This approach requires the > > server to pass the stateid in callbacks so the client can order > > the callback wrt the sequence being tracked by the seqid part. >=20 > stateids don't suffice to sort out all the possible race conditions. See > the problems that we have in v4.0 with delegations being recalled by the > server before the client has processed the results of the OPEN call. That depends on the details of how they're used. We have experience (i.e., running code) with FMP for MPFS that a single sequence count *that is included in all the relevant operations, including callbacks* is sufficient to sort this out if one pays close attention to all the details. The class of race you describe is handled at the client by observing that the callback carries seqid "n", but the client hasn't processed the reply to operation "n", and hence the client holds the callback until operation "n" (the OPEN) is processed. OTOH, if the callback doesn't carry a seqid, the game's over ... and the fix is not to make that design mistake ;-). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 09 13:26:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7x0B-0004i7-7l; Mon, 09 Jul 2007 13:26:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7x0A-0004f1-D2 for nfsv4@ietf.org; Mon, 09 Jul 2007 13:26:22 -0400 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7x04-0006YV-3d for nfsv4@ietf.org; Mon, 09 Jul 2007 13:26:22 -0400 Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1I7wzX-0000Sn-HW; Mon, 09 Jul 2007 19:25:43 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx4.uio.no) by mail-mx4.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1I7wzX-0002DM-8H; Mon, 09 Jul 2007 19:25:43 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx4.uio.no with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1I7wzW-0002D0-SM; Mon, 09 Jul 2007 19:25:43 +0200 Subject: RE: [nfsv4] layout stateids and pNFS callbacks From: Trond Myklebust To: Black_David@emc.com In-Reply-To: References: <46827329.1000508@panasas.com> <4162.47852.qm@web31810.mail.mud.yahoo.com> <1183997410.6468.13.camel@heimdal.trondhjem.org> Content-Type: text/plain Date: Mon, 09 Jul 2007 13:22:11 -0400 Message-Id: <1184001731.6468.44.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.062) X-UiO-Scanned: 7C3A529B803371010917C3CAC142A1526EB284A0 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 191 total 2777919 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Mon, 2007-07-09 at 13:05 -0400, Black_David@emc.com wrote: > That depends on the details of how they're used. We have experience > (i.e., running code) with FMP for MPFS that a single sequence count > *that is included in all the relevant operations, including callbacks* > is sufficient to sort this out if one pays close attention to all the > details. > > The class of race you describe is handled at the client by observing > that the callback carries seqid "n", but the client hasn't processed > the reply to operation "n", and hence the client holds the callback > until operation "n" (the OPEN) is processed. OTOH, if the callback > doesn't carry a seqid, the game's over ... and the fix is not to make > that design mistake ;-). OK. I see where you're coming from now. Basically you are extending the v4.0 sequencing scheme to work with callbacks? I suppose that can work, but it does seem a tad inelegant. Why do you want an alternative to sessions? Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 09 14:31:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7y1I-0000QH-Ro; Mon, 09 Jul 2007 14:31:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7y1H-0000Ph-Ln for nfsv4@ietf.org; Mon, 09 Jul 2007 14:31:35 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7y1H-0001tk-CD for nfsv4@ietf.org; Mon, 09 Jul 2007 14:31:35 -0400 X-IronPort-AV: E=Sophos;i="4.16,517,1175497200"; d="scan'208";a="80286046" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 09 Jul 2007 11:31:23 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l69IVJtl027011; Mon, 9 Jul 2007 11:31:22 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 11:31:10 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 11:31:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] layout stateids and pNFS callbacks Date: Mon, 9 Jul 2007 14:31:08 -0400 Message-ID: In-Reply-To: <1184001731.6468.44.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] layout stateids and pNFS callbacks Thread-Index: AcfCTouXazXRgrJ2T6+oXS101KU1ewAB3TJw From: "Noveck, Dave" To: "Trond Myklebust" , X-OriginalArrivalTime: 09 Jul 2007 18:31:09.0289 (UTC) FILETIME=[51C0ED90:01C7C257] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I'm getting confused here. Originally, there was a=20 proposal to add stateid's to to layouts. Now it seems that something entirely different is being proposed. It sounds like David Is proposing a single global (for every pair of client and meta-data server) sequence id. Is that in fact the case? It doesn't sound like the fact that stateid's have sequence values meets his requirement to have a "a single sequence count *that is=20 included in all the relevant operations, including callbacks*" at least as part as the "single" part. With stateid's you still have the same issue with delegation recall that Trond points out. =20 -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Monday, July 09, 2007 1:22 PM To: Black_David@emc.com Cc: nfsv4@ietf.org Subject: RE: [nfsv4] layout stateids and pNFS callbacks On Mon, 2007-07-09 at 13:05 -0400, Black_David@emc.com wrote: > That depends on the details of how they're used. We have experience > (i.e., running code) with FMP for MPFS that a single sequence count > *that is included in all the relevant operations, including callbacks* > is sufficient to sort this out if one pays close attention to all the > details. >=20 > The class of race you describe is handled at the client by observing > that the callback carries seqid "n", but the client hasn't processed > the reply to operation "n", and hence the client holds the callback > until operation "n" (the OPEN) is processed. OTOH, if the callback > doesn't carry a seqid, the game's over ... and the fix is not to make > that design mistake ;-). OK. I see where you're coming from now. Basically you are extending the v4.0 sequencing scheme to work with callbacks? I suppose that can work, but it does seem a tad inelegant. Why do you want an alternative to sessions? Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 09 14:54:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yN6-0003QO-3R; Mon, 09 Jul 2007 14:54:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yN4-0003QB-L3 for nfsv4@ietf.org; Mon, 09 Jul 2007 14:54:06 -0400 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7yN4-0002Tm-5w for nfsv4@ietf.org; Mon, 09 Jul 2007 14:54:06 -0400 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1I7yMi-0000oi-Mp; Mon, 09 Jul 2007 20:53:44 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx2.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1I7yMi-00025T-6q; Mon, 09 Jul 2007 20:53:44 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx2.uio.no with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1I7yMh-00025O-Qy; Mon, 09 Jul 2007 20:53:44 +0200 Subject: RE: [nfsv4] layout stateids and pNFS callbacks From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Mon, 09 Jul 2007 14:53:42 -0400 Message-Id: <1184007222.6468.50.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.065) X-UiO-Scanned: 8C74926F1897083BEE5F6EAE8FCC9515D44995D7 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 537 total 2778752 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Black_David@emc.com, nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Mon, 2007-07-09 at 14:31 -0400, Noveck, Dave wrote: > I'm getting confused here. Originally, there was a > proposal to add stateid's to to layouts. Now it seems > that something entirely different is being proposed. > > It sounds like David Is proposing a single global > (for every pair of client and meta-data server) sequence > id. Is that in fact the case? It doesn't sound like > the fact that stateid's have sequence values meets his > requirement to have a "a single sequence count *that is > included in all the relevant operations, including callbacks*" > at least as part as the "single" part. With stateid's > you still have the same issue with delegation recall > that Trond points out. I believe that David is proposing that the client supply a sequence id (presumably modelled on the scheme used by LOCK in the v4.0 spec) in the GETLAYOUT call, and that the server then uses that sequence id as part of the stateid. That way the client always knows whether or not the stateid refers to an outstanding call or a completed call. David is that correct? Trond > -----Original Message----- > From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] > Sent: Monday, July 09, 2007 1:22 PM > To: Black_David@emc.com > Cc: nfsv4@ietf.org > Subject: RE: [nfsv4] layout stateids and pNFS callbacks > > > On Mon, 2007-07-09 at 13:05 -0400, Black_David@emc.com wrote: > > That depends on the details of how they're used. We have experience > > (i.e., running code) with FMP for MPFS that a single sequence count > > *that is included in all the relevant operations, including callbacks* > > is sufficient to sort this out if one pays close attention to all the > > details. > > > > The class of race you describe is handled at the client by observing > > that the callback carries seqid "n", but the client hasn't processed > > the reply to operation "n", and hence the client holds the callback > > until operation "n" (the OPEN) is processed. OTOH, if the callback > > doesn't carry a seqid, the game's over ... and the fix is not to make > > that design mistake ;-). > > OK. I see where you're coming from now. Basically you are extending the > v4.0 sequencing scheme to work with callbacks? I suppose that can work, > but it does seem a tad inelegant. > > Why do you want an alternative to sessions? > > Trond > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 09 16:39:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8018-0007WW-0n; Mon, 09 Jul 2007 16:39:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8016-0007L2-36 for nfsv4@ietf.org; Mon, 09 Jul 2007 16:39:32 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8015-0001Q9-PS for nfsv4@ietf.org; Mon, 09 Jul 2007 16:39:32 -0400 X-IronPort-AV: E=Sophos;i="4.16,518,1175497200"; d="scan'208";a="80331048" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 09 Jul 2007 13:39:06 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l69Kd2S0014622; Mon, 9 Jul 2007 13:39:06 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:39:02 -0700 Received: from exsvl01.hq.netapp.com ([10.56.8.45]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:39:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Re: Fall 2007 NFSv4.1 CITI sponsored Bakeathon date query Date: Mon, 9 Jul 2007 13:39:00 -0700 Message-ID: <7619F3097FAB384287CF636FF92D0CA10A02109A@exsvl01.hq.netapp.com> In-Reply-To: <4691C237.6020808@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Re: Fall 2007 NFSv4.1 CITI sponsored Bakeathon date query Thread-Index: AcfB50EuAdYqcRhcTn23GxfyeCZADgAga5HA References: <89c397150707031130n35351248re5d8b7a10571ad16@mail.gmail.com><89c397150707051002k4a7f4cd8te738d6e90144767a@mail.gmail.com> <4691C237.6020808@panasas.com> From: "Iyer, Rahul" To: "Benny Halevy" , "William A. \(Andy\) Adamson" X-OriginalArrivalTime: 09 Jul 2007 20:39:01.0822 (UTC) FILETIME=[2EF08DE0:01C7C269] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: nfsv4 , NFSv4 , William Brown X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Apologies for the delayed response. Netapp had a shutdown all of last week. Nay! I will be out of town this week. I'm hoping to fly out to India on the 18th.=20 Regards Rahul =20 > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com]=20 > Sent: Sunday, July 08, 2007 10:06 PM > To: William A. (Andy) Adamson > Cc: nfsv4; NFSv4; William Brown > Subject: [nfsv4] Re: Fall 2007 NFSv4.1 CITI sponsored=20 > Bakeathon date query >=20 > Yay :) >=20 > Benny >=20 > William A. (Andy) Adamson wrote: > > We had a reported conflict with the proposed first week in October.=20 > > Will the third week in October work? > >=20 > > CITI NFSv4.1 bakeathon proposed date > > October, Monday 10/15/07 through Friday 10/19/07 > >=20 > > Comments please! (Yay or Nay...) > >=20 > > -->Andy > >=20 > >=20 > > On 7/3/07, William A. (Andy) Adamson wrote: > >> We had a successful bakeathon in Austin - thanks to Sun=20 > for sponsoring! > >> > >> CITI will once again host a fall bakeathon, for NFSv4.1=20 > implementations. > >> > >> We propose the first week of October - Monday 10/01/07 through=20 > >> Friday 10/5/07. > >> Is this an agreeable week? > >> > >> -->Andy > >> > >> On 7/3/07, William Brown < wilbrown@us.ibm.com> wrote: > >>> Hope things are going well in Michigan. We're really tire of hte=20 > >>> rain in Texas... > >>> > >>> When you were here for the bakeoff, you mentioned there=20 > may be a NFS 4.1bakeoff at CITI. When were you thinking this may be? > >>> > >>> Bill > >>> > >> > >=20 > >=20 > >=20 > ---------------------------------------------------------------------- > > -- > >=20 > > _______________________________________________ > > NFSv4 mailing list > > NFSv4@linux-nfs.org > > http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 >=20 >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 09 23:54:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I86nV-0004oe-Rn; Mon, 09 Jul 2007 23:53:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I86nU-0004oZ-Bs for nfsv4@ietf.org; Mon, 09 Jul 2007 23:53:56 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I86nF-0000jd-2S for nfsv4@ietf.org; Mon, 09 Jul 2007 23:53:56 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6A3rGTh005233 for ; Tue, 10 Jul 2007 03:53:16 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKY00G012N6AL00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 09 Jul 2007 21:53:16 -0600 (MDT) Received: from [192.168.0.3] (adsl-71-145-184-131.dsl.austtx.sbcglobal.net [71.145.184.131]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKY00D3P2SQKZ10@mail-amer.sun.com> for nfsv4@ietf.org; Mon, 09 Jul 2007 21:53:16 -0600 (MDT) Date: Mon, 09 Jul 2007 22:53:19 -0500 From: Spencer Shepler To: nfsv4@ietf.org Message-id: <94967674-4D00-40F4-8D39-E64813F7C6BA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [nfsv4] Draft-12 is coming X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I submitted draft-12 today for publication. You can find an early copy at the usual location: www.nfsv4-editor.org This draft includes updates to the pNFS sections based on the review comments that were received along with a few sessions tweaks. The html-ized diff is available on the site as well. We seemed to have come to a consensus on the proposed changes for the stateids in layouts and the handling of deviceid mapping. I will be working to make changes to the specification to reflect Mike's proposals with the intent of submitting draft-13 the week of the IETF meeting. I will be providing additional detail of the changes on the WG alias and review them at the IETF meeting to assist in any last minute changes. Thanks, Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 10 00:00:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I86uB-0000b4-Tc; Tue, 10 Jul 2007 00:00:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I86uA-0000T8-CZ for nfsv4@ietf.org; Tue, 10 Jul 2007 00:00:50 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I86u6-0006X3-1U for nfsv4@ietf.org; Tue, 10 Jul 2007 00:00:50 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6A40jx2020750 for ; Tue, 10 Jul 2007 04:00:45 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKY00I0134BUH00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 09 Jul 2007 22:00:45 -0600 (MDT) Received: from [192.168.0.3] (adsl-71-145-184-131.dsl.austtx.sbcglobal.net [71.145.184.131]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKY00D5V358KZ10@mail-amer.sun.com> for nfsv4@ietf.org; Mon, 09 Jul 2007 22:00:45 -0600 (MDT) Date: Mon, 09 Jul 2007 23:00:49 -0500 From: Spencer Shepler To: nfsv4@ietf.org Message-id: <1E6DD7E5-CFC3-43F6-A2B7-945291B0685A@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [nfsv4] agenda for Chicago meeting X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org If anyone has agenda items to add for the Chicago meeting, please let me know. Otherwise, this is our current agenda: Intro/Blue Sheets/Note Well (Shepler) (3 minutes) Requirements for Federated File Systems (Ellard) (15 minutes) [draft-ellard-federated-fs-01.txt] Using DNS SRV to Specify a Global File Name Space with NFS version 4 (Ellard) (15 minutes) [draft-everhart-nfsv4-namespace-via-dns-srv-01.txt] Review of changes to NFSv4.1 I-D and open issues (Shepler/Eisler/ Noveck) (45 minutes) Wrapup (Shepler) (2 minutes) _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 10 03:55:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8AYr-000115-TE; Tue, 10 Jul 2007 03:55:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8AYq-0000zi-Ku for nfsv4@ietf.org; Tue, 10 Jul 2007 03:55:04 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8AYm-0002wC-8B for nfsv4@ietf.org; Tue, 10 Jul 2007 03:55:04 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6A7skBj017466; Tue, 10 Jul 2007 03:54:46 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 10 Jul 2007 03:54:46 -0400 Received: from [192.168.0.140] ([172.17.28.123]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 03:54:45 -0400 Message-ID: <46933B43.50702@panasas.com> Date: Tue, 10 Jul 2007 10:54:43 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Trond Myklebust , "Noveck, Dave" , Black_David@emc.com Subject: Re: [nfsv4] layout stateids and pNFS callbacks References: <1184007222.6468.50.camel@heimdal.trondhjem.org> In-Reply-To: <1184007222.6468.50.camel@heimdal.trondhjem.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2007 07:54:45.0791 (UTC) FILETIME=[950742F0:01C7C2C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Trond Myklebust wrote: > On Mon, 2007-07-09 at 14:31 -0400, Noveck, Dave wrote: >> I'm getting confused here. Originally, there was a >> proposal to add stateid's to to layouts. Now it seems >> that something entirely different is being proposed. >> >> It sounds like David Is proposing a single global >> (for every pair of client and meta-data server) sequence >> id. Is that in fact the case? It doesn't sound like >> the fact that stateid's have sequence values meets his >> requirement to have a "a single sequence count *that is >> included in all the relevant operations, including callbacks*" >> at least as part as the "single" part. With stateid's >> you still have the same issue with delegation recall >> that Trond points out. > > I believe that David is proposing that the client supply a sequence id > (presumably modelled on the scheme used by LOCK in the v4.0 spec) in the > GETLAYOUT call, and that the server then uses that sequence id as part > of the stateid. That way the client always knows whether or not the > stateid refers to an outstanding call or a completed call. David is that > correct? I won't speak for David, but what I had in mind is a layout stateid per that's incremented every time the layout changes, i.e. on each LAYOUTGET and each LAYOUTRETURN. On CB_LAYOUTRECALL, the server sends the last stateid it knows about for this file and the client must wait on every outstanding LAYOUTGET and LAYOUTRETURN operation until it gets this stateid back before starting to return layouts for this recall. Any further LAYOUTGETs should be rejected by the server if they conflict with the recall, otherwise they can be served. The recall is done either by returning a NOMATCHINGLAYOUT error to CB_LAYOUTRECALL or by a respective LAYOUTRETURN. Again, I propose to make this explicit by e.g. quoting the layout stateid the CB_LAYOUTRECALL was sent for otherwise it will be harder to handle an inflight LAYOUTRETURN that hasn't been seen by the server before it sent out the CB_LAYOUTRECALL and that will effectively complete the recall. Note that the per-file layout stateid does not solve the problem for recalling and returning layouts for FSID and ALL. A per-client layout stateid may help here but it can limit parallelism. Benny > > Trond > >> -----Original Message----- >> From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] >> Sent: Monday, July 09, 2007 1:22 PM >> To: Black_David@emc.com >> Cc: nfsv4@ietf.org >> Subject: RE: [nfsv4] layout stateids and pNFS callbacks >> >> >> On Mon, 2007-07-09 at 13:05 -0400, Black_David@emc.com wrote: >>> That depends on the details of how they're used. We have experience >>> (i.e., running code) with FMP for MPFS that a single sequence count >>> *that is included in all the relevant operations, including callbacks* >>> is sufficient to sort this out if one pays close attention to all the >>> details. >>> >>> The class of race you describe is handled at the client by observing >>> that the callback carries seqid "n", but the client hasn't processed >>> the reply to operation "n", and hence the client holds the callback >>> until operation "n" (the OPEN) is processed. OTOH, if the callback >>> doesn't carry a seqid, the game's over ... and the fix is not to make >>> that design mistake ;-). >> OK. I see where you're coming from now. Basically you are extending the >> v4.0 sequencing scheme to work with callbacks? I suppose that can work, >> but it does seem a tad inelegant. >> >> Why do you want an alternative to sessions? >> >> Trond >> >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From fjhhz@libero.it Tue Jul 10 05:54:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8CQF-0004pd-AD for nfsv4-archive@lists.ietf.org; Tue, 10 Jul 2007 05:54:19 -0400 Received: from [59.93.79.63] (helo=gbqryek) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I8CQA-0006d3-6d for nfsv4-archive@lists.ietf.org; Tue, 10 Jul 2007 05:54:19 -0400 Received: from [51.56.148.108] (helo=bhyjt) by gbqryek with smtp (Exim 4.62 (FreeBSD)) id 1I8CV-0006dA-Bu; Tue, 10 Jul 2007 15:28:58 +0530 Message-ID: <46935745.7060805@libero.it> Date: Tue, 10 Jul 2007 15:24:13 +0530 From: James User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: The bill received parliamentary approval and is expected to be signed into law by President Levy Mwanawasa within a month or two. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 VPSN Has Wild Day as Stock climbs $0.019 (90.48%) GAIN! VISION AIRSHIPS INC (Other OTC:VPSN.PK) The 24 hrs has been a sky rocket for VPSN. With major news to be released stirring interest has brought huge returns for investors. The key is, knowing when to get on and when to get off a stock, for successful day trading. VPSN has distinct patterns to watch for. This ride is not over. Jump on now and ride the price up on the highest return "Day Trade" we have featured this year. Get on VPSN first thing Tuesday as we stired you in the right direction for Monday. Chinese Internet users' access to Google is filtered for specific keywords, and this filtering disrupts Google searches as well as access to the Google cache. Atlantis Lands in CaliforniaSpace shuttle Atlantis descended to a smooth landing at Edwards Air Force Base, Calif. Try your hand at our simple Quiz About Harry Potter and Astronomy at Hogwarts. Remember, like Harry Potter, you may need astronomy some day. Flight controllers and forecasters continue to monitor the weather at Kennedy Space Center, Fla. NASA is quickly gearing up for the shuttle's next visit to the International Station, targeted for an Aug. The Asia Foundation started a program to look at how ICTs can be used to address human trafficking. Keep answering these Harry Potter questions to see whether your stay at Hogwarts has been successful or whether you'll be returning to the land of the muggles. Keep answering these Harry Potter questions to see whether your stay at Hogwarts has been successful or whether you'll be returning to the land of the muggles. The Geneva government has set up five information stands complete with an internet connection in the constituencies. You can also view a map displaying accumulate The committee recommended adopting e-commerce type provisions along with protection of ISPs for liability for third party content. Earthquake Information for Arizona Earthquake Maps Earthquake LocationLocation MapsDid You Feel It? NASA is quickly gearing up for the shuttle's next visit to the International Station, targeted for an Aug. The centres will be equipped with experts to assist citizens who don't own a computer or who need advice. The payload was delivered Sunday to the launch pad's payload changeout room. to begin the descent to Kennedy. Earthquake Maps Earthquake LocationLocation MapsHistorical SeismicitySeismic Hazard MapGoogle Map Did you feel it? to begin the descent to Kennedy. Earthquake Summary Earthquake Information for Oregon Earthquake Maps Earthquake LocationLocation MapsHistorical SeismicitySeismic Hazard MapGoogle Map Did you feel it? Earthquake Summary Earthquake Information for Oregon Earthquake Maps Earthquake LocationLocation MapsHistorical SeismicitySeismic Hazard MapGoogle Map Did you feel it? Earthquake Maps Earthquake LocationLocation MapsDid You Feel It? Rowling's fantasy series about the boy wizard, Harry Potter, had its world premier in Tokyo today. Earthquake Maps Earthquake LocationGoogle Map Did you feel it? You can also view a map displa Earthquake Summary Earthquake Information for Alaska Earthquake Maps Earthquake LocationLocation MapsHistorical SeismicitySeismic Hazard MapGoogle Map Did you feel it? to begin the descent to Kennedy. Try your hand at our simple Quiz About Harry Potter and Astronomy at Hogwarts. It addresses the priorities of international policy initiatives and identifies their discursive constructions. The bill received parliamentary approval and is expected to be signed into law by President Levy Mwanawasa within a month or two. You can also view a map displaying accumulated data fro Earthquake Summary Earthquake Information for Hawaii Earthquake Maps Earthquake LocationLocation MapsHistorical SeismicitySeismic Hazard MapGoogle Map Did you feel it? The payload was delivered Sunday to the launch pad's payload changeout room. , concluding a successful assembly mission to the International Space Station. Earthquake Maps Earthquake LocationLocation MapsHistorical SeismicitySeismic Hazard MapEQ Density MapGoogle Map Did you feel it? From nfsv4-bounces@ietf.org Tue Jul 10 10:35:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Go6-0006W3-8T; Tue, 10 Jul 2007 10:35:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Go5-0006Vy-30 for nfsv4@ietf.org; Tue, 10 Jul 2007 10:35:13 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Go4-0006Rx-R6 for nfsv4@ietf.org; Tue, 10 Jul 2007 10:35:13 -0400 X-IronPort-AV: E=Sophos;i="4.16,522,1175497200"; d="scan'208";a="80551049" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 10 Jul 2007 07:35:11 -0700 Received: from tooting.eng.netapp.com (tooting-fe.eng.netapp.com [10.56.10.118]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6AEZBeG022122 for ; Tue, 10 Jul 2007 07:35:11 -0700 (PDT) Received: (from beepy@localhost) by tooting.eng.netapp.com (8.11.7p1+Sun/8.11.6) id l6AEZ8o19399 for nfsv4@ietf.org; Tue, 10 Jul 2007 07:35:08 -0700 (PDT) From: Brian Pawlowski Message-Id: <200707101435.l6AEZ8o19399@tooting.eng.netapp.com> To: nfsv4@ietf.org Date: Tue, 10 Jul 2007 07:35:08 -0700 (PDT) X-Mailer: ELM [version 2.4ME++ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [nfsv4] July 13 cutoff for IETF 69 Early Bird Registration X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org ----- Forwarded message from IETF Secretariat ----- From=20wgchairs-bounces@ietf.org Tue Jul 10 06:32:47 2007 To: IETF Announcement list From: IETF Secretariat Date: Tue, 10 Jul 2007 09:32:26 -0400 Cc: irsg@isi.edu, wgchairs@ietf.org Subject: IETF 69 =E2=80=93 Early Bird Registration and Registration=20 Cancellation Cutoff Dates=20 69th IETF Meeting=20 Chicago, IL, USA=20 July 22-27, 2007=20 Host: Motorola=20 =20 REMINDER: Early bird registration cutoff is Friday, July 13 at 12:00 noon ET (16:00 UTC/GMT). If you register and pay prior to this time, the registration fee is $600.00. After this time the fee will be $750.00.=20 =20 Registration cancellation cutoff is Monday, July 16 at 17:00 ET (21:00 UTC/GMT). Cancellations and requests for refund received by this date are subject to a 10% service charge. Refunds will not be honored beyond this date.=C2=A0 To cancel your registration and request a refund, contact the I= ETF Registrar at ietf-registrar@ietf.org.=C2=A0 Substitutions are not allowed.= =20 =20 To register for the IETF meeting and social event, please go to:=20 http://www.ietf.org/meetings/69-IETF.html Only 12 days until the 69th IETF in Chicago, IL!=20 ----- End of forwarded message from IETF Secretariat ----- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 10 23:21:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8SlN-0007l6-9L; Tue, 10 Jul 2007 23:21:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8RJh-0000e3-14 for nfsv4@ietf.org; Tue, 10 Jul 2007 21:48:33 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8RJc-0001Vg-N6 for nfsv4@ietf.org; Tue, 10 Jul 2007 21:48:33 -0400 X-IronPort-AV: E=Sophos;i="4.16,524,1175497200"; d="scan'208";a="80722594" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 10 Jul 2007 18:48:28 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6B1mRLp023431 for ; Tue, 10 Jul 2007 18:48:27 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 18:48:27 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 18:48:27 -0700 Received: from 10.30.32.47 ([10.30.32.47]) by exnane01.hq.netapp.com ([10.97.0.61]) with Microsoft Exchange Server HTTP-DAV ; Wed, 11 Jul 2007 01:48:26 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 10 Jul 2007 21:48:31 -0400 From: Daniel Ellard To: Message-ID: Thread-Topic: The composition of pseudo file systems in single-server namespaces Thread-Index: AcfDXZVy1ARp1y9QEdyq1wARJNaE/g== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 11 Jul 2007 01:48:27.0953 (UTC) FILETIME=[93A11210:01C7C35D] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Tue, 10 Jul 2007 23:21:09 -0400 Subject: [nfsv4] The composition of pseudo file systems in single-server namespaces X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org This came up today during a discussion of the 4.1 draft, but we didn't have time to resolve the question and it was suggested that the mailing list would be a better forum: Q: What kinds of objects can appear in the pseudo file system used to implement a single-server namespace? The example in the draft makes it appear that the only thing that can appear are directories that are used to stitch together local file systems. (from the example, it looks like only a single level of directories is permitted, so, for example, if we have / - pseudo file system /a - local file system /a/b - could be a pseudo file system /a/b/c - must be a local file system? The consensus was no, it's OK for the pseudo file system to contain multiple levels, i.e., a path like /a/b/c/d could have /a/b/c in the pseudo file system and /a/b/c/d being in a local file system. The next question is whether anything else can be in the pseudo file system. Some things that were mentioned: 1. Symlinks (or hard links, although nobody mentioned a use case -- probably pointless unless ordinary files can be present as well) 2. Ordinary files 3. Referrals At this point there's really not much pseudo about the file system that implements the local server namespace, and it can be stitched, via referrals, directly to other single server namespaces. The idea of having referrals as first-class objects in the single server namespace blurs (or erases) the line between the single server namespace and the multi server namespace, but be able to unify these ideas into a single abstraction. If you know what the spec was trying to express here, or have an opinion about what it should be trying to express, please chime in. Thanks, -Dan _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 10 23:44:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8T7r-0003LW-06; Tue, 10 Jul 2007 23:44:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8T7q-0003LR-4v for nfsv4@ietf.org; Tue, 10 Jul 2007 23:44:26 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8T7b-0004za-NZ for nfsv4@ietf.org; Tue, 10 Jul 2007 23:44:26 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6B3gprn019976 for ; Wed, 11 Jul 2007 03:42:51 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKZ00M01WMQAI00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 10 Jul 2007 21:42:50 -0600 (MDT) Received: from [192.168.0.3] (adsl-71-145-190-138.dsl.austtx.sbcglobal.net [71.145.190.138]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKZ00D5XWZEC320@mail-amer.sun.com>; Tue, 10 Jul 2007 21:42:50 -0600 (MDT) Date: Tue, 10 Jul 2007 22:42:56 -0500 From: Spencer Shepler Subject: Re: [nfsv4] The composition of pseudo file systems in single-server namespaces In-reply-to: To: Daniel Ellard Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 10, 2007, at 8:48 PM, Daniel Ellard wrote: > > This came up today during a discussion of the 4.1 draft, but we > didn't have > time to resolve the question and it was suggested that the mailing > list > would be a better forum: > > Q: What kinds of objects can appear in the pseudo file system used to > implement a single-server namespace? > > The example in the draft makes it appear that the only thing that > can appear > are directories that are used to stitch together local file > systems. (from > the example, it looks like only a single level of directories is > permitted, > so, for example, if we have > > / - pseudo file system > /a - local file system > /a/b - could be a pseudo file system > /a/b/c - must be a local file system? > > The consensus was no, it's OK for the pseudo file system to contain > multiple > levels, i.e., a path like /a/b/c/d could have /a/b/c in the pseudo > file > system and /a/b/c/d being in a local file system. > > The next question is whether anything else can be in the pseudo > file system. > Some things that were mentioned: > > 1. Symlinks (or hard links, although nobody mentioned a use case -- > probably > pointless unless ordinary files can be present as well) > > 2. Ordinary files > > 3. Referrals > > At this point there's really not much pseudo about the file system > that > implements the local server namespace, and it can be stitched, via > referrals, directly to other single server namespaces. > > The idea of having referrals as first-class objects in the single > server > namespace blurs (or erases) the line between the single server > namespace and > the multi server namespace, but be able to unify these ideas into a > single > abstraction. > > If you know what the spec was trying to express here, or have an > opinion > about what it should be trying to express, please chime in. As Mike pointed out during the review, the pseudo file system concept was used in 4.0 to provide a conceptual anchor to a method of namespace access that differed from NFSv3. It was also mentioned that the client doesn't have a method of determine what portion of the namespace represents pseudo file system and what does not. And, to quote from the spec: "A pseudo file system has a unique fsid and behaves like a normal, read only file system." I think that is sufficient. If a read only file system has the potential of containing various object types then the pseudo file system may as well. I don't see any need to restrict its behavior. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 11 10:57:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ddU-0003rV-Em; Wed, 11 Jul 2007 10:57:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ddT-0003rQ-IL for nfsv4@ietf.org; Wed, 11 Jul 2007 10:57:47 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8ddP-0002OM-76 for nfsv4@ietf.org; Wed, 11 Jul 2007 10:57:47 -0400 X-IronPort-AV: E=Sophos;i="4.16,527,1175497200"; d="scan'208";a="80898476" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 11 Jul 2007 07:57:41 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6BEvB0p012474; Wed, 11 Jul 2007 07:57:39 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 07:57:25 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 07:57:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] The composition of pseudo file systems in single-server namespaces Date: Wed, 11 Jul 2007 10:57:22 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] The composition of pseudo file systems in single-server namespaces Thread-Index: AcfDbZI4LzxVPT8rT8SXxsqAD0/H7AAWdGlw References: From: "Ellard, Daniel" To: "Spencer Shepler" X-OriginalArrivalTime: 11 Jul 2007 14:57:24.0771 (UTC) FILETIME=[CA924730:01C7C3CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org =20 > -----Original Message----- > From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 > Sent: Tuesday, July 10, 2007 11:43 PM > To: Ellard, Daniel > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] The composition of pseudo file systems=20 > in single-server namespaces >=20 >=20 > On Jul 10, 2007, at 8:48 PM, Daniel Ellard wrote: >=20 > > Q: What kinds of objects can appear in the pseudo file=20 > system used to=20 > > implement a single-server namespace? > > > > ... > > The next question is whether anything else can be in the=20 > pseudo file=20 > > system. > > Some things that were mentioned: > > > > 1. Symlinks (or hard links, although nobody mentioned a use case --=20 > > probably pointless unless ordinary files can be present as well) > > > > 2. Ordinary files > > > > 3. Referrals > > > > At this point there's really not much pseudo about the file system=20 > > that implements the local server namespace, and it can be stitched,=20 > > via referrals, directly to other single server namespaces. > > > > The idea of having referrals as first-class objects in the single=20 > > server namespace blurs (or erases) the line between the=20 > single server=20 > > namespace and the multi server namespace, but be able to=20 > unify these=20 > > ideas into a single abstraction. > > > > If you know what the spec was trying to express here, or have an=20 > > opinion about what it should be trying to express, please chime in. >=20 > As Mike pointed out during the review, the pseudo file system=20 > concept was used in 4.0 to provide a conceptual anchor to a=20 > method of namespace access that differed from NFSv3. It was=20 > also mentioned that the client doesn't have a method of=20 > determine what portion of the namespace represents pseudo=20 > file system and what does not. >=20 > And, to quote from the spec: >=20 > "A pseudo file system has a unique fsid and behaves > like a normal, read only file system." >=20 > I think that is sufficient. If a read only file system has=20 > the potential of containing various object types then the=20 > pseudo file system may as well. I don't see any need to=20 > restrict its behavior. Agreed -- from the client's point of view, it should look normal. But what I want to clarify is whether there's anything required of the server. The only thing that is required to satisfy the current examples is directories and mounts of local file systems. Do we want to require any other file system object types, or just leave that up to the implementators to decide? -Dan _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 11 11:04:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dkI-0003wQ-Ku; Wed, 11 Jul 2007 11:04:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dkH-0003wK-L8 for nfsv4@ietf.org; Wed, 11 Jul 2007 11:04:49 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8dk2-0002cw-8t for nfsv4@ietf.org; Wed, 11 Jul 2007 11:04:49 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6BF3O8f025253 for ; Wed, 11 Jul 2007 15:03:24 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JL000301S9S3D00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 11 Jul 2007 09:03:24 -0600 (MDT) Received: from [192.168.0.3] (adsl-71-145-170-113.dsl.austtx.sbcglobal.net [71.145.170.113]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JL000DVGSHNC360@mail-amer.sun.com> for nfsv4@ietf.org; Wed, 11 Jul 2007 09:03:24 -0600 (MDT) Date: Wed, 11 Jul 2007 10:03:30 -0500 From: Spencer Shepler Subject: Re: [nfsv4] The composition of pseudo file systems in single-server namespaces In-reply-to: To: nfsv4@ietf.org Message-id: <6D580B4B-74A5-4C54-9A43-BF277502360B@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 11, 2007, at 9:57 AM, Ellard, Daniel wrote: > >>> >>> If you know what the spec was trying to express here, or have an >>> opinion about what it should be trying to express, please chime in. >> >> As Mike pointed out during the review, the pseudo file system >> concept was used in 4.0 to provide a conceptual anchor to a >> method of namespace access that differed from NFSv3. It was >> also mentioned that the client doesn't have a method of >> determine what portion of the namespace represents pseudo >> file system and what does not. >> >> And, to quote from the spec: >> >> "A pseudo file system has a unique fsid and behaves >> like a normal, read only file system." >> >> I think that is sufficient. If a read only file system has >> the potential of containing various object types then the >> pseudo file system may as well. I don't see any need to >> restrict its behavior. > > Agreed -- from the client's point of view, it should look normal. > > But what I want to clarify is whether there's anything required of the > server. The only thing that is required to satisfy the current > examples > is directories and mounts of local file systems. Do we want to > require > any other file system object types, or just leave that up to the > implementators to decide? Implementation choice. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 11 11:14:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dtP-0004NH-8z; Wed, 11 Jul 2007 11:14:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dtN-0004N7-4J for nfsv4@ietf.org; Wed, 11 Jul 2007 11:14:13 -0400 Received: from gigi.cs.uoguelph.ca ([131.104.94.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8dtJ-0002nA-Q4 for nfsv4@ietf.org; Wed, 11 Jul 2007 11:14:13 -0400 Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.96.170]) by gigi.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id l6BFE6Wo021600 for ; Wed, 11 Jul 2007 11:14:06 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id l6BFI0K08939 for ; Wed, 11 Jul 2007 11:18:00 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 11 Jul 2007 11:18:00 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher To: nfsv4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 131.104.94.210 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [nfsv4] Volatile FH's, a client implementor's perspective X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I saw some recent discussion about volatile FHs and thought I'd post this: When a client receives an NFS4ERR_FHEXPIRED, what can it do? - The only thing I can think of is PutRootFH, Lookup,..., Lookup, GetFH using the path it had acquired the expired FH with. (It has to capture this path, but that's just a client side implementation hassle.) - Now, how does it know the new FH acquired above refers to the same file object as the one the expired FH referenced? I haven't a clue? I believe it can assume the Fsid and Type attributes should still be the same, but that isn't exactly an "iron clad" sanity check:-) So, if servers choose to use volatile file handles, it seems they should try very hard to make sure the same pathname never refers to a different file. Now, wait a minute. If the path never refers to a different file... --> the server could use that path to create a non-volatile FH, couldn't it? - If the path is less than 128 bytes, put that in the FH, else compress the path Ok, so for long paths that won't compress down to 128 bytes, it doesn't quite work, but my point is that, it a server can avoid reuse of the path, it seems that there should be a similar mechanism it can use to generate a non-volatile FH? As you might have guessed, my client doesn't handle volatile FH's, rick _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 11 11:19:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dyp-00063q-CM; Wed, 11 Jul 2007 11:19:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dyn-00063B-Kh for nfsv4@ietf.org; Wed, 11 Jul 2007 11:19:49 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8dyc-00038F-55 for nfsv4@ietf.org; Wed, 11 Jul 2007 11:19:49 -0400 X-IronPort-AV: E=Sophos;i="4.16,527,1175497200"; d="scan'208";a="80905826" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 11 Jul 2007 08:19:36 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6BFJTse021072; Wed, 11 Jul 2007 08:19:36 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 08:19:35 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 08:19:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Volatile FH's, a client implementor's perspective Date: Wed, 11 Jul 2007 11:19:25 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Volatile FH's, a client implementor's perspective Thread-Index: AcfDzk2u/VRoveZkRpChgJXmsaATJAAAEg2g From: "Noveck, Dave" To: "Rick Macklem" , X-OriginalArrivalTime: 11 Jul 2007 15:19:35.0163 (UTC) FILETIME=[E38BFCB0:01C7C3CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I would assume that you could check fsid and fileid. It is true that fielid is not a mandatory attribute, but most servers do support it. -----Original Message----- From: Rick Macklem [mailto:rmacklem@uoguelph.ca]=20 Sent: Wednesday, July 11, 2007 11:18 AM To: nfsv4@ietf.org Subject: [nfsv4] Volatile FH's, a client implementor's perspective I saw some recent discussion about volatile FHs and thought I'd post this: When a client receives an NFS4ERR_FHEXPIRED, what can it do? - The only thing I can think of is PutRootFH, Lookup,..., Lookup, GetFH using the path it had acquired the expired FH with. (It has to capture this path, but that's just a client side implementation hassle.) - Now, how does it know the new FH acquired above refers to the same file object as the one the expired FH referenced? I haven't a clue? I believe it can assume the Fsid and Type attributes should still be the same, but that isn't exactly an "iron clad" sanity check:-) So, if servers choose to use volatile file handles, it seems they should try very hard to make sure the same pathname never refers to a different file. Now, wait a minute. If the path never refers to a different file... --> the server could use that path to create a non-volatile FH, couldn't it? - If the path is less than 128 bytes, put that in the FH, else compress the path Ok, so for long paths that won't compress down to 128 bytes, it doesn't quite work, but my point is that, it a server can avoid reuse of the path, it seems that there should be a similar mechanism it can use to generate a non-volatile FH? As you might have guessed, my client doesn't handle volatile FH's, rick _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 11 13:33:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8g4W-0006OK-0s; Wed, 11 Jul 2007 13:33:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8g4V-0006O5-7d for nfsv4@ietf.org; Wed, 11 Jul 2007 13:33:51 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8g4U-0000A3-Q9 for nfsv4@ietf.org; Wed, 11 Jul 2007 13:33:51 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6BHX4F4007159 for ; Wed, 11 Jul 2007 17:33:04 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JL000B01YPQLK00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 11 Jul 2007 11:33:04 -0600 (MDT) Received: from [192.168.0.3] (adsl-71-145-175-66.dsl.austtx.sbcglobal.net [71.145.175.66]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JL000GLIZF32W00@mail-amer.sun.com>; Wed, 11 Jul 2007 11:33:04 -0600 (MDT) Date: Wed, 11 Jul 2007 12:33:11 -0500 From: Spencer Shepler Subject: Re: [nfsv4] Volatile FH's, a client implementor's perspective In-reply-to: To: Rick Macklem Message-id: <43FA9332-08EC-41C8-B9CD-BB0B1AB10C70@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org As Dave mentions, checking the fsid and fileid are first line methodology along with file type and other attrs like size or modified time. The main thing to remember is that volatile filehandles present a less then perfect world for the client and there are holes on the recovery path. Spencer On Jul 11, 2007, at 10:18 AM, Rick Macklem wrote: > I saw some recent discussion about volatile FHs and thought I'd > post this: > When a client receives an NFS4ERR_FHEXPIRED, what can it do? > - The only thing I can think of is PutRootFH, Lookup,..., Lookup, > GetFH > using the path it had acquired the expired FH with. (It has to > capture > this path, but that's just a client side implementation hassle.) > - Now, how does it know the new FH acquired above refers to the same > file object as the one the expired FH referenced? I haven't a > clue? > I believe it can assume the Fsid and Type attributes should > still be > the same, but that isn't exactly an "iron clad" sanity check:-) > > So, if servers choose to use volatile file handles, it seems they > should > try very hard to make sure the same pathname never refers to a > different > file. > Now, wait a minute. If the path never refers to a different file... > --> the server could use that path to create a non-volatile FH, > couldn't > it? > - If the path is less than 128 bytes, put that in the FH, else > compress the path > Ok, so for long paths that won't compress down to 128 bytes, it > doesn't quite work, but my point is that, it a server can avoid > reuse of the path, it seems that there should be a similar > mechanism > it can use to generate a non-volatile FH? > > As you might have guessed, my client doesn't handle volatile FH's, > rick > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 11 15:28:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hqz-0008Aa-5C; Wed, 11 Jul 2007 15:28:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hqx-0008A1-On for nfsv4@ietf.org; Wed, 11 Jul 2007 15:27:59 -0400 Received: from mailhub.cs.uoguelph.ca ([131.104.94.205]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8hqt-00051n-EF for nfsv4@ietf.org; Wed, 11 Jul 2007 15:27:59 -0400 Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.96.170]) by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id l6BJRqC0013698; Wed, 11 Jul 2007 15:27:52 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id l6BJVkN16894; Wed, 11 Jul 2007 15:31:46 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 11 Jul 2007 15:31:46 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher To: "Noveck, Dave" Subject: RE: [nfsv4] Volatile FH's, a client implementor's perspective In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 131.104.94.205 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Wed, 11 Jul 2007, Noveck, Dave wrote: > I would assume that you could check fsid and fileid. It is > true that fielid is not a mandatory attribute, but most > servers do support it. > I thought about fileid, but couldn't find anywhere in RFC3530 that said that it won't change when an FH expires. I could see a server implementor creating a pseudo-root fs and generating the fileids on the fly. When the pseudo-root fs is re-created, the old FH's would expire and the new pseudo-root fs might assign different fileids. It might be worth clarifying that a given fileid will only represent a given file object until that object no longer exists, so that it can be used in the sanity check. rick _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 11 15:36:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hzK-0002of-66; Wed, 11 Jul 2007 15:36:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8hzI-0002oI-So for nfsv4@ietf.org; Wed, 11 Jul 2007 15:36:36 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8hzB-0006f8-Iz for nfsv4@ietf.org; Wed, 11 Jul 2007 15:36:36 -0400 X-IronPort-AV: E=Sophos;i="4.16,527,1175497200"; d="scan'208";a="80994419" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 11 Jul 2007 12:36:10 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6BJaAo7028181; Wed, 11 Jul 2007 12:36:10 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 12:36:10 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 12:36:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Volatile FH's, a client implementor's perspective Date: Wed, 11 Jul 2007 15:36:08 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Volatile FH's, a client implementor's perspective Thread-Index: AcfD8Zw++4Cfxw5pT5SmvYWmSwk5GQAAM6oA From: "Noveck, Dave" To: "Rick Macklem" X-OriginalArrivalTime: 11 Jul 2007 19:36:10.0251 (UTC) FILETIME=[BBBBFDB0:01C7C3F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org To me it is impied by the definition, "A number uniquely identifying the file within the filesystem". A number=20 that changes essentially at random is not useful for identifying a file within the filesystem. -----Original Message----- From: Rick Macklem [mailto:rmacklem@uoguelph.ca]=20 Sent: Wednesday, July 11, 2007 3:32 PM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: RE: [nfsv4] Volatile FH's, a client implementor's perspective On Wed, 11 Jul 2007, Noveck, Dave wrote: > I would assume that you could check fsid and fileid. It is > true that fielid is not a mandatory attribute, but most > servers do support it. > I thought about fileid, but couldn't find anywhere in RFC3530 that said that it won't change when an FH expires. I could see a server implementor creating a pseudo-root fs and generating the fileids on the fly. When the pseudo-root fs is re-created, the old FH's would expire and the new pseudo-root fs might assign different fileids. It might be worth clarifying that a given fileid will only represent a given file object until that object no longer exists, so that it can be used in the sanity check. rick _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 11 17:43:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8jyK-0000sn-VX; Wed, 11 Jul 2007 17:43:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8jyJ-0000mQ-Kk for nfsv4@ietf.org; Wed, 11 Jul 2007 17:43:43 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8jyC-0001U7-DJ for nfsv4@ietf.org; Wed, 11 Jul 2007 17:43:43 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6BLglT9027232; Wed, 11 Jul 2007 17:42:47 -0400 (EDT) Received: from [128.222.177.194] ([128.222.177.194]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6BLgiD5007795; Wed, 11 Jul 2007 17:42:45 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0D83C041-B229-4714-8964-880D4B786715@emc.com> Content-Transfer-Encoding: 7bit From: Paul Lemahieu Subject: Re: [nfsv4] Volatile FH's, a client implementor's perspective Date: Wed, 11 Jul 2007 14:42:45 -0700 To: Rick Macklem X-Mailer: Apple Mail (2.752.3) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=1%, Reasons='EMC_FROM_0+ -3, RDNS_NXDOMAIN 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: "Noveck, Dave" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org > > On Wed, 11 Jul 2007, Noveck, Dave wrote: > >> I would assume that you could check fsid and fileid. It is >> true that fielid is not a mandatory attribute, but most >> servers do support it. >> > I thought about fileid, but couldn't find anywhere in RFC3530 that > said > that it won't change when an FH expires. I could see a server > implementor > creating a pseudo-root fs and generating the fileids on the fly. > When the > pseudo-root fs is re-created, the old FH's would expire and the new > pseudo-root fs might assign different fileids. > > It might be worth clarifying that a given fileid will only represent a > given file object until that object no longer exists, so that it > can be > used in the sanity check. > > rick > Is it allowed for fsid and fileid to change when a file handle expires? For example, a directory has been internally moved to another physical file system. Access to those files now returns expired file handles. Objects and paths haven't changed, but file handles, fsids, and fileids have. I can think of cases where the preferred resolution to an expired FH would be to simply ask the file server what the new file handle is, given the old FH. This would be particularly useful for resolving NFS4ERR_MOVED. The advantage is basically the one that started this discussion: there is no need to deal with trying to figure out if the object at the path is really the same object for those cases where the file server itself can provide the new file handle. --Paul Paul LeMahieu lemahieu_paul@emc.com _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 11 20:29:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8mYc-0003ap-IQ; Wed, 11 Jul 2007 20:29:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8mYb-0003aj-MH for nfsv4@ietf.org; Wed, 11 Jul 2007 20:29:21 -0400 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8mYM-0005as-8O for nfsv4@ietf.org; Wed, 11 Jul 2007 20:29:21 -0400 Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1I8mXj-0001Sb-7b; Thu, 12 Jul 2007 02:28:27 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx5.uio.no) by mail-mx5.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1I8mXi-0001kc-Ka; Thu, 12 Jul 2007 02:28:26 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx5.uio.no with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1I8mXi-0001kV-7J; Thu, 12 Jul 2007 02:28:26 +0200 Subject: Re: [nfsv4] Volatile FH's, a client implementor's perspective From: Trond Myklebust To: Paul Lemahieu In-Reply-To: <0D83C041-B229-4714-8964-880D4B786715@emc.com> References: <0D83C041-B229-4714-8964-880D4B786715@emc.com> Content-Type: text/plain Date: Wed, 11 Jul 2007 20:28:24 -0400 Message-Id: <1184200104.30876.118.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.092) X-UiO-Scanned: 77326FA15F1F4C831D57D38082BFDFB5B5B5436E X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 104 total 2811594 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Rick Macklem , "Noveck, Dave" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Wed, 2007-07-11 at 14:42 -0700, Paul Lemahieu wrote: > Is it allowed for fsid and fileid to change when a file handle > expires? For example, a directory has been internally moved to > another physical file system. Access to those files now returns > expired file handles. Objects and paths haven't changed, but file > handles, fsids, and fileids have. I suppose it is allowed. It would not, however be a good idea if you want to avoid data corruption issues. It would be fairly trivial for client1 to rename a file onto another before client2 got round to recovering its filehandle: there is no equivalent to the grace period when it comes to filehandle recovery. > I can think of cases where the preferred resolution to an expired FH > would be to simply ask the file server what the new file handle is, > given the old FH. This would be particularly useful for resolving > NFS4ERR_MOVED. The advantage is basically the one that started this > discussion: there is no need to deal with trying to figure out if the > object at the path is really the same object for those cases where > the file server itself can provide the new file handle. If the server can recognise the old file handle, why would you need to migrate it? Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 11 20:45:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8moP-0006ls-2B; Wed, 11 Jul 2007 20:45:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8moO-0006lk-3n for nfsv4@ietf.org; Wed, 11 Jul 2007 20:45:40 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8moN-0005xx-RG for nfsv4@ietf.org; Wed, 11 Jul 2007 20:45:40 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6C0ifK2018486; Wed, 11 Jul 2007 20:44:41 -0400 (EDT) Received: from [128.222.177.194] ([128.222.177.194]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6C0idWl025178; Wed, 11 Jul 2007 20:44:39 -0400 (EDT) In-Reply-To: <1184200104.30876.118.camel@heimdal.trondhjem.org> References: <0D83C041-B229-4714-8964-880D4B786715@emc.com> <1184200104.30876.118.camel@heimdal.trondhjem.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Paul Lemahieu Subject: Re: [nfsv4] Volatile FH's, a client implementor's perspective Date: Wed, 11 Jul 2007 17:44:39 -0700 To: "Trond Myklebust" X-Mailer: Apple Mail (2.752.3) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=1%, Reasons='EMC_FROM_0+ -3, RDNS_NXDOMAIN 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Rick Macklem , "Noveck, Dave" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On 2007-Jul-11, at 17:28, Trond Myklebust wrote: > On Wed, 2007-07-11 at 14:42 -0700, Paul Lemahieu wrote: > >> Is it allowed for fsid and fileid to change when a file handle >> expires? For example, a directory has been internally moved to >> another physical file system. Access to those files now returns >> expired file handles. Objects and paths haven't changed, but file >> handles, fsids, and fileids have. > > I suppose it is allowed. It would not, however be a good idea if you > want to avoid data corruption issues. It would be fairly trivial for > client1 to rename a file onto another before client2 got round to > recovering its filehandle: there is no equivalent to the grace period > when it comes to filehandle recovery. > >> I can think of cases where the preferred resolution to an expired FH >> would be to simply ask the file server what the new file handle is, >> given the old FH. This would be particularly useful for resolving >> NFS4ERR_MOVED. The advantage is basically the one that started this >> discussion: there is no need to deal with trying to figure out if the >> object at the path is really the same object for those cases where >> the file server itself can provide the new file handle. > > If the server can recognise the old file handle, why would you need to > migrate it? > Because the ability to recognise the old file handle may either be expensive, or a transient ability. It may be advantageous to get all clients on the new file handles as quickly as possible by the simplest mechanism possible. --Paul _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From ioh@tut.by Wed Jul 11 22:31:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8oSs-0001dn-KB for nfsv4-archive@lists.ietf.org; Wed, 11 Jul 2007 22:31:34 -0400 Received: from [211.219.115.107] (helo=ttsfmxe) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I8oSn-0000Nq-9u for nfsv4-archive@lists.ietf.org; Wed, 11 Jul 2007 22:31:34 -0400 Received: from [182.217.106.42] (helo=pecyr) by ttsfmxe with smtp (Exim 4.66 (FreeBSD)) id 1I9%-0001gB-LY; Thu, 12 Jul 2007 11:32:23 +0900 Message-ID: <4695927E.8060808@tut.by> Date: Thu, 12 Jul 2007 11:31:26 +0900 From: Dick User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: Mailbody.bswrhapktvziar.pdf Content-Type: multipart/mixed; boundary="------------010401080006030604020402" X-Spam-Score: 2.5 (++) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e --------------010401080006030604020402 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------010401080006030604020402 Content-Type: application/pdf; name="Mailbody.bswrhapktvziar.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Mailbody.bswrhapktvziar.pdf" JVBERi0xLjMgCjEgMCBvYmoKPDwKPj4KZW5kb2JqCjIgMCBvYmoKPDwKL1R5cGUgL0NhdGFsb2cK L1BhZ2VzIDMgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8Ci9UeXBlIC9QYWdlcwovS2lkcyBbIDQg MCBSIF0KL0NvdW50IDEKPj4KZW5kb2JqCjQgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL1BhcmVudCAz IDAgUgovUmVzb3VyY2VzIDw8Ci9Gb250IDw8IC9GMCA4IDAgUiA+PgovWE9iamVjdCA8PCAvSW0w IDkgMCBSID4+Ci9Qcm9jU2V0IDcgMCBSID4+Ci9NZWRpYUJveCBbMCAwIDc3OCAxMzNdCi9Dcm9w Qm94IFswIDAgNzc4IDEzM10KL0NvbnRlbnRzIDUgMCBSCi9UaHVtYiAxMiAwIFIKPj4KZW5kb2Jq CjUgMCBvYmoKPDwKL0xlbmd0aCA2IDAgUgo+PgpzdHJlYW0KcQo3NzggMCAwIDEzMyAwIDAgY20K L0ltMCBEbwpRCmVuZHN0cmVhbQplbmRvYmoKNiAwIG9iagozMQplbmRvYmoKNyAwIG9iagpbIC9Q REYgL1RleHQgL0ltYWdlSSBdCmVuZG9iago4IDAgb2JqCjw8Ci9UeXBlIC9Gb250Ci9TdWJ0eXBl IC9UeXBlMQovTmFtZSAvRjAKL0Jhc2VGb250IC9IZWx2ZXRpY2EKL0VuY29kaW5nIC9NYWNSb21h bkVuY29kaW5nCj4+CmVuZG9iago5IDAgb2JqCjw8Ci9UeXBlIC9YT2JqZWN0Ci9TdWJ0eXBlIC9J bWFnZQovTmFtZSAvSW0wCi9GaWx0ZXIgWyAvTFpXRGVjb2RlIF0KL1dpZHRoIDc3OAovSGVpZ2h0 IDEzMwovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEwIDAg Ugo+PgpzdHJlYW0KgAAgUDgkFg0HhEJhULhkNh0PiERiUTikVi0XjEZjUbjkdj0fkEhkUjkklk0n lEplUrlktl0vmExmUzmk1m03nE5nU7nk9n0/oFBoVDolFo1HpFJpVLplNp1PqFRqVTqlVq1XrFZr Vbrldr1fsFhsVjslls1ntFptVrtltt1vuFxuVzul1u02Ticii1WsIb5ejwWwWCsd8i4/H93xWLxk jw0Dx8wwV6jWRkmEgWYgScLksxDTLzfZLJoWIxun1GpieWZLfgmmhrJvsaRN9NgVjRexMlzUHCp7 heWhuwhWyo/E1XJ5XL1uv3cvdJDABpNME3sJL262GI7nPAGhjmchRpMnB2cP5EI68SWpsEJ7dIAI fUMmawYW8/CAHdxP87wAOM5cBQG07tv+joLFWzjaoSMjysyCyBuu1q/t24jTO4gRvtcgQuMpCT7w iiD3oU3sQw1DiHw2hj1oQLjavaEKDvqwcIAAzRatI77/wuxBRsBADzxvEUCSLIy5O2UaCuFE8QIL BMFgAWpExkADovVIj7SIgUMwM7zRMg87ry0zMFRehLyQhE0syy/r+IHHzwII/SDSbBKBwYAD4IHN MhxDNk1IK9LiNEyLLRbI9E0UssNwCghEkS61ARtPDznS6LpUpOs/oGWxyUFA6BNk2bIw9J1JIG8U 8ys+KDzXVCBU8gZLTdOEgTnIVTIW9ZEjZViBkpB8h2HNVJoEb1aTg/9HL5KdT01Rdo2ksFmyFaE/ INVcrUyAEaWNJ8iHIA9ZktQVboEyNIAAThV2e68zoENjgPk+cWW/cVyVmxLszDdEpkTXVroPbU+T 7TTCS0CxbIHZAAEtcsuN3MFcVSVcyWnjGMrBdlXS2gYL21K93RrgSBAOLF8oEVp8yXawAQ9i0RYv dbOoIeF5um6sQY9TeFU+gmHoHlaBkuvt00jjloUQgmRXBLeL59k9kYhh2ICkOAA6LfunYRb+CY1s GwqbFoLQ+AFeoGIduVfYtnoLoKBHyKSFWcjryPvg+eIfq4AoES+/7+gWASdmeaXtE+u53n2xcZxs jbrgsaVhxW9J1sm8JDTk1LzmqBvhbiHYucmUcd0vTdOomlqtuHUdb13X9h2PZdn2na9t2/cdz3Xd 953vfd/4Hg+F4fieL43j+R5PleX5nm+d5/oej6Xp+p6vrev7Hs+17fue773v/B8PxfH8ny/N8/0f SkZX7V9v21bKRxIIcX6Tm1tbvShBW6odBrYihkij7ghvwIu4AS7RAAhwbmeFF4ryCPuIyD+A7RIJ gAgUyxlQ3X+oGWUfsH45hUCoB0ZNBb7CpvvZwAB+j9YVPyIG/caZ3XAkHgUQQVo3QADWVCRVtRBA Kq+Im/krx3SSwsbEbqChMx0s4iNE1+RzYOxJIOw8VpAgPipQtFliJGIjEIigQqGcNX9kCG7DgibZ TxEChZD1PRuIWwthXC6MEFXAECgVAsS0VRugfi3Fs2A5hNslHEy4gsXYuk+h+QOFki4norg8c+GZ AoEhSCk/uPMZo+xCIpImRUcpDkxa+Q6T5IpNEdkOdoxEFSHxXiiQ5F4tYVl9hRJwoUcYjIVIJHUA EYYFRjAAB2TCXjvSAQk2aUUnpkEDiQciSMFg4EHlYhhLpu5iGZmMRKUZziGSVZUB0AErIPGrhcY8 x4bFIxvnRC9FJCJmy9ipMCP0WkuDmABCJG6H5YEHTo/OOQAJHQembAYOEz2qitmBOAiDZSJyji7D KA0dKCECjyQaDkfSMyGn6TCV5GovkFmaRqapIy/0ejpBOgc3AAUGijBwxEgJ7LrQ+/U/U5pCy2hY hWABMhxI6AAKNWskXAN9m5RMgUWJw1Hj+KggaCl0UZmPIqnlPkuUlIHAmG03qKK1O5PSl9TI1VOI jTuf8zJVEIj3PGixe1SGzkZGqnlaYaQLIFQeLE04OjmnomVl5tZ+p0n2QOf9R2/VlpRL+HFRiVyj qlBSh4l6rUSirK05x6U7kapvOsiNKrJylIVINKUhCJWcI9V6UiB5I2Fng/+TJia8AAhGo8vsRjDH 6mzYGshMziOBt1BUfL+49RXVDNIgVL0OznplaAhkX6HQTkjDWbs2lQEDhADoHQAEzXGjlX8h0RLB kEseQqitLYQEXMe4OdEjrbkKs1B24RxLqXWQXPmFRwlqq5mvdGKUdq5Rkj5Wgjt9SE2BvzLux0z7 e0pqxYLBRBL301I2F4adaaPgAt7HnBOCkL1cuolA81n2tkKhjTmxpFDu15ITbLABGsJ4Hv5K2IkH yBYbXa2eQihmjMumzekm9QMCqzsiB9/x/iDwgFXdUgR1GKWfu0Qu3NVAABSwrQaYJ3n8ioxmt06i kX6TkPzcgh0Bqq0RwQQyP+JiBBkZ0RQC6HzMYQj7QFvt4EeK1vHCMC2aA05akGkJauSVwEMgNd+u cmKLXCIblzD6myERCmbb6b2QLBHIg/kQgmWaM5LIjmAglziB1n0LMPExhMsxquQoac4nGPYQQzjy SVzqiQ5yom8gV4zMrCn1l2tZm9UOqITpwgeQLuUWrxlZYmebs41Py0jXaRNVHpnbfurJLcC5Qire ulmsiC54IIHuIC/l/Ze0BHTONKWIQaxcd4IGZsjhpbVEvbmN9ELonORXabQsL2inrUpG+tk9QpIi b2r0M+Bbjl9nIgutMznVjYAANmN8Pbecgi2NJCtqYWvwsoxG6cYmCzRh3h6Ut5rFURhPchBIdaSO eD8IDk3PLzMtdpP9lZ2Y9IJamyZBuNISWFANPW3a/rqUodeOtu9x3P0/dCeuRmcugITqZwiRLSEP 5tZIgnCM7nT3avFZqYc+tnYBstYkuaykD18ACDXJ4dksdZ2jWRpt0whtfliHsS6abea2pBgJErv9 rnlYLnOtSDbc65Ws2fQGLET72Ja1NOcFozZ0pfPxEjrmPjDHhqkOiGd/zPraJeNF+7xV0ZhFumOz +MwX3BLfCyGLN5C2zzxCMoED8XFo5Hfze888j04jjrOqJw811cgfkOIZdITzFwXIcCRT5sj2yXce sEFRgQvoHYTCcTxIgeTSDvgnxnNohOjHEyLw7EQjqe0SZI9+Z0nze7HQIMtnrkgfoUI68ITq/9Jx NaccWEpcPYIfosbFSjKEmiJoboNn/vGMYCGP/QAFsnOiFJQlmoMIyQDK4D1N+POvPviPpnEjNjOk YOutMMhOqt9CBuOvcPXiGl2PXOPrtINuUDtszPgD5ICL6EhPDHKiLH8j0oQwSv9oCMlN4mzwHEnp 8P4CBsWCBH+qVuUjnvnF6CBv/O7OPmemZEiP3NwDhj/riCCwMMPQQPCwhlhqFPhiDQkOLshwSCYP 0NQkRMkCBP+wWOHOHmkj7DKFtNMCTl0wwiHQ8CJEHM0iLv6NvutiIt8CBQuidNgweiCw4OHw+k/E twauuiUL6uYQcCOqQmCghhoQfiGmAmlsbQpQkr+uMMMlnt2CCOGsPsUw+PiRQorO0iChNw0mciER XxCGklsP4lIxQxKi+h0APtsDkRMvtPzoPxZrqjNPVNbxCLzFiDBmzRbwsChRHizRqibIBxGwpP3k pmYPpFrRriaPxCpxXiDxDCFRVPBxwiIRWCJQ3DzJyN5mlwPwgx1xMssP2Qfx1n1Chx9x+CnR/R/y BSBivtUSCHGHICEOokBSAm6Rpi2SGnGOAL7jFALkPGSGBviQpiQB7gqC3yIiEgfgMivOXyHq9iLx 0yQxYifEcjKyTCyxsiNpYKwCISFi7lDv5uoC9FIM+xCDIk9iNA9ofx6SQCrSiiDwTitjLSDRWryN wRliOEXt5yGyjiDu8i3pQiKyQSqiFOsiNxBCUPDknOJxJwgG0SgAAJaSZSNCWlmhkgJBSJJAMgNg NoHErShPuwpxLDrQimWutleg9nPiBvujWS4ACSRwHwvxCPim8AuGQSfRWF5TBF4ypy3TDCFzCRpm YPRRoHOsUx2umlrBSTDgAzESMiQSuAATDrRwBiasARfK1CMDhTSy6S7I2y8zQytR2m0CPO6iSTUi HjewrvBiDDovOzfSNzZDzzNktHOCJxsvBTYCBTViBS6iCqaTIRHNwQxxts+N5zjTAwyCBS4S5G0u mCDRyyrzQzsi+Jzk9wuwgzRgMzSiBITE9B4TcRykSktqNzkjHjfiHzyCCz7T1zFiMsltuQPiG0CN EwgRCTmFNPrS/NMRWT5T6S6t2l5yiQ4jDFTTODJvVmXTwN/CDzSAMhKiBOFu6utp90IUCwgzeRDo UxKiB0TBKgN0QlcUDCM0YiVt4r6lI0APoN4EhTqS1mdtdQULtHPvhFVy3AATRgAAAs4hXzbTozXx XQjUXzvQuT4D8jSULAA0bvgzwtDy2HVRfDzjbltzBxeUvzpzTS60CTsUszQEXOQxXlejfmRPBCHU xzrvkT0PvJYDNHOSslHjby0U+tvzxy4pJUb0qxU1Aq/jHhxEsi9PxQ8QTx6IXzyT5zizA0VzFxuU aHEyyUiDI1EmmzfNMUGUnUtTGCCVMt4NvU1xDwaEhS31HUpgATrQ30SUJw5H4kQTnOPG0v+IgU7C Pt41bCCQF0WC+y4BSTTAAVIiOIjVT0HK/xtP3iB1p1eTrPcVWVR1hVKoV0zPWIHxOslEAAJKqm+1 fRbUKDz1sQ9wpU9GcPO1X1213z60rTcQvGXRwySiB0AVN1YCFRERRNbpOiCkzz9CEWFDLBSVHAAS 5zT2FzkqvpFL41u2M0yVnkw0wVd1qQ3zMwAUssHDxVSVoT3H4RtWRCHw7yNQ8RxxezvjpUvCCS3r vTTOeVF152G2N1GMlmmxVqeVPzfj3V81gCCWKACG+y51rCBQo15UaCFsUQMymiC2oCB0q2fkZR61 yOPpGJszrj3johoPcqeWoT6UUj41uQjMlonUGxUkqgAROW4uP0o23QZ2qJzxWWPE5pk0cnPWX2wy NWKCHj9W5pkstzISTDhXFCB140vRJ3GJCIu3MQoWmlDW2Oi1bmWziRBjIH5InLj2AziluAQufLQT aUzM/QgyHM/ESRNzB1hWeKq1qPhXU2PsHWhr526iEyU1O2e0cCTxs27sl05FMv+08SX3YQpD3ErW 1WqNuiDXJiCUCWQ2PWrlqn626XfCDv+3iEpK30pWpIHROGtx21lCDVz0HCF3yRWTyWu1/UZQF0dX A1hWy2zTihoFM3WGt1dTRtx2v3oy/MTtjz9D4XqiF0BXKTbE9XlW5S2WhJ+XRF0IgB04AIl27iC3 c0pYDTzwa3RsPKbKvs93UjDESUZOGS2Xs37w34P15UJ3CVjE9XDw4iBWn0p1qX1xVvCUdiDomy2R Hj9W+nPWqiSjLYITq3j4ZyU2IUDjz4Wy7nBSyiDS6UyRBuHXu3oVBFpJbRyNcDzk92DiGWLtt4Px pMPpPpDzpW0WjCHS50MFuXyz/RK4btSCJShz4gCXKYoXb4h2GCNy0S01k3BUjXF4LXxNEx245iFZ F234giTAJV3CF4/MlzUyq5NKFyaV0SDiH1dS8YuiG2JSHlm34YUiaTgWNCJUjV45EVAzXC+ZL2Ki SX/ZHFKiH0GOuZTCiZXZRZh0Q5CECYx5iZk5lZl3Zid5dZmZoZRZnvI5o5q5rQ8yH5piB2k5r5u5 vCQZtE6TDZuEgwUypSaWrtv3+515qVdUjBSAJDZPp5v56HjY33Lkc1pJ9N5yxLOpkInYpo334I42 j2eoXjZxvOw566Fnc4UJ0wpXc5uZLnBUXaFCEKbXTaM2yZ/1z2s4h4knISxVC17aGaSnX4i2F4IA M5AAAAJDzvwFjVD4L0dXgK2zxXzUa6QEhGLuJ5taTafmxRX4Qzp2Km65+mEJ8Y96Ltj1GJ0oWRQ4 Qz5gCaix5GnwrK2alagatHTDI0BAA6WE8HOzORd4U5Vo4R4T/jgIe3HyS5b5Aav6DmXi8wVo4Xw6 H6t68HHTDhL6p1HSEuRFK6CCQOFghhX5hCL6fa87FEjxPywCWah7F7IntbHbJbK6tjBybbLbNbN7 ObO7PbP7QbQ7RbR7SbS7TbT7UbU7VbV7WbW7XbX7YbY7ZbZ7aba7bbb7cbc7dbd7ebe7fbf6GbD5 RRzinZ57gCzxxzc5dikyWlFR/biCKk/1DCSboGS7jzUZ8TZZaCMZD7lZXimbqiYOXjSC/sQk3Ngg fsIlRTtnCjVyTOUCTlV7uiP7w7KbrzdDIEdIkRAxLlJI0QpGRG700C+DmpUP0LRHNbADel4VVTzi MbwksYmEhNDJHiCE5Ru7rcMq1ZjQzpNC87/SMcEiDmmj6iSZ4kO65yMPqb+77zZXzvevJcWST2qa 1G1lvyVOMI/b1ZyzGQqlNLrttj4l68NRzO2tsb+CLD7q/74DiDQLMHFaLM/iFj6GEj8El8XtFjPk gZ5EPGzE18fDNaZcqwgl+JH8D8duQcumeHMETMr8W76IdjuEfkUuvymbAOgwcS0E0mZxBP0p/DXR u8Uz9lT2O3plMD6UkCGcDLVJHklb18e8QnMWOiGk7DMKOr8DYE5QhSKG8R5i+Xp0UxAFsQOaccYI vad6xmlEiWVlLcHGRkRcCwmLVDTdNLzGoPjEb83D283iQpNFCuIM2cfOgl27ktslhdSb28srAKeL ZyKGOk8Jz4rQSzWxdQsrBFC5GmRq9YsQ3119nkbDNJSgf9HGJr6i9cEmunVY5kx81kW7iScdtayc aU2MzxLmZ8KDYEf1BFrEyD7diSeCCyodeCNJNQAxIGSPRzAFdlAUPiBmTjYy2UPcb0hvtsjhKOn8 2eJrNjwFmT2m3HJo0kpl5FLlMlgnQksmF+HwK39aw9B9cq98xGPd2CEFkM5zg6rFnxx89eL+D97E ieVJwlCEOJ99IknLSFnD4ZI+B7sCERc9SVZZaG1R39IeUFxAsBvGgPeRbF1enQq8VcRlucS87xIC CFPGpCFdNXBQVeNcZuGF5+BSwFZKJFynWAflzlsuv+PiC+QlIzA+lePjr+5GUsF8OOWcwt50ysj9 j92iFer/B+7J/EdRmvkdb9oF4+/I2exOWeliNwN9hQxariBGbmC9wcZCyw9LreGdqcg+pGdfKiGn WKJmr3hfDEtvrA2B4UUlMnJVYjrGF+siDG+Gtckwx75dveTiFHWfZu7T2+88ozW+RGb/j8o/OHMn MOwo018ICFvFJ77Cw+1/veXeD7/CGm5GsOx/kFUpjU9+pd48I/gCjGfHRigev/qyCfw/7f8lo/V/ 9f+//CAACBQOCQWDQeEQmFQuGQ2HQ+IRGJROKRWLReMRmNRuOR2PR+QSGRSOSSWTSeUSmVSuWS2X S+YTGZTOaTWbTecTmdTueT2fT+gUGhUOiUWjUekUmlUumU2nU+oVGpVOqVWrVesVmtVuuV2vV+wW GxWOyWWzWe0Wm1Wu2W23W+4XG5XO6XW7Xe8Xm9Xu+X2/X/AYHBYPCYXDYfEYnFYvGY3HY/IZHJZP KZXLZfMZnNZvOZ3PZ/QaHRaPSaXTafUanVavWa3Xa/YbHZbPabXbbfcbndbveb3fb/gcHhcPicXj cfkcnlcvmc3nc/odHpdPqdXrdfsdntdvud3vd/wXqAgKZW5kc3RyZWFtCmVuZG9iagoxMCAwIG9i ago1NjYzCmVuZG9iagoxMSAwIG9iagpbIC9JbmRleGVkIC9EZXZpY2VSR0IgMjU1IDE0IDAgUiBd CmVuZG9iagoxMiAwIG9iago8PAovRmlsdGVyIFsgL0xaV0RlY29kZSBdCi9XaWR0aCAxMDYKL0hl aWdodCAxOAovQ29sb3JTcGFjZSAxMSAwIFIKL0JpdHNQZXJDb21wb25lbnQgOAovTGVuZ3RoIDEz IDAgUgo+PgpzdHJlYW0KgD+gUDgb/g0HhEJgb9fsChsHf0NiMMhkFhL7fb9jD8i0JhUOiMdj0Qgj +kj+jj8kcrlktl0vmExmUzmk1m03mr4ejzcTdabtdrodjtebudbyeLtek9ddGejfbjtZTIcLodLs c7wcDXb7MbDcZzjcTlcTidzpczxfD3fbOZrjaLSczcbbrbzfcDrdrkpDvdDrckYfbTabYdrpd7qc laurDYbhaLTczhu7sd7mazhZzecLabrlb040Wj0ml02n1EujD6cDcbjlb7oaDKzTMcrOZjkV6uab abTrsrvaTVc7qdLqc7ob7ZazXbrbcHPdC+XjbXq7bblcrxvDuzzsamfYjQZbCYLIZDAaLXaLhfL4 fjMZjjYTCby7XTaYjGb7DYhwGybZ0nAcZunadZ0GiZ5qm4bJxneo7UwlCcKQrCycJKiKOIqiiKwz D6BI8gaMH6fh+IokyDQyisSRNFEVobFyRQvGkaxtG8bomfB5x4fB5HWex3Hie56HqfJ6HkfJ4nqe 56nwex8IGtZ+NgeR4L+xJznYeB0nge54HofKeHecBwncbx5HoeCDoqw56HwtZ7SOhp+nOeh1nGeJ ynyfh8oOfR7nyeRzqNMx3HGdx7nieMTn7RJ4nEeBysWcyzG+cJ1G+ch0U2cR1SafJ8nrUZ7Hmep9 nueSdTke06RGfcTxOkJ5naex5S6dJynAbx1m4cZ5HIdx6HidZ6HUdp6nWjqQx+eZ8HiekSn5WB9v ge9rI2gZ9SYflAoHE9UHseiM1kiUSxLPh8neep2pQjkQHueZ5HdINVHnMJ5nefCnHWesi32eR6nU eJ5HZKB5TTQSUxmkZ51SWxnlqVBplYTZklKV5iluXZemBjxhGYWZgm+Yxqn6fJ9nta5mGkZ5fGoX hgGsXxfmyYZnG4ahiGKZZUk8UJhFcWjIGyjR+H1ExmG0Z5inC8ZymllB9GAahkGCaBhnQdR2Iodx yPAXBlmIXhfGKZ5gm8dBt3WeBlm8aJWGUWRXFqW5gFUVxhlWW5nFqYxvGQa56Heehmm/qxuGEZpw mmWBklsZBnmafXKHKaBunEaLlmQbJ1UwbpwG0a5wmoV+4FUaRXmCbBjmWZ3XmUZRsGWZ595Qc50n ke57n1BhqmwcZrHAdhxGabxqGqcRtGKY5lGkYJqHqdx5GkWZlZsapqHSapjHOY5em4XxoHKahp+O aJqGobRrG1YZ5mrxRqFznBonAfXbViaxyGqYhwmONAcDqRcC0FkKwWQxBaC5GaLEYgwhLi2GgL55 zSxojbGWMkcAzB0jzHSuAl61x7jRG0NMX4vxjtVd+LgzYwRrDlG4X8cr0zED4cIO4146hzDrHeO8 dyRnpJgHcOheY4ChDfHMZMv43h0j1HIOsfQ9FbD1g4WhPA5x4jnHeOEaA4h2jja2Oleich5pbHYN scY8FjpLVuOMrKnh0DYHKOwxY744jpiMO0c0OxvjnHyPBZw9B7jbGqNcbg14zP6HGM8bo8RzFKHa PEcBmR2jnHaOUrg9x2sBX8kZYY9B3STHYwVhA5V+pgHSp4fSpkxD2HrKaSg5HMDyXuOodCS41Jah wluDY63gDuGqN8no3VNxNiCcg4A1RyDtG8Ooew7IrrBUqOwdQ1xyD0lIO0cI51qj5HY1och2X9xs GpNk146BwlXNiOUZ44B4qbmcU16Q448oQHlE8e65yWD6HwPobAvRrDVFuM8bjVBfCgF4zAaKtx4T cHgPtgK6h5jfF0M0ZwsRmjiGGNVWw9ht0XGgLwaQyBVjDGsLQY43RbjIHELUZA6BajHHoNwcg9h4 j2GwLoaw6RqDjGu9cZYvhqvPgAM4bA7lPD4keOoYY0RzjSG8uweg0xWjMGyLoaA1aMjSGM6IX40B ri6GWOY9Q6hejNHzDqVo9RrjFG6NkXw1xrC9GiOIao4yBzYHUOobY5FUj1HQ1cb4sRijXggPOPI8 R1DyG8M4cA4pxjcGOZlq45xkjXHmNocQ8jwjbhUM4XA1RvDPHG8QdQ06SDjGmr4aw3RsUvG2K8ZA 4xTC7HKK0X40hSC9GkLB2Qu4RDHG4N8aQ5C5x8SgOAZ0ZmSjtGgNwfSUBuDGGyOAYA1bOILF8M8b 7whvjRG6NcX4zxwjFGmt0fJ0xnjrqWOIZI2k+j6HUOObELT9DRsQO0lhKB+j1koPKYQ7xxDpHGMw a9PBvjdGoNwvw7JUj2HfL8eI1BvjwGqOAd40RuDugqbIbQ6htDhm+OEb4zhtDxHQO5dw/Z9ruIWu Vc5DF3omv0RMgmLiFqwQ6RRRqsMUz7aMitd+MEXESIWSAhb90fJMSGn1WCJ59KwZQPyfdDh6j8SY P1++Kn7u8H2PrGC7spD4VhlnJqULzD5enlgjK1J9pPTgoFapGWkY1JShvGrSMkzbWohzMs+0wLfU DlLJA+0/tIH0yhQSrWUEsVQPgaQw8CDGPWM8bY0RhHrGKNUzQ22BDwH1KYY42BtC3GkO0ZA1R0DM GoOUaI1huDPGwOIbw5xxPCkSNweWAb9I415r3X2v9gEnHom/Q5GciEEvzkVhhL0M7B2ds/aG0Sa3 6H2PUe2XU/EJWmrFDp79sD8J2lEhg9x3jwlYPHPCUsxD4ZQnB+6fHKbHIESmfY9lYkexwR1DmOk+ pPVU4QfQ8h7cD22nB2yfMZIuyknzdidNryAueoF3bvHdv3VhJ9YcPSJox44QxJ0gOJO8HnTXaXJT UyfHON8ao1oLjCGMLwaYyoMDAF+Nsa41DkjnHkLUWI1hdC7G5zIcTlB8jUGbCYZQuhgjBGKTsewx RiDeF8Lga4rRTDOFmLEbIyhljlWuPYZg2xhDEGiLkYAxhd15HaMYYo4BhC+G42MbSTx8jlisL0YQ 2uVjVHhGgYwxhcDAGELUXoxBlCdEwL5XY7DyOZGiOgZQzRyjIGWN05Y1h3jnr4WsY4zBjC/F8M4Z NwBfi9G23MaY3xvDuGaM0cgshZDKMiMAZ42qljbGdBcaoshWjGFGKAZIvRclfc7yb4xpT3j4HPFg c18hvjaLQOLACkR1jqHo5Qfg7h3j2HgkNUI+yBqilYPP7m5kXD32uvIfI7Ye7llYkbQ4+Rx4gm6O 4cw5ftpyGeM8c42RsE8ByN0GkF/h0B2kwIpMuh9lch2jEh5CyB5CoClB5s0Pth3F6NhpVuBh8Mqt 4iGoeOMlRwJlRh9BzBzkeQJi1qHF7ikrEkth4tzK8mCohJaB6B2mDN4vjwcwdQdweQewfQfwgQgw hQhwiQiwjQjwkQkwlQlwmEbiAgplbmRzdHJlYW0KZW5kb2JqCjEzIDAgb2JqCjI0NTUKZW5kb2Jq CjE0IDAgb2JqCjw8Ci9MZW5ndGggMTUgMCBSCj4+CnN0cmVhbQr///8gqGJL7zgJolY+fVTQ4g2F FxJTa5OBYydoVO3jaN+PiIfx03cp3RqAHJfU7Xrhc5L0xv6HSGGvsLWckx17I6YDFHp6PViUvXQs kmKmdNU5aZw38OSYoJROPChsuEsSu2CMNZ7lyVtZ9e68nGOR1cwuDL0SpV2n9JnQYFEbcw18/0Ia 5Qx2PgJk+5/HjHSUuoFRzSeudBtIRHuaYO6n3O7q9tP3bBL60Q2ZmZoOLVWPfyK2LpbRdttNETs7 uRgqpA/9m3wQlU4dL+e3PRUNzJQvg8LGVTmhokvd3gX2CakFBkWBF9vPNAq37EfM+RRhKZck7+1e kZCqb26vZXdYa36d7ZZ4vcqDdLfLQbHfo9p3yMpkJlz10MtjfzHb2JxadYrw7ke7crtzPf0kHKD/ lGnK+Y8m7mDyUt8jLbjAiC5KeR2SNY9OqMxLzenszH1VlnflvWVFr7cl0+XdlG0L3ucpcBy4vsSF CpFv917tTPVkMbPJd2KAnTZlesrThqm6rxnWaNib7eMtXNqLSSeBrVk0d9CX923NXeiXMG9A6x5a wYYzXXQWitHxFhoYl8hxzEBBYzivMJWXyMYGCbElZHOsl9Agrlrxn3AMtwjVKNQVajdNGWjjsTGp uDpa3Z/OiTaequT4nIRpqDtxfmRFk8594OjlxJkXbVJSyC/xlrknNGQMLQCRlqnMCCcxTbr/ypvo sF+CyM3UGpUECyu+M2AiQI4j0SXMni3zz3quz0VKuPaqOr53D9kNE+Q50Ria9FgoFylN5Mh62Jf1 h2c70R8yfFrw9GnKAX2uO0/G1UMf/ltJSz8RxhepvJ4R93AwKe2LGuH05ONxkx/AWvQEefNfwj6f 1AW2fcFVjrjGv+KzSvyVP+F5sXSYcc6NdUiA1Qu/dN/EK12Gges/SKsh/PYekTX/C+Z0o1hDMc6M sqOXcRh2NkPTvcW//A1rHQlhPJuXPKZ+sErW9HylgC5IGKBhjtelYpRqIpF4ja+B7+sdhifDBNgO 282KgE65yWYKZW5kc3RyZWFtCmVuZG9iagoxNSAwIG9iago3NjgKZW5kb2JqCnhyZWYKMCAxNgow MDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDAwMTAgMDAwMDAgbiAKMDAwMDAwMDE4NSAwMDAwMCBu IAowMDAwMDAwMjM0IDAwMDAwIG4gCjAwMDAwMDAyOTMgMDAwMDAgbiAKMDAwMDAwMDQ5NyAwMDAw MCBuIAowMDAwMDAwNTgwIDAwMDAwIG4gCjAwMDAwMDA1OTggMDAwMDAgbiAKMDAwMDAwMDYzNiAw MDAwMCBuIAowMDAwMDAwNzQ0IDAwMDAwIG4gCjAwMDAwMDY1ODggMDAwMDAgbiAKMDAwMDAwNjYw OSAwMDAwMCBuIAowMDAwMDA2NjYwIDAwMDAwIG4gCjAwMDAwMDkyNTQgMDAwMDAgbiAKMDAwMDAw OTI3NSAwMDAwMCBuIAowMDAwMDEwMDk4IDAwMDAwIG4gCnRyYWlsZXIKPDwKL1NpemUgMTYKL0lu Zm8gMSAwIFIKL1Jvb3QgMiAwIFIKPj4Kc3RhcnR4cmVmCjEwMTE4CiUlRU9GCg== --------------010401080006030604020402-- From egjlu@garytregaskis.com Wed Jul 11 23:11:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8p5e-00083v-O4 for nfsv4-archive@lists.ietf.org; Wed, 11 Jul 2007 23:11:38 -0400 Received: from [124.6.165.157] (helo=onlpzk) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I8p5Z-0001WC-Qd for nfsv4-archive@lists.ietf.org; Wed, 11 Jul 2007 23:11:38 -0400 Received: from jlf ([81.178.204.196]) by onlpzk (8.13.1/8.13.1) with SMTP id l6CHokEw068596; Thu, 12 Jul 2007 10:50:46 -0700 Message-ID: <469669A6.1020202@garytregaskis.com> Date: Thu, 12 Jul 2007 10:49:26 -0700 From: Milligan User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: "It is extremely rare for people with Asperger syndrome to commit violent crimes. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.7 (+) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Vision Airships Global Expansion! BANGKOK, THAILAND, Jul 09, 2007 (MARKET WIRE via COMTEX) - Vision Airships Inc. (PINKSHEETS: VPSN) - The company wishes to announce that it has finalized arrangements for funding for its global expansion. Check out the news and get on VPSN first thing Thursday! They then become inflamed and clogged. Can anthrax be treated? These particles can penetrate deep into the lung and are known to worsen existing heart or respiratory problems. Attacks are caused by the airways over-reacting to certain environmental factors. The US Environmental Protection Agency has an ongoing research programme to look into arsenic in the environment and to establish what constitutes a safe level. Treatment consists of two main factors - environmental control and medication. "Now with fewer of them, their bodies are turning over to asthma instead. The first, cutaneous anthrax, is the least serious of the three, and produces a skin lesion, which is rarely painful. It may be that in the past when all children had a lot of viral infections their bodies were defending themselves against infection. They can be taken in liquid, inhaled or tablet form. The aim is to create a solid, and hopefully painfree, structure. The risk that a patient will experience pain if awake is considerably less than this. If death does not occur at this stage, it will happen a few days when the kidney fails. Most people who realise they have severe allergy reactions carry a ready-filled adrenaline injector with them at all times. What happens when the clotting mechanism goes wrong? For immediate effect, such as after a DVT or a pulmonary embolism, an intravenous dose is given to ensure it is more rapidly delivered to the blood stream. It most commonly affects the joints of the fingers, knees, hips, and spine. Those at highest risk in the UK are those who directly handle dead animals, such as abattoir workers and tanners. After repeated attacks, this additional bone growth can surround the disc. Genetic factors play a role, but not in every case. The third is respiratory anthrax, which happens when spores are breathed in by the patient and lodge in the lung. Lesions appear on the skin which are due to small clots in the blood vessels under the surface. Most people who realise they have severe allergy reactions carry a ready-filled adrenaline injector with them at all times. However, experts say there is no known link between Asperger's and violent crime. Women are thought to be twice as likely to suffer from them as men. This disturbs the delicate balance required to ensure that cartilage builds up, breaks down and is replaced. Blood coagulation is triggered by blood cells called platelets which, through a series of chemical reactions, produce a substance called thrombin. After repeated attacks, this additional bone growth can surround the disc. Low dose aspirin pills are usually given an enteric coating which protects the stomach tissue. If started early and continued regularly - every day - the result is excellent with little restriction of movement or deformity. What causes anxiety disorders and what are their symptoms? What triggers an asthma attack? Taking low doses of aspirin daily is one of the cheapest and most effective means of preventing a further attack. They are described as feeling similar to taking deep breaths of very cold air in winter. Asbestosis, for example, leads to a thickening of the lower part of the lungs, making them less elastic and causing breathing problems. The air may make a wheezing or whistling sound. For immediate effect, such as after a DVT or a pulmonary embolism, an intravenous dose is given to ensure it is more rapidly delivered to the blood stream. These provide temporary relief from asthma symptoms but do not tackle the underlying inflammation. Arsenic can kill humans quickly if consumed in large amounts, although small, long-term exposure can lead to a much slower death or other illness. These exercises are very specialised and have to be done irrespective of the patient's lifestyle. Often someone with Asperger's may be obsessed with complex topics such as music, history, or the weather, and have above average verbal skills. The horse serum used in the makeup of some vaccines can also cause anaphylactic shock. Obsessive compulsive disorders often start in adolescene or early adulthood and may be linked to other mental health problems, such as depression. The condition varies a great deal from one person to another. The effects of heparin on clotting can be measured with a test called APTT and, as with warfarin, the dose needs to be adjusted to make sure it is at the right therapeutic level. However, experts say there is no known link between Asperger's and violent crime. Symptoms of anthrax normally develop within two days of exposure. "There are simple ones - women who smoke during pregnancy are much more likely to have asthmatic children. "There are simple ones - women who smoke during pregnancy are much more likely to have asthmatic children. Arthroplasty: The rebuilding or replacement of an entire joint. The two forms act in a slightly different way on the thrombin in the blood and have the effect of prolonging the time a clot takes to form. Attacks can be only occasional or frequent. From nfsv4-bounces@ietf.org Thu Jul 12 05:21:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8urB-0006ym-RO; Thu, 12 Jul 2007 05:21:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ur9-0006sb-VI for nfsv4@ietf.org; Thu, 12 Jul 2007 05:21:04 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8uqu-0003wy-Gd for nfsv4@ietf.org; Thu, 12 Jul 2007 05:21:03 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6C9Jxn2002740 for ; Thu, 12 Jul 2007 05:19:59 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6C9Jp58000778 for ; Thu, 12 Jul 2007 05:19:59 -0400 (EDT) From: Glasgow_Jason@emc.com Received: from CORPUSMX40A.corp.emc.com ([10.254.64.48]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 05:19:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jul 2007 05:19:45 -0400 Message-ID: <39CF2A4B63947142A66EAA65B2FDF2F00491A274@CORPUSMX40A.corp.emc.com> In-Reply-To: <94967674-4D00-40F4-8D39-E64813F7C6BA@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Using Mandatory file locks with block layouts Thread-Index: AcfCpj4onH5wX+IlSHGPszIKs+jMqwAVDfDQ References: <94967674-4D00-40F4-8D39-E64813F7C6BA@sun.com> To: X-OriginalArrivalTime: 12 Jul 2007 09:19:46.0529 (UTC) FILETIME=[CA219D10:01C7C465] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [nfsv4] Using Mandatory file locks with block layouts X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I have been reviewing the NFS-V41 draft 12 and I have an issue with section 12.5.1. The language in the last paragraph seems to preclude using mandatory locks in conjunction with block layouts. I say this because I do not expect block devices to be able to implement byte/octet/record range locking. Perhaps we need a change the spec to say If the storage device is incapable of providing this check in the presence of mandatory file locks, the metadata server then MUST NOT grant intersecting layouts and added "intersecting"----^ mandatory file locks simultaneously to different clients. ^*******added********^ Comments? Jason Glasgow EMC http://www.nfsv4-editor.org/drafts/drafts.html 12.5.1. Guarantees Provided by Layouts Layouts delegate to the client the ability to access data located at a storage device with the appropriate storage protocol. .... =20 .... In the presence of pNFS functionality, mandatory file locks MUST behave as they would without pNFS. Therefore, if mandatory file locks and layouts are provided simultaneously, the storage device MUST be able to enforce the mandatory file locks. For example, if ^**^ one client obtains a mandatory lock and a second client accesses the storage device, the storage device MUST appropriately restrict I/O for the byte range of the mandatory file lock. If the storage device is incapable of providing this check in the presence of mandatory file locks, the metadata server then MUST NOT grant layouts and ^********^ mandatory file locks simultaneously. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 12 09:25:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8yfn-0006gp-Jc; Thu, 12 Jul 2007 09:25:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8yfl-0006gV-RG for nfsv4@ietf.org; Thu, 12 Jul 2007 09:25:33 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8yfl-0000vP-F2 for nfsv4@ietf.org; Thu, 12 Jul 2007 09:25:33 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6CDOhxk015148; Thu, 12 Jul 2007 09:24:43 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 12 Jul 2007 09:24:43 -0400 Received: from [192.168.0.140] ([172.17.28.123]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 09:24:42 -0400 Message-ID: <46962B99.4090404@panasas.com> Date: Thu, 12 Jul 2007 16:24:41 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Glasgow_Jason@emc.com Subject: Re: [nfsv4] Using Mandatory file locks with block layouts References: <94967674-4D00-40F4-8D39-E64813F7C6BA@sun.com> <39CF2A4B63947142A66EAA65B2FDF2F00491A274@CORPUSMX40A.corp.emc.com> In-Reply-To: <39CF2A4B63947142A66EAA65B2FDF2F00491A274@CORPUSMX40A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2007 13:24:43.0088 (UTC) FILETIME=[01F68D00:01C7C488] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Well the server can't mandate the byte range locks otherwise. I don't see how you can support mandatory locking when you allow direct client access to the device without being able to enforce the locks there. Without layouts the client has to funnel through the server where and I/O can be intercepted and mandatory locks can be enforced. A client that previously tried I/O at the server without holding a lock will now go directly to storage and the I/O will go through although it must not when mandatory locks are in place and there's a lock intersecting with the unlock I/O range. Benny Glasgow_Jason@emc.com wrote: > I have been reviewing the NFS-V41 draft 12 and I have an issue with > section 12.5.1. The language in the last paragraph seems to preclude > using mandatory locks in conjunction with block layouts. I say this > because I do not expect block devices to be able to implement > byte/octet/record range locking. > > Perhaps we need a change the spec to say > > If the storage device > is incapable of providing this check in the presence of mandatory > file locks, the metadata server then MUST NOT grant intersecting > layouts and > added "intersecting"----^ > mandatory file locks simultaneously to different clients. > ^*******added********^ > > > Comments? > > Jason Glasgow > EMC > > > > > http://www.nfsv4-editor.org/drafts/drafts.html > > 12.5.1. Guarantees Provided by Layouts > > Layouts delegate to the client the ability to access data located at > a storage device with the appropriate storage protocol. .... > > .... > > In the presence of pNFS functionality, mandatory file locks MUST > behave as they would without pNFS. Therefore, if mandatory file > locks and layouts are provided simultaneously, the storage device > MUST be able to enforce the mandatory file locks. For example, if > ^**^ > one client obtains a mandatory lock and a second client accesses the > storage device, the storage device MUST appropriately restrict I/O > for the byte range of the mandatory file lock. If the storage device > is incapable of providing this check in the presence of mandatory > file locks, the metadata server then MUST NOT grant layouts and > ^********^ > mandatory file locks simultaneously. > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 12 10:56:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I905d-0003pz-EL; Thu, 12 Jul 2007 10:56:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I905b-0003nW-TT for nfsv4@ietf.org; Thu, 12 Jul 2007 10:56:19 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I905b-0003J6-IN for nfsv4@ietf.org; Thu, 12 Jul 2007 10:56:19 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6CEtkxe012950; Thu, 12 Jul 2007 10:55:47 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6CEtYxA004912; Thu, 12 Jul 2007 10:55:45 -0400 (EDT) From: Glasgow_Jason@emc.com Received: from CORPUSMX40A.corp.emc.com ([10.254.64.48]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 10:55:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Using Mandatory file locks with block layouts Date: Thu, 12 Jul 2007 10:55:43 -0400 Message-ID: <39CF2A4B63947142A66EAA65B2FDF2F00491A4B0@CORPUSMX40A.corp.emc.com> In-Reply-To: <46962B99.4090404@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Using Mandatory file locks with block layouts Thread-Index: AcfEiAgKIC5SIl2XSOubLWVOOlKpAwACLb4w References: <94967674-4D00-40F4-8D39-E64813F7C6BA@sun.com> <39CF2A4B63947142A66EAA65B2FDF2F00491A274@CORPUSMX40A.corp.emc.com> <46962B99.4090404@panasas.com> To: X-OriginalArrivalTime: 12 Jul 2007 14:55:45.0521 (UTC) FILETIME=[B9D3AE10:01C7C494] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org For block layout drivers, the server can mandate locks as long as the locks are on sector boundaries, and as long as the server only grants to a client layouts that are compatible with the mandatory locks previously acquired by that client. It is a limitation, but not nearly as serious a limitation as preventing the use of mandatory locks for block layout drivers. -Jason -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Thursday, July 12, 2007 9:25 AM To: Glasgow, Jason Cc: nfsv4@ietf.org Subject: Re: [nfsv4] Using Mandatory file locks with block layouts Well the server can't mandate the byte range locks otherwise. I don't see how you can support mandatory locking when you allow direct client access to the device without being able to enforce the locks there. Without layouts the client has to funnel through the server where and I/O can be intercepted and mandatory locks can be enforced. A client that previously tried I/O at the server without holding a lock will now go directly to storage and the I/O will go through although it must not when mandatory locks are in place and there's a lock intersecting with the unlock I/O range. Benny Glasgow_Jason@emc.com wrote: > I have been reviewing the NFS-V41 draft 12 and I have an issue with > section 12.5.1. The language in the last paragraph seems to preclude > using mandatory locks in conjunction with block layouts. I say this > because I do not expect block devices to be able to implement > byte/octet/record range locking. >=20 > Perhaps we need a change the spec to say >=20 > If the storage device > is incapable of providing this check in the presence of mandatory > file locks, the metadata server then MUST NOT grant intersecting > layouts and > added "intersecting"----^ > mandatory file locks simultaneously to different clients. > ^*******added********^ >=20 >=20 > Comments? >=20 > Jason Glasgow > EMC >=20 >=20 >=20 >=20 > http://www.nfsv4-editor.org/drafts/drafts.html >=20 > 12.5.1. Guarantees Provided by Layouts >=20 > Layouts delegate to the client the ability to access data located at > a storage device with the appropriate storage protocol. .... > =20 > .... >=20 > In the presence of pNFS functionality, mandatory file locks MUST > behave as they would without pNFS. Therefore, if mandatory file > locks and layouts are provided simultaneously, the storage device > MUST be able to enforce the mandatory file locks. For example, if > ^**^ > one client obtains a mandatory lock and a second client accesses the > storage device, the storage device MUST appropriately restrict I/O > for the byte range of the mandatory file lock. If the storage device > is incapable of providing this check in the presence of mandatory > file locks, the metadata server then MUST NOT grant layouts and > ^********^ > mandatory file locks simultaneously. >=20 >=20 >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 12 11:19:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90SC-000866-J8; Thu, 12 Jul 2007 11:19:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90S9-000805-HI for nfsv4@ietf.org; Thu, 12 Jul 2007 11:19:37 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I90S8-00048m-Tw for nfsv4@ietf.org; Thu, 12 Jul 2007 11:19:37 -0400 X-IronPort-AV: E=Sophos;i="4.16,533,1175497200"; d="scan'208";a="81261360" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 12 Jul 2007 08:19:27 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6CFJ8jD022164; Thu, 12 Jul 2007 08:19:24 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 08:19:16 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 08:19:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Using Mandatory file locks with block layouts Date: Thu, 12 Jul 2007 11:19:15 -0400 Message-ID: In-Reply-To: <39CF2A4B63947142A66EAA65B2FDF2F00491A274@CORPUSMX40A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Using Mandatory file locks with block layouts Thread-Index: AcfCpj4onH5wX+IlSHGPszIKs+jMqwAVDfDQAGdN6CA= From: "Noveck, Dave" To: , X-OriginalArrivalTime: 12 Jul 2007 15:19:16.0671 (UTC) FILETIME=[02F014F0:01C7C498] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org What this would require is that the client itself enforce the mandatory locks with respect to other owners in the same client. That's doable but the spec has to make=20 clear that that is its job, since there is no way for the combination meta-data server and data server to do it.=20 -----Original Message----- From: Glasgow_Jason@emc.com [mailto:Glasgow_Jason@emc.com]=20 Sent: Thursday, July 12, 2007 5:20 AM To: nfsv4@ietf.org Subject: [nfsv4] Using Mandatory file locks with block layouts I have been reviewing the NFS-V41 draft 12 and I have an issue with section 12.5.1. The language in the last paragraph seems to preclude using mandatory locks in conjunction with block layouts. I say this because I do not expect block devices to be able to implement byte/octet/record range locking. Perhaps we need a change the spec to say If the storage device is incapable of providing this check in the presence of mandatory file locks, the metadata server then MUST NOT grant intersecting layouts and added "intersecting"----^ mandatory file locks simultaneously to different clients. ^*******added********^ Comments? Jason Glasgow EMC http://www.nfsv4-editor.org/drafts/drafts.html 12.5.1. Guarantees Provided by Layouts Layouts delegate to the client the ability to access data located at a storage device with the appropriate storage protocol. .... =20 .... In the presence of pNFS functionality, mandatory file locks MUST behave as they would without pNFS. Therefore, if mandatory file locks and layouts are provided simultaneously, the storage device MUST be able to enforce the mandatory file locks. For example, if ^**^ one client obtains a mandatory lock and a second client accesses the storage device, the storage device MUST appropriately restrict I/O for the byte range of the mandatory file lock. If the storage device is incapable of providing this check in the presence of mandatory file locks, the metadata server then MUST NOT grant layouts and ^********^ mandatory file locks simultaneously. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 12 11:19:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90SQ-0000bZ-Fd; Thu, 12 Jul 2007 11:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90SO-0000UV-LY for nfsv4@ietf.org; Thu, 12 Jul 2007 11:19:52 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I90Ry-0005ZM-F1 for nfsv4@ietf.org; Thu, 12 Jul 2007 11:19:52 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6CFJLpx021694; Thu, 12 Jul 2007 11:19:21 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 12 Jul 2007 11:19:21 -0400 Received: from [192.168.0.140] ([172.17.28.123]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 11:19:20 -0400 Message-ID: <46964677.8040208@panasas.com> Date: Thu, 12 Jul 2007 18:19:19 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Glasgow_Jason@emc.com Subject: Re: [nfsv4] Using Mandatory file locks with block layouts References: <94967674-4D00-40F4-8D39-E64813F7C6BA@sun.com> <39CF2A4B63947142A66EAA65B2FDF2F00491A274@CORPUSMX40A.corp.emc.com> <46962B99.4090404@panasas.com> <39CF2A4B63947142A66EAA65B2FDF2F00491A4B0@CORPUSMX40A.corp.emc.com> In-Reply-To: <39CF2A4B63947142A66EAA65B2FDF2F00491A4B0@CORPUSMX40A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2007 15:19:21.0095 (UTC) FILETIME=[05932170:01C7C498] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org If I understand you correctly, you can dispatch layouts iff a client has a byte range lock covering the layout byte range, right? If so I think you're covered by the "simultaneously to different clients" clause. Benny Glasgow_Jason@emc.com wrote: > For block layout drivers, the server can mandate locks as long as the > locks are on sector boundaries, and as long as the server only grants to > a client layouts that are compatible with the mandatory locks previously > acquired by that client. > > It is a limitation, but not nearly as serious a limitation as preventing > the use of mandatory locks for block layout drivers. > > -Jason > > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com] > Sent: Thursday, July 12, 2007 9:25 AM > To: Glasgow, Jason > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] Using Mandatory file locks with block layouts > > Well the server can't mandate the byte range locks otherwise. > I don't see how you can support mandatory locking when you allow > direct client access to the device without being able to enforce > the locks there. Without layouts the client has to funnel through > the server where and I/O can be intercepted and mandatory locks > can be enforced. A client that previously tried I/O at the server > without holding a lock will now go directly to storage and the I/O > will go through although it must not when mandatory locks are in place > and there's a lock intersecting with the unlock I/O range. > > Benny > > Glasgow_Jason@emc.com wrote: >> I have been reviewing the NFS-V41 draft 12 and I have an issue with >> section 12.5.1. The language in the last paragraph seems to preclude >> using mandatory locks in conjunction with block layouts. I say this >> because I do not expect block devices to be able to implement >> byte/octet/record range locking. >> >> Perhaps we need a change the spec to say >> >> If the storage device >> is incapable of providing this check in the presence of mandatory >> file locks, the metadata server then MUST NOT grant intersecting >> layouts and >> added "intersecting"----^ >> mandatory file locks simultaneously to different clients. >> ^*******added********^ >> >> >> Comments? >> >> Jason Glasgow >> EMC >> >> >> >> >> http://www.nfsv4-editor.org/drafts/drafts.html >> >> 12.5.1. Guarantees Provided by Layouts >> >> Layouts delegate to the client the ability to access data located > at >> a storage device with the appropriate storage protocol. .... >> >> .... >> >> In the presence of pNFS functionality, mandatory file locks MUST >> behave as they would without pNFS. Therefore, if mandatory file >> locks and layouts are provided simultaneously, the storage device >> MUST be able to enforce the mandatory file locks. For example, if >> ^**^ >> one client obtains a mandatory lock and a second client accesses > the >> storage device, the storage device MUST appropriately restrict I/O >> for the byte range of the mandatory file lock. If the storage > device >> is incapable of providing this check in the presence of mandatory >> file locks, the metadata server then MUST NOT grant layouts and >> ^********^ >> mandatory file locks simultaneously. >> >> >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 12 13:55:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92sU-0001LW-LQ; Thu, 12 Jul 2007 13:54:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92sT-0001IL-1F for nfsv4@ietf.org; Thu, 12 Jul 2007 13:54:57 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I92sO-0006xc-EM for nfsv4@ietf.org; Thu, 12 Jul 2007 13:54:57 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6CHsqCC023400 for ; Thu, 12 Jul 2007 17:54:52 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JL200801UUQRC00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 12 Jul 2007 11:54:52 -0600 (MDT) Received: from [192.168.0.3] (adsl-71-145-187-12.dsl.austtx.sbcglobal.net [71.145.187.12]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JL2008OZV3FWU00@mail-amer.sun.com>; Thu, 12 Jul 2007 11:54:51 -0600 (MDT) Date: Thu, 12 Jul 2007 12:54:57 -0500 From: Spencer Shepler Subject: Re: [nfsv4] Using Mandatory file locks with block layouts In-reply-to: <39CF2A4B63947142A66EAA65B2FDF2F00491A4B0@CORPUSMX40A.corp.emc.com> To: Glasgow_Jason@emc.com Message-id: <7A3A61AA-C81B-4EFE-89A1-E5A38A9C5107@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <94967674-4D00-40F4-8D39-E64813F7C6BA@sun.com> <39CF2A4B63947142A66EAA65B2FDF2F00491A274@CORPUSMX40A.corp.emc.com> <46962B99.4090404@panasas.com> <39CF2A4B63947142A66EAA65B2FDF2F00491A4B0@CORPUSMX40A.corp.emc.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: bhalevy@panasas.com, nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 12, 2007, at 9:55 AM, Glasgow_Jason@emc.com wrote: > For block layout drivers, the server can mandate locks as long as the > locks are on sector boundaries, and as long as the server only > grants to > a client layouts that are compatible with the mandatory locks > previously > acquired by that client. > > It is a limitation, but not nearly as serious a limitation as > preventing > the use of mandatory locks for block layout drivers. As Benny pointed out, the language you quoted would allow what you described above. The locks would be on sector boundaries and the server would ensure to provide layouts accordingly. That is allowed. Spencer > > -Jason > > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com] > Sent: Thursday, July 12, 2007 9:25 AM > To: Glasgow, Jason > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] Using Mandatory file locks with block layouts > > Well the server can't mandate the byte range locks otherwise. > I don't see how you can support mandatory locking when you allow > direct client access to the device without being able to enforce > the locks there. Without layouts the client has to funnel through > the server where and I/O can be intercepted and mandatory locks > can be enforced. A client that previously tried I/O at the server > without holding a lock will now go directly to storage and the I/O > will go through although it must not when mandatory locks are in place > and there's a lock intersecting with the unlock I/O range. > > Benny > > Glasgow_Jason@emc.com wrote: >> I have been reviewing the NFS-V41 draft 12 and I have an issue with >> section 12.5.1. The language in the last paragraph seems to preclude >> using mandatory locks in conjunction with block layouts. I say this >> because I do not expect block devices to be able to implement >> byte/octet/record range locking. >> >> Perhaps we need a change the spec to say >> >> If the storage device >> is incapable of providing this check in the presence of mandatory >> file locks, the metadata server then MUST NOT grant intersecting >> layouts and >> added "intersecting"----^ >> mandatory file locks simultaneously to different clients. >> ^*******added********^ >> >> >> Comments? >> >> Jason Glasgow >> EMC >> >> >> >> >> http://www.nfsv4-editor.org/drafts/drafts.html >> >> 12.5.1. Guarantees Provided by Layouts >> >> Layouts delegate to the client the ability to access data located > at >> a storage device with the appropriate storage protocol. .... >> >> .... >> >> In the presence of pNFS functionality, mandatory file locks MUST >> behave as they would without pNFS. Therefore, if mandatory file >> locks and layouts are provided simultaneously, the storage device >> MUST be able to enforce the mandatory file locks. For example, if >> ^**^ >> one client obtains a mandatory lock and a second client accesses > the >> storage device, the storage device MUST appropriately restrict I/O >> for the byte range of the mandatory file lock. If the storage > device >> is incapable of providing this check in the presence of mandatory >> file locks, the metadata server then MUST NOT grant layouts and >> ^********^ >> mandatory file locks simultaneously. >> >> >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 12 14:05:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I932x-0006K0-NZ; Thu, 12 Jul 2007 14:05:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I932w-0006Jv-Az for nfsv4@ietf.org; Thu, 12 Jul 2007 14:05:46 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I932v-0001uw-W5 for nfsv4@ietf.org; Thu, 12 Jul 2007 14:05:46 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6CI55Z0011655; Thu, 12 Jul 2007 14:05:05 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6CI523G003833; Thu, 12 Jul 2007 14:05:03 -0400 (EDT) From: Glasgow_Jason@emc.com Received: from CORPUSMX40A.corp.emc.com ([10.254.64.48]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 14:05:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Using Mandatory file locks with block layouts Date: Thu, 12 Jul 2007 14:04:59 -0400 Message-ID: <39CF2A4B63947142A66EAA65B2FDF2F00491A6D6@CORPUSMX40A.corp.emc.com> In-Reply-To: <7A3A61AA-C81B-4EFE-89A1-E5A38A9C5107@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Using Mandatory file locks with block layouts Thread-Index: AcfErckrYrCWB86uRFOFJGEwH262owAAEdGg References: <94967674-4D00-40F4-8D39-E64813F7C6BA@sun.com> <39CF2A4B63947142A66EAA65B2FDF2F00491A274@CORPUSMX40A.corp.emc.com> <46962B99.4090404@panasas.com> <39CF2A4B63947142A66EAA65B2FDF2F00491A4B0@CORPUSMX40A.corp.emc.com> <7A3A61AA-C81B-4EFE-89A1-E5A38A9C5107@sun.com> To: X-OriginalArrivalTime: 12 Jul 2007 18:05:00.0748 (UTC) FILETIME=[2A11D0C0:01C7C4AF] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: bhalevy@panasas.com, nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I am glad to hear that there is consensus that spec allows such behavior. =20 I read the specification differently, and thought that the unqualified references to "layouts" precluded this. I stand corrected. -Jason -----Original Message----- From: Spencer.Shepler@Sun.COM [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Thursday, July 12, 2007 1:55 PM To: Glasgow, Jason Cc: bhalevy@panasas.com; nfsv4@ietf.org Subject: Re: [nfsv4] Using Mandatory file locks with block layouts On Jul 12, 2007, at 9:55 AM, Glasgow_Jason@emc.com wrote: > For block layout drivers, the server can mandate locks as long as the > locks are on sector boundaries, and as long as the server only =20 > grants to > a client layouts that are compatible with the mandatory locks =20 > previously > acquired by that client. > > It is a limitation, but not nearly as serious a limitation as =20 > preventing > the use of mandatory locks for block layout drivers. As Benny pointed out, the language you quoted would allow what you described above. The locks would be on sector boundaries and the server would ensure to provide layouts accordingly. That is allowed. Spencer > > -Jason > > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com] > Sent: Thursday, July 12, 2007 9:25 AM > To: Glasgow, Jason > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] Using Mandatory file locks with block layouts > > Well the server can't mandate the byte range locks otherwise. > I don't see how you can support mandatory locking when you allow > direct client access to the device without being able to enforce > the locks there. Without layouts the client has to funnel through > the server where and I/O can be intercepted and mandatory locks > can be enforced. A client that previously tried I/O at the server > without holding a lock will now go directly to storage and the I/O > will go through although it must not when mandatory locks are in place > and there's a lock intersecting with the unlock I/O range. > > Benny > > Glasgow_Jason@emc.com wrote: >> I have been reviewing the NFS-V41 draft 12 and I have an issue with >> section 12.5.1. The language in the last paragraph seems to preclude >> using mandatory locks in conjunction with block layouts. I say this >> because I do not expect block devices to be able to implement >> byte/octet/record range locking. >> >> Perhaps we need a change the spec to say >> >> If the storage device >> is incapable of providing this check in the presence of mandatory >> file locks, the metadata server then MUST NOT grant intersecting >> layouts and >> added "intersecting"----^ >> mandatory file locks simultaneously to different clients. >> ^*******added********^ >> >> >> Comments? >> >> Jason Glasgow >> EMC >> >> >> >> >> http://www.nfsv4-editor.org/drafts/drafts.html >> >> 12.5.1. Guarantees Provided by Layouts >> >> Layouts delegate to the client the ability to access data located > at >> a storage device with the appropriate storage protocol. .... >> >> .... >> >> In the presence of pNFS functionality, mandatory file locks MUST >> behave as they would without pNFS. Therefore, if mandatory file >> locks and layouts are provided simultaneously, the storage device >> MUST be able to enforce the mandatory file locks. For example, if >> ^**^ >> one client obtains a mandatory lock and a second client accesses > the >> storage device, the storage device MUST appropriately restrict I/O >> for the byte range of the mandatory file lock. If the storage > device >> is incapable of providing this check in the presence of mandatory >> file locks, the metadata server then MUST NOT grant layouts and >> ^********^ >> mandatory file locks simultaneously. >> _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 12 14:59:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93t8-0007aN-5e; Thu, 12 Jul 2007 14:59:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I93t6-0007Xx-79 for nfsv4@ietf.org; Thu, 12 Jul 2007 14:59:40 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I93t3-0004Ac-DP for nfsv4@ietf.org; Thu, 12 Jul 2007 14:59:40 -0400 X-IronPort-AV: E=Sophos;i="4.16,533,1175497200"; d="scan'208";a="81338816" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 12 Jul 2007 11:59:28 -0700 Received: from sacexrs02.hq.netapp.com (sacexrs02.corp.netapp.com [10.99.190.106]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6CIxDIC015430; Thu, 12 Jul 2007 11:59:22 -0700 (PDT) Received: from SACEXMV01.hq.netapp.com ([10.99.190.108]) by sacexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 11:58:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Using Mandatory file locks with block layouts Date: Thu, 12 Jul 2007 11:58:26 -0700 Message-ID: <01AE8AF878612047A442668306EAEB05C17A10@SACEXMV01.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Using Mandatory file locks with block layouts Thread-Index: AcfCpj4onH5wX+IlSHGPszIKs+jMqwAVDfDQAGdN6CAAB5b04A== References: <39CF2A4B63947142A66EAA65B2FDF2F00491A274@CORPUSMX40A.corp.emc.com> From: "Muntz, Daniel" To: "Noveck, Dave" , , X-OriginalArrivalTime: 12 Jul 2007 18:58:27.0590 (UTC) FILETIME=[A17F1260:01C7C4B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Does this imply that a buggy/malicious client would be capable of violating mandatory locks? -Dan -----Original Message----- From: Noveck, Dave=20 Sent: Thursday, July 12, 2007 8:19 AM To: Glasgow_Jason@emc.com; nfsv4@ietf.org Subject: RE: [nfsv4] Using Mandatory file locks with block layouts What this would require is that the client itself enforce the mandatory locks with respect to other owners in the same client. That's doable but the spec has to make clear that that is its job, since there is no way for the combination meta-data server and data server to do it.=20 -----Original Message----- From: Glasgow_Jason@emc.com [mailto:Glasgow_Jason@emc.com] Sent: Thursday, July 12, 2007 5:20 AM To: nfsv4@ietf.org Subject: [nfsv4] Using Mandatory file locks with block layouts I have been reviewing the NFS-V41 draft 12 and I have an issue with section 12.5.1. The language in the last paragraph seems to preclude using mandatory locks in conjunction with block layouts. I say this because I do not expect block devices to be able to implement byte/octet/record range locking. Perhaps we need a change the spec to say If the storage device is incapable of providing this check in the presence of mandatory file locks, the metadata server then MUST NOT grant intersecting layouts and added "intersecting"----^ mandatory file locks simultaneously to different clients. ^*******added********^ Comments? Jason Glasgow EMC http://www.nfsv4-editor.org/drafts/drafts.html 12.5.1. Guarantees Provided by Layouts Layouts delegate to the client the ability to access data located at a storage device with the appropriate storage protocol. .... =20 .... In the presence of pNFS functionality, mandatory file locks MUST behave as they would without pNFS. Therefore, if mandatory file locks and layouts are provided simultaneously, the storage device MUST be able to enforce the mandatory file locks. For example, if ^**^ one client obtains a mandatory lock and a second client accesses the storage device, the storage device MUST appropriately restrict I/O for the byte range of the mandatory file lock. If the storage device is incapable of providing this check in the presence of mandatory file locks, the metadata server then MUST NOT grant layouts and ^********^ mandatory file locks simultaneously. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 12 16:01:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I94rB-0002QA-MF; Thu, 12 Jul 2007 16:01:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I94r9-0002PS-Rj for nfsv4@ietf.org; Thu, 12 Jul 2007 16:01:43 -0400 Received: from e2.ny.us.ibm.com ([32.97.182.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I94r9-0006xi-JX for nfsv4@ietf.org; Thu, 12 Jul 2007 16:01:43 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6CJx27k017359 for ; Thu, 12 Jul 2007 15:59:02 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6CJx2bx518000 for ; Thu, 12 Jul 2007 15:59:02 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6CJx2tT003767 for ; Thu, 12 Jul 2007 15:59:02 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6CJx2mV003764; Thu, 12 Jul 2007 15:59:02 -0400 In-Reply-To: <94967674-4D00-40F4-8D39-E64813F7C6BA@sun.com> To: Spencer Shepler , email2mre-ietf@yahoo.com MIME-Version: 1.0 Subject: Re: [nfsv4] Draft-12 is coming X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Marc Eshel Date: Thu, 12 Jul 2007 12:58:56 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V80_M5_05202007|May 20, 2007) at 07/12/2007 15:59:03, Serialize complete at 07/12/2007 15:59:03 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Spencer Shepler wrote on 07/09/2007 08:53:19 PM: > > I submitted draft-12 today for publication. You can find > an early copy at the usual location: www.nfsv4-editor.org > > This draft includes updates to the pNFS sections based > on the review comments that were received along with > a few sessions tweaks. The html-ized diff is available > on the site as well. > > We seemed to have come to a consensus on the proposed > changes for the stateids in layouts and the handling > of deviceid mapping. I will be working to make changes We had a short discussion of this proposal in our weekly pNFS/Linux status meeting and it was not clear to us that a consensus was reached. Will it be possible for Mike to post the last version of the proposal again before it goes to draft-13? Thanks, Marc. > to the specification to reflect Mike's proposals with > the intent of submitting draft-13 the week of the IETF > meeting. I will be providing additional detail of the > changes on the WG alias and review them at the IETF > meeting to assist in any last minute changes. > > Thanks, > Spencer > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 12 16:05:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I94ul-0002wd-HQ; Thu, 12 Jul 2007 16:05:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I94uj-0002wT-Rr for nfsv4@ietf.org; Thu, 12 Jul 2007 16:05:26 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I94uj-0007AI-GD for nfsv4@ietf.org; Thu, 12 Jul 2007 16:05:25 -0400 X-IronPort-AV: E=Sophos;i="4.16,533,1175497200"; d="scan'208";a="81365244" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 12 Jul 2007 13:05:09 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6CK57Gd001179; Thu, 12 Jul 2007 13:05:07 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 13:05:07 -0700 Received: from exsvl03.hq.netapp.com ([10.56.8.64]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 13:05:07 -0700 Received: from [10.34.24.132] ([10.34.24.132]) by exsvl03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 13:05:07 -0700 Message-ID: <46968972.4060009@netapp.com> Date: Thu, 12 Jul 2007 13:05:06 -0700 From: Garth Goodson User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: "Muntz, Daniel" Subject: Re: [nfsv4] Using Mandatory file locks with block layouts References: <39CF2A4B63947142A66EAA65B2FDF2F00491A274@CORPUSMX40A.corp.emc.com> <01AE8AF878612047A442668306EAEB05C17A10@SACEXMV01.hq.netapp.com> In-Reply-To: <01AE8AF878612047A442668306EAEB05C17A10@SACEXMV01.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2007 20:05:07.0358 (UTC) FILETIME=[F18B3BE0:01C7C4BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Glasgow_Jason@emc.com, "Noveck, Dave" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Muntz, Daniel wrote: > Does this imply that a buggy/malicious client would be capable of > violating mandatory locks? > Yes. But given that a buggy/malicious block based pNFS client can write anywhere on the block device to which it has access, this seems like the least of your worries... -Garth > -Dan > > -----Original Message----- > From: Noveck, Dave > Sent: Thursday, July 12, 2007 8:19 AM > To: Glasgow_Jason@emc.com; nfsv4@ietf.org > Subject: RE: [nfsv4] Using Mandatory file locks with block layouts > > What this would require is that the client itself enforce the mandatory > locks with respect to other owners in the same client. That's doable > but the spec has to make clear that that is its job, since there is no > way for the combination meta-data server and data server to do it. > > -----Original Message----- > From: Glasgow_Jason@emc.com [mailto:Glasgow_Jason@emc.com] > Sent: Thursday, July 12, 2007 5:20 AM > To: nfsv4@ietf.org > Subject: [nfsv4] Using Mandatory file locks with block layouts > > I have been reviewing the NFS-V41 draft 12 and I have an issue with > section 12.5.1. The language in the last paragraph seems to preclude > using mandatory locks in conjunction with block layouts. I say this > because I do not expect block devices to be able to implement > byte/octet/record range locking. > > Perhaps we need a change the spec to say > > If the storage device > is incapable of providing this check in the presence of mandatory > file locks, the metadata server then MUST NOT grant intersecting > layouts and > added "intersecting"----^ > mandatory file locks simultaneously to different clients. > ^*******added********^ > > > Comments? > > Jason Glasgow > EMC > > > > > http://www.nfsv4-editor.org/drafts/drafts.html > > 12.5.1. Guarantees Provided by Layouts > > Layouts delegate to the client the ability to access data located at > a storage device with the appropriate storage protocol. .... > > .... > > In the presence of pNFS functionality, mandatory file locks MUST > behave as they would without pNFS. Therefore, if mandatory file > locks and layouts are provided simultaneously, the storage device > MUST be able to enforce the mandatory file locks. For example, if > ^**^ > one client obtains a mandatory lock and a second client accesses the > storage device, the storage device MUST appropriately restrict I/O > for the byte range of the mandatory file lock. If the storage device > is incapable of providing this check in the presence of mandatory > file locks, the metadata server then MUST NOT grant layouts and > ^********^ > mandatory file locks simultaneously. > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 12 16:15:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I954I-00056T-RJ; Thu, 12 Jul 2007 16:15:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9543-0003qo-1k; Thu, 12 Jul 2007 16:15:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9542-0003xV-Nt; Thu, 12 Jul 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 934F726E86; Thu, 12 Jul 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I9542-0006cJ-DR; Thu, 12 Jul 2007 16:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 12 Jul 2007 16:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nfsv4@ietf.org Subject: [nfsv4] I-D ACTION:draft-ietf-nfsv4-minorversion1-12.txt X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF. Title : NFSv4 Minor Version 1 Author(s) : S. Shepler, et al. Filename : draft-ietf-nfsv4-minorversion1-12.txt Pages : 491 Date : 2007-7-12 This Internet-Draft describes NFSv4 minor version one, including features retained from the base protocol and protocol extensions made subsequently. The current draft includes description of the major extensions, Sessions, Directory Delegations, and parallel NFS (pNFS). This Internet-Draft is an active work item of the NFSv4 working group. Active and resolved issues may be found in the issue tracker at: http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4. New issues related to this document should be raised with the NFSv4 Working Group nfsv4@ietf.org and logged in the issue tracker. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nfsv4-minorversion1-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nfsv4-minorversion1-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-12154408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nfsv4-minorversion1-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nfsv4-minorversion1-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12154408.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --NextPart-- From nfsv4-bounces@ietf.org Thu Jul 12 20:26:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I98zS-0006dF-4E; Thu, 12 Jul 2007 20:26:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I98zQ-0006d8-8c for nfsv4@ietf.org; Thu, 12 Jul 2007 20:26:32 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I98zL-0002DE-Mw for nfsv4@ietf.org; Thu, 12 Jul 2007 20:26:32 -0400 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6D0QQTZ028167 for ; Fri, 13 Jul 2007 00:26:26 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JL300M01D7ZBG00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 12 Jul 2007 18:26:25 -0600 (MDT) Received: from [192.168.0.3] (adsl-71-145-192-173.dsl.austtx.sbcglobal.net [71.145.192.173]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JL300DVND80MV20@mail-amer.sun.com>; Thu, 12 Jul 2007 18:26:25 -0600 (MDT) Date: Thu, 12 Jul 2007 19:26:34 -0500 From: Spencer Shepler Subject: Re: [nfsv4] Draft-12 is coming In-reply-to: To: Marc Eshel Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: email2mre-ietf@yahoo.com, nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 12, 2007, at 2:58 PM, Marc Eshel wrote: > Spencer Shepler wrote on 07/09/2007 > 08:53:19 PM: > >> >> I submitted draft-12 today for publication. You can find >> an early copy at the usual location: www.nfsv4-editor.org >> >> This draft includes updates to the pNFS sections based >> on the review comments that were received along with >> a few sessions tweaks. The html-ized diff is available >> on the site as well. >> >> We seemed to have come to a consensus on the proposed >> changes for the stateids in layouts and the handling >> of deviceid mapping. I will be working to make changes > > We had a short discussion of this proposal in our weekly pNFS/Linux > status > meeting and it was not clear to us that a consensus was reached. > Will it > be possible for Mike to post the last version of the proposal again > before > it goes to draft-13? Well, yes and no. If there are issues with what has been proposed, they should be mentioned on the WG alias. If there is a need for additional detail in a particular area, please ask for clarifications. The editorial work to integrate the proposal into the specification will be large enough that I would prefer any issues be raised now. I can work to extend Mike's proposal slightly given the thread of discussion on the WG but again, I would prefer comments now. Spencer > > Thanks, Marc. > >> to the specification to reflect Mike's proposals with >> the intent of submitting draft-13 the week of the IETF >> meeting. I will be providing additional detail of the >> changes on the WG alias and review them at the IETF >> meeting to assist in any last minute changes. >> >> Thanks, >> Spencer >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 12 20:44:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I99Gr-0003HU-UU; Thu, 12 Jul 2007 20:44:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I99Gp-0003HE-6l for nfsv4@ietf.org; Thu, 12 Jul 2007 20:44:31 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I99Gl-0002n6-J8 for nfsv4@ietf.org; Thu, 12 Jul 2007 20:44:31 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6D0iQW1025647 for ; Thu, 12 Jul 2007 20:44:26 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l6D0iQQq131966 for ; Thu, 12 Jul 2007 20:44:26 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6D0iQjs019315 for ; Thu, 12 Jul 2007 20:44:26 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6D0iQcT019309; Thu, 12 Jul 2007 20:44:26 -0400 In-Reply-To: To: Spencer Shepler MIME-Version: 1.0 Subject: Re: [nfsv4] Draft-12 is coming X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Marc Eshel Date: Thu, 12 Jul 2007 17:44:19 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V80_M5_05202007|May 20, 2007) at 07/12/2007 20:44:27, Serialize complete at 07/12/2007 20:44:27 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: email2mre-ietf@yahoo.com, nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Spencer.Shepler@Sun.COM wrote on 07/12/2007 05:26:34 PM: > > On Jul 12, 2007, at 2:58 PM, Marc Eshel wrote: > > > Spencer Shepler wrote on 07/09/2007 > > 08:53:19 PM: > > > >> > >> I submitted draft-12 today for publication. You can find > >> an early copy at the usual location: www.nfsv4-editor.org > >> > >> This draft includes updates to the pNFS sections based > >> on the review comments that were received along with > >> a few sessions tweaks. The html-ized diff is available > >> on the site as well. > >> > >> We seemed to have come to a consensus on the proposed > >> changes for the stateids in layouts and the handling > >> of deviceid mapping. I will be working to make changes > > > > We had a short discussion of this proposal in our weekly pNFS/Linux > > status > > meeting and it was not clear to us that a consensus was reached. > > Will it > > be possible for Mike to post the last version of the proposal again > > before > > it goes to draft-13? > > Well, yes and no. If there are issues with what has been > proposed, they should be mentioned on the WG alias. If there > is a need for additional detail in a particular area, please > ask for clarifications. > > The editorial work to integrate the proposal into the specification > will be large enough that I would prefer any issues be raised now. > > I can work to extend Mike's proposal slightly given the thread > of discussion on the WG but again, I would prefer comments now. > > Spencer I am not sure what is the final state of the proposal for which you assume that there is consensus. There where comments and suggestion which might have changed to initial proposal. One specific question I had is are we going to keep the recall all layouts for a given fsid. Few of us were not clear on the final proposal so I think we need another review before it goes into the draft. Marc. > > > > Thanks, Marc. > > > >> to the specification to reflect Mike's proposals with > >> the intent of submitting draft-13 the week of the IETF > >> meeting. I will be providing additional detail of the > >> changes on the WG alias and review them at the IETF > >> meeting to assist in any last minute changes. > >> > >> Thanks, > >> Spencer > >> > >> _______________________________________________ > >> nfsv4 mailing list > >> nfsv4@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Jul 12 20:49:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I99LQ-000107-Pe; Thu, 12 Jul 2007 20:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I99LP-000101-7X for nfsv4@ietf.org; Thu, 12 Jul 2007 20:49:15 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I99LK-0002up-SX for nfsv4@ietf.org; Thu, 12 Jul 2007 20:49:15 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6D0nAE2020562 for ; Fri, 13 Jul 2007 00:49:10 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JL300A01D8BA900@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 12 Jul 2007 18:49:10 -0600 (MDT) Received: from [192.168.0.3] (adsl-71-145-192-173.dsl.austtx.sbcglobal.net [71.145.192.173]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JL3008ZKE9XWU10@mail-amer.sun.com> for nfsv4@ietf.org; Thu, 12 Jul 2007 18:49:10 -0600 (MDT) Date: Thu, 12 Jul 2007 19:49:19 -0500 From: Spencer Shepler Subject: Re: [nfsv4] Draft-12 is coming In-reply-to: To: nfsv4@ietf.org Message-id: <8C3B0D55-1DD9-4999-9773-37A239896163@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 12, 2007, at 7:44 PM, Marc Eshel wrote: > Few of us were not > clear on the final proposal so I think we need another review > before it > goes into the draft. I will put together a summary of what will be changed. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From opjtk@energizer.com Fri Jul 13 22:45:51 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Xdn-0007sl-Kt for nfsv4-archive@lists.ietf.org; Fri, 13 Jul 2007 22:45:51 -0400 Received: from [167.199.248.140] (helo=tgnrbje) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9XdY-00029E-3K for nfsv4-archive@lists.ietf.org; Fri, 13 Jul 2007 22:45:51 -0400 Received: (qmail 25494 invoked from network); Fri, 13 Jul 2007 22:44:55 -0400 Received: from unknown (HELO vrvv) (164.37.86.92) by tgnrbje with SMTP; Fri, 13 Jul 2007 22:44:55 -0400 Message-ID: <469838A7.1000208@energizer.com> Date: Fri, 13 Jul 2007 22:44:55 -0400 From: Sandoval User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: Fwd: Content-Type: multipart/mixed; boundary="------------000400040002030500050600" X-Spam-Score: 3.0 (+++) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 --------------000400040002030500050600 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit --------------000400040002030500050600 Content-Type: application/pdf; name="" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="" JVBERi0xLjMKJeLjz9MKMSAwIG9iaiAKPDwKL1BhZ2VzIDIgMCBSCi9UeXBlIC9DYXRhbG9nCj4+ CmVuZG9iaiAKMiAwIG9iaiAKPDwKL0tpZHMgWzMgMCBSXQovQ291bnQgMQovVHlwZSAvUGFnZXMK Pj4KZW5kb2JqIAozIDAgb2JqIAo8PAovQ3JvcEJveCBbMCAwIDQ3MiAxOTRdCi9QYXJlbnQgMiAw IFIKL1RodW1iIDQgMCBSCi9NZWRpYUJveCBbMCAwIDQ3MiAxOTRdCi9SZXNvdXJjZXMgCjw8Ci9Y T2JqZWN0IAo8PAovSW0wIDUgMCBSCj4+Ci9Gb250IAo8PAovRjAgNiAwIFIKPj4KL1Byb2NTZXQg NyAwIFIKPj4KL0NvbnRlbnRzIDggMCBSCi9UeXBlIC9QYWdlCj4+CmVuZG9iaiAKOCAwIG9iaiAK PDwKL0xlbmd0aCAzMQo+PgpzdHJlYW0KABvnhtnLaLjAEZdzamUhYulO9EmSIZkDzh6Y0Ecg5wpl bmRzdHJlYW0gCmVuZG9iaiAKNyAwIG9iaiBbL1BERiAvVGV4dCAvSW1hZ2VJXQplbmRvYmogCjYg MCBvYmogCjw8Ci9CYXNlRm9udCAvSGVsdmV0aWNhCi9TdWJ0eXBlIC9UeXBlMQovTmFtZSAvRjAK L0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nCi9UeXBlIC9Gb250Cj4+CmVuZG9iaiAKNSAwIG9i aiAKPDwKL1dpZHRoIDQ3MgovQml0c1BlckNvbXBvbmVudCA4Ci9OYW1lIC9JbTAKL0hlaWdodCAx OTQKL1N1YnR5cGUgL0ltYWdlCi9GaWx0ZXIgWy9MWldEZWNvZGVdCi9MZW5ndGggNTg2NQovVHlw ZSAvWE9iamVjdAovQ29sb3JTcGFjZSA5IDAgUgo+PgpzdHJlYW0K1+AdDj1qKHO7/eG7Wy7A4/+1 4IAgFw79FIr3TaESD9V5TvizXZdMv2T0rL++NpaXn9CLmyP8JVAh31zyuHozOsq9bYEk0JF/zEfT hDKBNWTtJAhFUsAyLEv7uouN01tRLP8MwwcFOozjh+YbxJTeKjuDtNhsx95YSBoah7d2b5EG35h0 jlwmJsoxGq9v+CfbZYTgrfppn8wU/0BpSiyHEVaPiUo34l2rVVqLOOs94mpO539nkgTiQujcEIBU cwhqM4ByCJ/RYQyjkjXx+fiDTj5+QOwrpjhM4/NgDmUvIlDxc7HoQpwzUCRs49oNS0GyAiyTySge fou9iEuloJ7z+BaeAEfSBLJdnyQ+9lTE5e7CoX9M4sMr3zvrHz8fgHzmABx17pw3VAUkoOW1K6m6 6qtO9F4K0xp4agBejaH9zCAiTrF9uQZ+WJEWcYxZ8A0mbcHrT1szU1SeHKVju500WbpD2sEkJGsB DHmJbDlXyTsI2+L8DAeWs01Y4kpUntj7Xko2XRnaIur52BmuD9UAfdPx4XORKZNcHHVpKytc4FTX HejeUWkuNCP+GgRqRDkdXoQoIEU5w7KVTXoenjs6H9sucKaD5xeCbIoEFa+ZY6C1e2iqRqP3mAws pqiZAWdBso7I9U4UgqFwJ5VQZY+QbIm3mPilQ0eO/+LXpK/ptO/rxnZ7QDlB/bxOGOamTB0CN6y9 b4tuQsEjy6BnZHXR0QeBSmA5jBljunSzVrLQQu6VteACtNLYx64DIse73adrSR6pecBqQnqclHQS zQuxWjYofHf1rkt3ipvKMc5VuHJSvzi8kKMjnyVr1Z16woq7+DO5ICEGEkw3H7aMCTsSp+Z4omxK GoGFMUAifiMFPXoyCRWRSIWHxFEi7gcXpORnH+hWHTXLE7w0Sd4cFzTtFm+E2LmergLAnC+4LXay W2D8d64jD3gaMDXrOg/WOrDUGP67J+1xGcqnkjRQQhPip0X26a9h1I/r1ro6G2VUhxlBDv5FKdtn Qaq4LTo78RIdc9Pj5bqnxgVgyPAgjyIAAG0R7u04ZpRTRFZs/RBLEg2R9VTd2DxJ8Teyh0KM7HPp DYZZrV67TjWitKrR/iC2Pfyu63M4qrqsqLNCztLmkrLKBsuL/xbsYCYs21hVHYo/u9MrMM8GleK9 oUAwaSVjM3A38FOIujIx4rtXk5723IJQQswNmlImjLHmkCIXYb1w4tV/hne/bdN7KISnT8evUTwc 0quyn/uJoro8oD19+l1uhYVDi08kKLEYWpZ8o6qpawLFVxOnsON6+zov7t86pj+UVAy7+yc9TlyD FjUbqQfnjY8gfyoO9TIliPxxraL8mwLq8pAn9ZQGyem400fFcSOG1Jv9FtP3pYNXoQt4dM+Uz9dQ s2feJcuAtdcqN9ky7RmKSS2MegSQiUSYazy6hqPhdyxb6Ol07TSbj8UDU5adeBTnDyYPvkYp9lph Nfr6lGraqJypPS7AR3G+irG90laPGyeWqJsqa/w3NXYBxP/ijw9z/s0T0RQNj2oXNVGLms6qvC4P JQ6A+mbJ3ys9eBIIkuWrzcUUpUaYBesyRQoX83r1sZ0Hzs7r5DELtKdSG5pXSobWnoTFMYV6XtCt Zjy5pQU1gEgK1mXUE1D848mW9EcQcyjlC9vZGwwjEskZNVmDNQIRCLh+xoOq4fLZOkIeIKRXPCRO iIZ5v4VEAmRdIx5iV2btWI9WqvmGCA3+plpq1yANjl1SNnoxtZJibuxhcoV2em1A5QUfgIZLIbqy lgIpkB3023DQgCN/Ehioqy+EFSV2UjHCJD9tXPKZpPV6K+JFpuniUE0vCgMV3woeJnxNXWBqBe1p 38YBsy4O3Jz3NZtWJ1u3M3bmDKLHRVX1Y8BNR5mOemcR7ErrIXaeUp95C0SdJeDw+W+lnEiaw+G8 2k3dXFfAIwG9sFvLT1PFttGR/kulagOk+rSplGPPPSikV1YNKX4BW0Wq5G/vbiQYLnlkJeYpzdTn YAB9gcZJrDqtRKTLSJNQ3QsLrY/bY6ljHJiYyehCu6wEHdZPM7Z6Z/fMtrHDh6V1WDIrXF6LbQmI gErlKk5kARwYvdciMm2jFk6nW3GtSTmlPxs0JjQj1Qf9yWyf65CmkYvWEUX+rtE5diEKmjk9x+oN a1KUZti+4eKHRiaZkPdsjIoTuG+rDMqqDGsN9crBp4CVNARTr3zqXDc24XCY/YzIfYNKnAC/l30r Bb/72Ze+Ls9V+Jv64Xx0m4PfbRf+JuaKYf/+Ir2fgPUN/zNGRJSMFzadKMCexCE94MCEE4Xe0Gt3 fh/6pm4OdwU8lTLrNfH98DtvUwXbubZAM59T20yretn1yeVOAf+S3zhRtNC0FNA4mCNeJBfUFfv6 blOd4gTW2wNA3kS5G4Lw1bpv3U4xdVdKJ66E/ntu19GmoQsvFB0+CSBN/DvMX0iS996YtySONS36 nobk5jv+HVcFCwFjUf4PM0/JwuSUZMFyCexXSpa5ww6PPxvD+A+3BePQ+JmLnQobnQ9yf6c0cuwT qguV3gm/Q5IN0AqhfmfxHyzMkYjh420QIpFgUZIPq8MlRYOdo+EFNyGpbX2icGDBeq4vdPKkp0dH pW2MO0/OUiKkuxoMEDnHTPTK4x3UGhdAQnK2dk27PEcfMyZzbdMH1xpoP7tRcyZh05nPaNcwbGpC YmWYOtOvsy9xZmo1VcnQePf2ePPgIrnjSwKZ8zBoGX99AVVEkgh56EJkxuydmnoertXYXyXY0j07 vEkUpvQElExM4KMUtZ34S+h7d7jnXdTtxQdTyEPRDY/9W/zdfi6vaKIECG8DWpjzmuXNVvzjfIWF UHCvMq0nujGWzH5sdOVTUeaTrkizlomJvJGUzTQVc7Nv5jIcGCH+wewmKic4LAeU+yj1kGHgFh2d GuF5BQoL59Nm4KKM6Eo453QAAKvPvvizUdTnT5wqZG8wX+0ZR4Za1gCYQaVCxs/xefUlVm9WiDdh DxK6lcgzvJlXpy5PMryNjDtEqbzL397BoV+4a2YH26hjI9W8IJn7pV/m8QJQ4Uqqu8FwyuQIJTUn 9teqT3sC3LshwoAFwIukpXM50FIz6xDJO+5dJefFhxf/rE+WR8fY1vIdVjQhOOWPv7LTOmqz5yDT Sbs2HiHUKXMo2B8RAlPiXoR3jiedS1XPgOmlnjl7vfYej9GUmOK5RMExjf8ONRixUoeg+0eo1CAE E+pgwmXZd91zxmuSZOKUhXAuYHfwEg5MxE6iReUo3dIvvkBu1OddwhNAlvCAUdcT+adCDnlh0b8I /oaRy0Xn7VXVvTWpRdLXIGRUQYuGvh9WyPTbfnqXdY8asU0XeC6jYC5ozLfUHUIUVh2reJUNW/6T klm9/9uqybMJRAYd9Wd+weWzUIcxkdxMK3LHrJnre2PXRE5S6fQEZ5ZvBt9DV3vxW2+LLzjvhNz1 /4oUeo1m8kPxtmjxNWMPmXVcH5Kai+OwNyxASxeu1qIAa5xDCPIVu+q79g4gB8t5vlJZxQ/Ukspp FBXGubTwP7yWZ05MOPLTgF4IVP9TL5iq8qL4+Qx+mw3sVq0FYnw+9hVHwbPlW/YN3PLCiqc/oOH3 rvG0g4b/kzQ3iWF08opdDfrNdHiV6xncz8Mpgjl0Ml+KsK7cV/O/vT/SI8T5cOUN1FuwcMGROfJx ed0wZhz0VAFWhV+Lm736ZIA9g6Z7lA3XeABeD3uGwYbHl3+cPCCVO+GMK9HOrLyRLKApiH1FXSm/ 05uSc0kLFbXH1iv5mf9cTkdvDx5b+15xF7/dL+Ijm/8zKHeoRvRevluNtpl4RPpdVasH51GCi4t7 MRQ+POaVfxYFODm7BQu6R5boX9vKDGrazNzflhWk+5UDGq8Tz72qbeCboZP/c6yoUqW7/NywGYhQ Wjta/tfby/4s17WDYifc1DUVKuFswIHFbGfQS99NZ5C7VdjdvaIukzZqrcZuai54bZYOLdWwGE58 U5bHpMwqv/FAE6C/pcKs6f0UPYp9rv5Q3Gfg6CLQqq00L4D/pwqCdV1aOCRRx6QYYHRHkS/0KUAd TkokhxCLzr8BQgT5TZuzfq5XrJbsum9LlvxSEVfHb/P75PsZBEKZmHZd7IaYGUrnH7uQyHQUKPJD ZGp9k6Rl3rFwQ4wQLD0vAsyjpnEpkvb6mUtFsG/iNXh2SGgvCMLJk3mJMwWAUZt1P5F/j8sWwWLh IEUxdN7cryNI0BHreZ8MWj/Hou5JTwQW4JwtugSz+nN5iw45s3aHwn8QDQ+7ZhA2H5KZgd4BDl63 Vrp2jYNSmFSPDvCEpjiwAuY1mMICXWIr/9CzS3gwdLApujpeL7BJeiQl2S3Xwpm1HIplG4DXwf3i STVKLLg35DjZ9Fd08MjQATfrdruoy42Ao4zXqbaEfSHRYCIvrJDWl6G7eSKcxyFERbiqDBp4HAc2 nlCyzpmro94IeE1WG5+CJhWZvp0nRCo/JwbSfIHYnyZlmGZRi8+kS765VobIxNHnT3ytZXnYcbVy nY/9+mfgGZBIYBuSX6g8Koqtx9NEMa1OzT+whr+UiHKbCdwY/2TjkxSbEIKp9J9t6m214fRxQPtm DLV31BejszUubhAcfl8rqt8ozyxOyeoZLQXnZ/fsLaMGNPwjIe0z3iewndcVQaD/w5uI4ioVwKAd IGYHmrBlXMwc4NMcml6z3rGwI+czao1ykqaZpTk/Tr10xHINOlAQvEpyy+XR1YWDQAaAS1sLsWLO iTCwx/duReqxWy14QOBtKs7GiNYyqvX0Gz7Uoh1BmWaQaCUPMJQh8H2/mQoB04jZZSPl8uY/ao+P LXrb1jBAT2z8Y262hTmCNekheavPn1pR9hJJh7yyOhBqjd8Yd3vElG2NwVITi002gdNBxV1+FEWL PMzzjt3xA9LELxyDb2LdAiF5UJQPcXl4jxv6lN0m5Up00k1I4fOA7P5nUWPU0GouZHmBH+Kyr8A2 ANUl3urXkqsNi7PV+QIJf6G7vKF+NfN71vMx5LjiA1H6K9VCH0aKUOF8ri97xVW45FaS42vr+QkY 60eHQldhK+ykz9WGrBsugP10Y+Us+lermdJUm6iiP75MlGMDlxsaRcPmBt3m4wRtAk9rP0BcfSZj 1Yzd0eI6/u9ez6a3vTks8rWI1gF5n5USouShSu5kya6enGSOHYF4l+54bL8aKLabOuLfKWCgiWkc Eu2ibJ5UbBf5aaWlo8LBBNe+J8GiqIG2L0hv0j8TzixPJJ44PgZTKVWqs36cpOFS3+9vuzXwRoQ1 PEMCBbdaafZ4COnjCUbTUH1qRsDYDsFE8pcGbOIgGUoeUHcrXgzXkgvIygwpBDC/M523/B2849vt HEgamKjV1HopNNY2siA9LG+QNQfVOKBawKu1/jSakH83YoSQ6jj2nMRJkVt5Tn0vy0Q9NN8bCpqu p/FTZHDXj2CcoLq0gj3UgWpGvkM/s5UISj2q2jjFo2IJEn7ONTa4Db04lobRbrPfzkcrWmJCxJdO fcNVfWey7DvAuc5XNFdqiUdtbemSs6VjRKx3kZo8XJGUOvAm/zOqlOAYGEcC9++a9Tp8f6Mnlupg vE6/LcmqgCTy5nGBjTM6RHjwStXzVZvpzd8klERz/74jEpeSrPfC9AGc4lnVoY8Q92w2hl3PTUpn BXUoJn0JcsB8HyHQA0VPYp4Ei+vXtPAL7aDAKMenLOmkLcqukLVof4NoMIDVVkHKJRLwZAJvZGAe 8ERC3XYR7RXC6vJqBl5gJMhJR3jGoSl+OMmThgjun5zjQslTX6j1Fb9bO3Us4ullRXzwfg6Gt8UK GYDEFfaLyWNIf2i+0REesGldE/g9VHNy6d+zsu4xFKr+0Ch+5t1bDyTHlyTOAt11stOR9AUcx2k4 EPUHQaSfb8ElJeYVxqPyVuzD2RGI2QUjsBLD9qxdS06fFVTQNtZ5+A8SsCKnQVc5yPhtCGkZeCz4 8LKU1hk836vQp2v/XWKZYj0HTQEXX1IL7pD3KzZzW421pfMyZqfQHwcRSIhJKZ0hWAhxGc2e+xCy cEoES31kPb0W6RJuctDNsI2bYJ3WhNGfvg8UiIhCZUqy2t0fe/nIgW1jy+Yuw9ALi6glHpFaDd0h LU4HXg7Cv3z1gPx8YT7F6lk3heQ+tV06gyt3lhkL6wZnMzE2XYMelEqP+ktEqf7P3xGUtIjZbC52 gJIZVoXbXDkanDh503pLNmiXXA8H3hbRX0cUh0ch81qE9KK8BVq15fU1bCzpCBLrVRh1wBoEH/Wj QjE40YOotP4AfLK+L0jKUBKjtl07gHQkZoPtDl+bV0tyRso9OXKCoi6GqMODutKdlzmICYdAlmSC Q9Br8STePuIcfmx8sHZQOir/4MeUrUV5zgiRBRqutfSSAePEolhThajQPt6rKgp/BN0VK9eXRffw TDervs9ZMPTL8S6RooH4FVrNdZRsPb09x4f1F5kWHWjL4/d8Xs7Keg79pSpS5DuA5V9SPZzOqxbo Lwb5ElwrHhP3jtEM1a74oPnVo5V2nmRtY93cFefStGcWioADy2lpskCGe67gKQADaGryh4WJmRfB pzr4ywtexzuomodJZzeX4GC5PSEYh0RsBhxUVR64jp55XwWUcXe4LvZbBMCR6Gt9qCOHlpvKY4Oz meaZiymF1tcnGzu7K+4rPDkzQ66KMenXnuMPjxJnvqlsCMBRW+cev+Udp3ugFezVRawTUmX0vIbm omDp+o4rOMoxE24aBk1a7gCRfccXQEXJ6ThoKeFoIw8id3MQpgXrY/m1gj9D3NM8bUWFHvgcFU8c Ann3gNhE+8X30qu+sCM/vhvgrpbxUIXqWGumqEHWpjbO4K4IpAkFvQWeL7KtsWFNxnozT+jDGbMb kuc3sd/bCkUXTx0rPYFUNhpij3BhrxpO8cI/zh6n8LQa35wvp9lIUrrMESrd4tEoMJpUTBeYS+wm AOigIXilBlhK1C8UYge+JUnDGWDFgKDFdh8WJPOTdBtDfzA58FmYqmrjin7YyaSQuF27cDttxj3b HNerPZ0VVwpM9/Je6Y442l4T5geQWKzpqtzv2LgHtSrwgMcAut9wtluD6MA2ffJu9jPmz8EXNQ6S HY7O9tRrrUm2vcIJvkkSv4tEsltlMTa3atzwnh8XbZ87hZ3D8Mb0uasBwJ9flmfdBfFyNc0kWKc1 /xH0EIMFwiXdHSEPZZgQXkxk16RBU4bxmUAkUsS5V3TEQLFEim8mmBGYHQ8fpoXbAZHOQ71LybDY Crsbm/lBJbTZDLMV1zyUWIqRF1oR32t5O5iybynHsaLz3aU3YNtmD8eWP97mahMX0nO70JVhIeGS 6UY/hd6OoO0yXMV47xY7F4a+rZPzK/CAUC3DEdvR8phw4my7O6K5VNGflDrAz6o9XnRKa9RoTv1z iHZ0z2ouPeHSE96GEwr2OSD9PZ7TPnsu3BGzzNZh0aFdfDuJyP6m02g/RcMAnFQgfxlGC/Hc6cd2 e8Y3onBaLGe6Wbd1AJ3sdAAsQUbgRa9Yup9/DcwkdM85W3nv87NV//2p4ouM+654S0WSmaRMmyni OA+q3hpIgwtGGlpXX9U9FBHbKiujf623u0Fcfa6ln4p6Bx8d2SwWbmIw6/KMVTOnjsQm4RJb+P40 PQ2fnxhTlDo5uxDAgfbOONhfbvh2slBuI2Ud0Gbs9v902u1oJAKzw1qj1WauSm5s3+KbWl6dQFkD Ub9xL7boK008mKhCCvwVM5zke9pNamcWkSiaz9UGCOIcvxkUnib10Y5f2br3PkkMcPk1tdfuQAdJ /AyLMnj7wcmSsoNxiIG9FLzErHZ5naH9GdDsUyBLEBPBCmVuZHN0cmVhbSAKZW5kb2JqIAo5IDAg b2JqIFsvSW5kZXhlZCAvRGV2aWNlUkdCIDI1NSAxMCAwIFJdCmVuZG9iaiAKNCAwIG9iaiAKPDwK L0NvbG9yU3BhY2UgOSAwIFIKL0ZpbHRlciBbL0xaV0RlY29kZV0KL0xlbmd0aCA1OTcyCi9XaWR0 aCAxMDYKL0hlaWdodCA0NAovQml0c1BlckNvbXBvbmVudCA4Cj4+CnN0cmVhbQq6k86MZuDPmnaV QAma0G6ZbpheXhnzVg8XcLFVbH4avn1L0AXmvoYU43jnkKrb6yBKIjpIICiD4L9WPVhizoP3x4wu CPVGur3NvX/sj8YsJNz3L63/K6oqXcufLPa8dhcMx1bToJb2lXwprE8+lDPGB8d6aKIMjoEUwla4 BhC/Dlr/01+J4bP4akfsyrS0LkLgR0T/SI8Vc0ND+P79W7LbOO8m7JVugCqpS+CMhe6F5gvNe+AQ TxieSlcyBJJ4sfevj9SZpvtgnbrVdUsV3Yp44xAxUZm+9NrKz6DdtvkOw2wwztj647/C+WPedENn GtDNJ6CUe8lw9GPdvXJqwMLg9pBnhqCD8PninXAsM1fyOZZrdaLvbVy0fL9Ysg8oYfLXQ7MDw2JU Qs/lRGzXIev7KkMx04GvP+WwmKSkI7AlkTIbu1/lJON/NZQdu3mcvU7W+st3SNBl9D6Jf/3zzvGy bZwz488VSGvKWVwO60zKcmspDs/Wnhy2F5FekksZvPEkuDZ0bRF7qMZFSpDO0O2TvUQmvA2WKYYX gQ+Se/wRPrhPD45xB8eri+vhcNVK4zd7U+0gJTxgKW9hbyYnOiATfRuqgsYVX+iXS7KBcmT86mhH 8zcpOx8x48j/eQmWH13Vb48C+bDF04hFcVzPUKOQYXy6WYTg8CgZFdVAFntn0mGOwNP0JnYUyji2 epi35Y4q+VS52m6iS/HjOD6PQyhGH6EibDxUiG4XOgK82CkzzWq0zwZYuoYQSt9NMC0A1TErNi+q vA/qHDWPqhHbTEpJrzodmbaua9LnIL+Ffuxg9CNfpp+44jzJqRDFMbUmfYtg9OD+uGEx7kKMzXLi 9i5PNfi0kjOIsd1VMivW7m9+o/zCK3CeJ7Rf+w3y2ALy77+gZbnjc/7dOc9KBKHCZiysDNwr0Uja 1yFSMUT0luOVhz6H/QzLjUXfqcNYUr9GHtV/UY+48xHCZwlVkw7L4YzF6rAJMi26YKjUDycpCSEf lHvdEwikHhazgZUoJ6B/6vM5yXl+x/eVrBJOkLnV38M6kO+ybQWCXytjGPbhUroqJ3FOdagH5YW4 y19Vkuy8ZMZHeFQaZO81m/BsOmiHj2NQeO3/WbYBxUlwCtw4/rmL3K75ZcujVeIgmcNGqLeeDcO5 LcyPfapGsC8w6NMKfsbXgi4vPSmsCccoGj71A2jiFUFjieSKNSCbztClMDYpoOelO2qVh89vZxuj zuv7cXJT8GA8cV3LgEG+ghZsfkojr/MArVu5Ye7V8ratAnqV7n00FB7kAe3CRo7RwBPMN8KiRs+j 2URvxApIP90MbC91fMoew+5/oCehOrWBg/3/ED3TaNc8rSALc+VR19gbjbzgT+CxADMIYuImsmtA swVdLvHtIBr72zwqR7rYS17r4WazEyeDZTuAALRi+77tJYMEAeYG4aUD97Hm0k5G7GqdXhJiqUBR NMjiaaVjJ42CjuQ5z8oU3rUnjFbZ9N51sEWYsGNZ+wdq4yvUF+A0yxEDiJCrIhdFMUgb7mlOmZWg vajIayXHuqtOfKhZqnceJ8ZblFD6yqXmEJKJd1zNhp0Ps+XklSZUXlDhh2zGxcmUMIVtdjfdkPx0 X7FjeGqN/6/j3YnTX9nDJiN8FTcaQPg0soAWPZBhoG4NGbI0Tm6vIpoQqs8lFhmHm3X5Neh62KY7 qYXcvCr12ccFOaqNyUXzpJ5sEVNXT5J8hxTXcn/ln0J4CISJ83qW9T2FSQCQQGmDtK4d/5kv+hzI 6h6RHb1L3AJhETBPyQVdB4I6NYOxkejf8TNH8AsFJidJ4dnmM4EduLHFeAq9CQmhgGtkT3W47ywk cGtj6hituEbfu9bHCI6pPBv9Zd6exd+rA2G8RwFLCMCe95lX7Y+IMLB7N8YNumHBqx37IaqXfhfy VUJ0snn02tmcfFtgKZLYwpzGD53R9hzmauE400aH7TTQS4ah5dzBMpC8LFT+1GQADrkh8AVkQCxV jB+Pwc0H8mCtHbO2xIiV9chXFV16C8Tj+honyWbnUt/22ZtNzgn8R+DITu45HXjOew5CYt2LU0+O njHtmjzNYx0OQ6EM9bVY5rcItfWYfBk/w7ELIKxBvcQ7sWZjsybGmStd/wZDbonEnTUQREx7PZTT D9oEX+kBaxGHill0EOdRo+87VwlxHlo0PZ0HYkezAvAWbjXg77Twaa1yTxsCtb9IcuX0rwPztNTI yqFMtTjcDNSYTMF5eidRZW0xDBGXo9n2ff/fpyAIaWw4nnizlr4OCky7lvfAiKi2dZyqnhPFdjwY heV41Nr9sVwWW+9TzgaDORJrRnz2wKgTb03cm9kAVF01b99uHqmf4S3GfVpbChUI6+f01/PDLbe6 tP8Kr+E6O7IpkQgf058qbjWOh+c0nVn1AATUccD0oKhRimmWJeUDxFIJAN05vSzWfMPMnvoKrySi 9DaLjlAuHJsoqQuj5fa6KjjPdZol94hWZAWzFszoXyI+ZF88V9UCTp7WcSEq/3Wvf7i6mNB0gZMI x2jIHnwn0iSd0wWBBvR6tPLTFE7/lYpTIuim8CaZwsUnvMBF3Xj6CX0YNLRvQ2U7tRUwKB8BSe9s m3PPncizJwUTeWKZ5sI+iBDUhasH/P8oF1T1R5cE02c/1b0KMf41G0ZtykbFPbVo8pYV4pHoeTTZ bKTJb/oBitauxxKZHaTmFLanOfrAyNm6Sg7+zv9zONj5JMrMtqzmg7yMv696Va8AVm5PoPoezqhI iFgDXYIKJAVv/o+xLmcsU2lFbA6hggdKhLFauUVRz6Jsb7d0lO0xm8cUWqLnsFNeo704INbnw9C4 jQfofJoqckPUv80tqipEtOivL8WsZP99FEeBehbOObfHJTA7u+EHuKn3IsqO6uriFiqGbPvytO8i dTEkdOM1FAD60n8DHeEYB7ihSqvyD4cVpRGvqTkuFKWsEfEuWzEVZ6t0cfAwntZB0VCEr6OHwfEP cFZpjeZSIoR9w7WFobJy5dVkDTHRJ168cy/X+5V1Imjd+g8EZQbb/uI4+WKgxQwZgnHq7Uxyz8Mn 57e+N66D6E7U9MjnNCR3q5l3JRYjc32HkjcJJPDZ+xvUYh6vHGleHkfpx2S6q8NkXr/ll6zum+uH 0fbTPvzx8fZtBoovQSqY0/w6Lmyp1NC8HxKM7YLwFlf1zXUnD+kUEGxfF+WNaB5rsLjXYabapJkX fH1eGRTcnqmORdwA/Nn8LtAZ/RPq1JkcgIH+n5PiSo08JK04auqjUPPj4EHzzN61FDRGOOKPqfP5 mknuuoU1642RvgVGmMvu5tsDirFS3zfjtMcuD0gdNjr7dbBywjHM6w8FgpB33BZlKRsDeOU1/QpK EHMjhQAGV6a+oCQDBbIr4gCLTWPw1A8w8ufGDjTzSR/ic3n0i5LHN6kywq+FEKMueWFxq1viqbMx VNtrirTDqcezhDF7V91BLqjEvWvhRLrQbYvKDx7ZoXFrdmeLFgMnw4tr7KtXqdIPPJ/PdDiGpUHZ Hn/Tn3WFsICfzcSsNSpmrpyxymh0LxJCqd1x9l6p+DauX1pmbEW2RJ/ZHmLBpZ462QQtbGeXHOlv UIFtYcFZVJIhsLQOQZm8KFaiMDr2BHQE6yQkX/s9OdFwwV01vsDCvl2aawp7tyVWS0YyyLkDB9XY k72+vtdZ5LC30dfAKUWHL4faGo6Z+J2jBTnSLnUnY8UwsXu8ekOt7wTJMD24yIribRvkleQ9KWr6 UxywUUuUTOxt6etXUw5oajeP56tw9Lx/PvyV/MifiuGq+A91C4xt0pwDrNugxjCfwSfRLF5CfcBK cBSwFGHPPUFBCSdGJru7pBtYfdKjm24kA6lOZ5RSkXfQT8/W5xoJ1vaJE9QzIQGg2ZUpkfKyrLbJ nDR9Hj9w4bUXny6lcrDhaNvl8EqViEY+NHqIyhejLtIvUU6dyVgdE+Q3+PVS9YfD03VQsZ/ARgzd 96iTjgLSCYjONF9b+/Ky7Ou0TalKAanm0u8UumPY3GqR8ibngIHupt+pUAcfAjKKK7a+fcUNbdeF hsr77DVnNUk1HUGtxNagu4c/zSba6GhsT8ZA7v+2DVC+UiuqcZdkl0WLED64n8L0mTdTA7GRiI31 DKxAdBhgxRNdw6qpvY5wvDmXSwc68Nc9SLUuLLBJNdWkJbHDovX+XxkYu86+gcQY8UD7y0gTrqtQ sH8OJ9wKJ9eVT3hRlXEMSQIvAnHyhJtnO6oz2YYrna2kNj3hCfZXgLSQuFWEzosu0HAGkqZ7vGHi IsfWLLgKviPsBkAp6pZfnGU03DaS0fpbZLhzcovEtvcEBZ5SOhvoGozo56U8shKnzuZXqB456IWK Vl1uU850moWg5sWYIVDYd8R/4tj7HjSC5U11nWS7MAr8O0R26K4ojFttWAI6JBS4niNUeKmkZmAW XlFL2AQDJymPVUY6/KtVjSn2G6s1oDG/hYi5Z6JgNBmMuuE3mAF7Jn2lyv5/AIC6wz3XKXQXag7h Wo35RRo4oksGIndJFpCgR0CmltFxj/uJe/1QinlyI+MAg8ZNDy5bJiiSasYWikHu+q/bIYrCx+dg LlKNORRM+WwWsATWlHUYbZDcn5PUQMW9Sgd6KTHRoDXoJ9pXF94UuSe6/2JB4Y7F1a4kJDLbYiDI zG4T23wXBKWN1B0GPG0VejF65ybSYPAAPmWIYQ2R8dkEkM4Q2BvOmKtCpnzOhbmlQrhBWcENYS5w GbXxlfcxPSmmOJJeeMquqFw2q3QqGjdeWmyxvtDoA/Z7Gq6U2niWwpCbannIz0rZrkHy1kpGdacV cHsYukw3KaDvUPHxQMuOoUvcYf/u+SjEWQuJqxt8KZ5TiQ8XXp1BTpxJLXLLcEEDozbo/LRaKwjE kEbdfMOdXpXQHK25SyH4oX4bAhpju5LKgz6uAq5NXP78Hq0g46yJQDnhM6GvmwciqHE2x21Lwmpc skhZDCZLQdijeKgmopAuQeWIfjujIv0xeioyizMrNixV2zzCcmL05t7y40Wi38luATmPVkSOUpfo OVyC3QoDuTVxFJQf/aqG7x0GHWDHztoms1o0mKSsXJ29YxnDTKr+2bGA2QLHnVFpzWZNnzSqVhJO incQhecx5f/iyFiSqcK2sfje6FP4sYh3KNKiInXLUj0sW2CE+qp0U4q7BSzPxr77R+XxuQNGbGZE zKtSaDS6k2u/9F/k4jRj8woU7MCVE1YqrE2POBvWNZhzTbsMbBJiqAqrz7Vf/Aw8+gk1Nf7ecYMj ju8oXBQ+wPcE9M8jCNbozpzsycNJahfhwZQGLxrARApqFK5RwXqt9Goi8c7+e6/95vlOtKeSb4HI LdSLpbRVg6jLlyzVUHv07RU1OfNlXn/Y9hTxuVcHW+C5i6eTolOSgrtj3cY/iDeQdU2MAFhxlFVf PZt8aYGP1Yv3yiczL39Zh5KtEWs9amhNLpxVZbGnR9rbbXX2czZsegjPIgmYiZ/4rsguTcRbVQyY lnP+sjw8cXzkR1sqGPdQ/GD6W4OShi765rvNHNJGYPwEz3TbUeDGQnbLNcWFutIEWaQYlh8c9i1h DL4xzOKPuSSSvOmYKwXaFUt96sbYZY9iI6XajEO3W47jG1k8esm3a+uZjj1wZPq7iAm2tnPHZBc7 yIc66fpCnrb4Zi1fRjCfvj7Tljd5X7feOkqIp4ojTeYu8+MgpGrVP8LD9ExNwr+BY3OexFZdyRwD 8tPWxAZDo0Knfmi8AK8StRb3bIEEzhcVJ5n7SzPmiBUsVhzCLZzB86FKwkQ4+Mbcl/Hb1mjVnxBp 0YI6dITkuBh+y5cyIdgmmU/0rHGw/JOH7MPSn88MO5mBtCVV/yhZiT4OifC1wTLU/jthEfO232N1 Sfm6VYMHvyeal/8GYFdHfWrMkRDPbZv3GJWcoaPuomm/WvIpQuDCSQ0ScGHJp4d9LuO/vwwV6/ks O1fJYEHMJ96ANVc6Cl1RtI4bfOfLQttnMG1fyYfglgSfsJHXOWJ/+hdk9pB0yFA1xHAZDLWUx4Ae WPSrglTxUYUIpvwwBjG6P5F02oZpd5/kiviEeNxGYGopJ+xfcZcIaUVzCa+umj+j8DKEyFZUPZUP vieFhMGDd9zMi1hArtiSbHnqiYkir2rjNaTpdUFX4Va7G+g4y/KrOTMFgVktpADMQ53ov0B6if7K BWezfbVRXd59rrkgtppGYKPPmjZ81CK4xjDF+DmSjAkb6LxkubZYoQjwTI0MH/c/pJL3rpzv8t1H iSBbjhRTuq0FD3b8aZjjy5Jw3AX700jmjSmCv1PisXsWcVDzYLQzl7Oq9nkz3Orv3WxopX1Jnree aPf3IRrp64PDtvoqA117sfXNBq3M9UdqdnFId8CpK9hoV1s63ku3Rnx6nbk7RSbNBnbbkFvBvKc9 L94qzlALBO7qVub+Mgn4BMUo17a0k/BKH3Uj3JKYaXP4JOvrWo0FGuh5vzpqcnDnai0AgSVdKEMf u/XqPLN3Rv/FbdA6rotb0iRsUEDXQEaNzH/2Bzz0SYciWZkeLYjdd9G8PC+RKLxuc3OYlhMERCnU NSFFBUjyVrpKbTMHLLJZG2FtTKDrlO401qUgazatDpfE1in5xjDNU9Jhm+Ljz3zu3nBBfuSA3x/Z XejAByj+CxrGQj1/AmOjnvCf/z9ba1yNFoEaWG6bpiU0SsrpIAnLLuXwwzPDJHAaIovcVrEASCVe BL0HWYEay/s71eXcDRKySATEtysO5UNu5AYob34lVKKFRS69htXqI1d1dM6KsIN+VObxxne6ZRX/ t0DJRh8unQg8MUtU2AlkUEH9j0mHz/77XUvrEyjT/YpAaN5wXHJZ25oVAQ0rsyoTW91Xfuk6Svey xCrlPMu+UEmDcrpU/xk7novfeqeLFHI9Ylz3aoHZonWnBzaLq9qvg0wzGjwT4EdSUSXzgTVbMk07 tmymAAWKHUs/3QOeamdFapjUqeFlrVaNxIMOsw/YPvDizVoDLVRq9yMpZmmCb5PAo0sYbavYPo7D zqeDN00WfaOv2MOd+5DPkg145F1aEe3UKRLumiAYDwHsodxLbg1vYyniVBSFABTNmS1MzaymCvwq b/0hDtz9KO/xcFjw+ZD4Vi0NRT/HAmMPqLuBp0E5FQS/FwDPez+Z+We9iFwRPKF5WkCe5cpShCFG +g1zolrwhOFF42WnhXijZYhs4NYx2uo9SIzeILhR8cyHmuoshq2pWQttyHbGxqSc8LPGNinR8boq VZJrNHX1WEZKJi6cBkf1nW9PuzY3ZG8pRtBm3pXCTm7lstiLsJyZm1vM+1IA1ohUYHU8bSz3hx6l gCHvAUFRqVUh6YLOhyA3mLniZJyZcyIm4JtYqJj6ALJ4k1zsa+5mNvIr0E/kCagp61s6DV4Efhld 5AKWA9ENLIt5pRAh5or5QJMGjCoAkTlRjsjfiVabkA1uJJ4KwdbzhZ5NxRS/3glHxsKSxPvAATud utPNuwTlNKtfkoMCJB/nzX9jfIgCB7xJb421GLoau9aqu7kisZpApi1sO80EVEpn7O6xnCwBNl14 yktdNUrciKA/LgFcTMbUhpLiXzFoxrW441UcyRCN00C9enbGToQ8QWGoXjaoP/xhJRxnRCMVLHjX hOU+FkG/2Aa2lVru8sgzfu3M7IwJ+l6LANPJsy1oMwSwPWdH6RueSeVwmCEz4RnSVEKACxpDvxJe AXz/wV8aC/z2o0/KPAS98daR06uE22G81Gu+fQ9sDR2/b5UaPVr45+lkWyVhZ9pN6jCThGNGtHY6 2lD+yuXIxjJ3hZ28p0isHyhmfy+aUo1KVa6blLT8maWo7rUTjpwyGq4I9EadSAufOTqjUsg/EDqU YegNdPuwBU44z/7TM653sykeRPm0ISx6Btdoirk8F6YUxNQF+zRY2rz5TO5xNicklBPYkyhGmVMD de6v9uj+n6y0oQyLtGTvxp6qmlhgT9K31OllFkHkmguz1QplbmRzdHJlYW0gCmVuZG9iaiAKMTAg MCBvYmogCjw8Ci9MZW5ndGggNzY4Cj4+CnN0cmVhbQo37IxJtQn9ft3WyfRPaA1FaNTdM0jvxwDE mO+sS5gwvJ8QyEZfZWzQyPeHPtd/HeMHE+QsgzmbGZWpEUpxME6LVl8LPUtPN2fhx8QeTCrQCT5N ZybV6g4hmh8UJKJ0wT+N1JC7XNEumUgi/KuOitjPvDFEzcxApptDlvWUOu1hJNZaWV4EOJwtje7z bbDUtjRvDCt+HiT3oMeGZstgnUBpCNC7ecXjqB7KMH9LaBrSWaWatpRXBepkN6RhiCJSZZgEz6PH imXG51YjW0ixaCYdmM2zJTRErzdcmCanxIMagM/te6XToDFAG1eKp8wHkabH8ut9CWhQo+N/vZoY ra1EMPXWteIuK5720Ttmmh4o4HbENxyYFXBq17SKQJjWkkkk9tsFc6BDHHT7JCxALFHZ4OH8ZJYU 9b+sZBtGjSgNnGZCDvlAAoMzAxSKugUDPSP2fYKpP+0msXiiW2E07/D4AqGEff2op+0CLzCCAPo8 iXFUNUq2id3y6r7GNhe0Jzw9YXAD0nSGNKq3jkgY/SpYqgfyDeTV18H1dbPcBAX1HBTfwEr/zX3g FeVu+JJ5ftTJd6aX33uqZ+dYIXOKjv20zdtHV9fsozqKJxfoKHeOYR3nNgNXEjHKZBFMYMUiHfsT jY9KGZP8vqFKHJzY6UcciNjg++25PDvOMzttZZoDkF2HypTXHVS3NyLKV0a0PUb5z0FrJo8gplKw CSbkysl8pnkpudHVz3XW9BU6T5W6VotlsyTV14vjXZCaw7DjEPxNBQdKHYxDyjVmLaBBzk1qZiHr Mhjt00K7V4MdxEw3CpzDlVxgCAHdYzDlQbCdLq0QDjeiqFoGTY2Y+xoKLlAqnhpwtdxHOzUFdGVl 5XZiy6RHPC2MY0bTJHcssFHKwGbuAap5t7EhHPfpMtuGgQnHfJpY97DfKcKC0Evfy8D8zglVfW4L eDvXWyjbZ6qqGItdRoEKjaP0qFPmFO+OqhnZ2SyccWVG21dNr4Kh4RyoPtcCpOJQ+FZgj+5UYj4q xOYKZW5kc3RyZWFtIAplbmRvYmogCjExIDAgb2JqIAo8PAovUiAzCi9QIC0zOTA0Ci9PIChuH2k1 2tCMX6kwegf98Ibo3hzeF1mXNz7goI7hBdkkAykKL0ZpbHRlciAvU3RhbmRhcmQKL0xlbmd0aCAx MjgKL1YgMgovVSAohYUzlTTfVbyjXGbKeMJiIY0AAAAAAAAAAAAAAAAAAAAAKQo+PgplbmRvYmog CjEyIDAgb2JqIAo8PAovVGl0bGUgKCV55pV2yhS+jPtffh8pCi9Qcm9kdWNlciAoH2DokXjYAbSV tkQ6T8PBKo5AQMQDvt3tsAUhXFzZIc2J2WRVPHocXjwGj8QCaR262rvuXHRkbT2pG9MpCi9Nb2RE YXRlICgSN7vGLaJQ5M3hHyxN1cE9KQovQ3JlYXRpb25EYXRlICgSN7vGLaJQ5M3hHyxN1cE9KQo+ PgplbmRvYmogeHJlZgowIDEzCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwMDAxNSAwMDAwMCBu IAowMDAwMDAwMDY2IDAwMDAwIG4gCjAwMDAwMDAxMjUgMDAwMDAgbiAKMDAwMDAwNjY1NyAwMDAw MCBuIAowMDAwMDAwNTY0IDAwMDAwIG4gCjAwMDAwMDA0NTQgMDAwMDAgbiAKMDAwMDAwMDQxNyAw MDAwMCBuIAowMDAwMDAwMzMzIDAwMDAwIG4gCjAwMDAwMDY2MDggMDAwMDAgbiAKMDAwMDAxMjc2 NSAwMDAwMCBuIAowMDAwMDEzNTg4IDAwMDAwIG4gCjAwMDAwMTM3MzggMDAwMDAgbiAKdHJhaWxl cgoKPDwKL0VuY3J5cHQgMTEgMCBSCi9JbmZvIDEyIDAgUgovUm9vdCAxIDAgUgovU2l6ZSAxMwov SUQgWzwzODM1ZWI5NGQwZWUxNzhkNjIzNmM1Mjk2NmY4NTg5OT48ZDY0OWJlZDNkNzQxNTliMTk5 Y2QyMWRlOGRjOWZkYTk+XQo+PgpzdGFydHhyZWYKMTM5MTcKJSVFT0YK --------------000400040002030500050600-- From nfsv4-bounces@ietf.org Sat Jul 14 14:52:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9mjZ-0008Np-NU; Sat, 14 Jul 2007 14:52:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9mjY-0008Nj-Hv for nfsv4@ietf.org; Sat, 14 Jul 2007 14:52:48 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9mjU-0000y9-2r for nfsv4@ietf.org; Sat, 14 Jul 2007 14:52:48 -0400 Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6EIqZQF000188; Sat, 14 Jul 2007 14:52:35 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6EIqTfM006568; Sat, 14 Jul 2007 14:52:29 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 14:52:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] layout stateids and pNFS callbacks Date: Sat, 14 Jul 2007 14:52:28 -0400 Message-ID: In-Reply-To: <46933B43.50702@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] layout stateids and pNFS callbacks Thread-Index: AcfCx5v+wv3/ChKeTd+3liahzDVr/QDf0iUw References: <1184007222.6468.50.camel@heimdal.trondhjem.org> <46933B43.50702@panasas.com> To: , X-OriginalArrivalTime: 14 Jul 2007 18:52:29.0084 (UTC) FILETIME=[20A2E5C0:01C7C648] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: nfsv4@ietf.org, Black_David@emc.com X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Sorry for the delay in getting back to this, but between Trond and Benny, what's been discussed is a specific example of what I had in mind - thanks. Also, Trond asked: > >> Why do you want an alternative to sessions? (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm hearing that sessions have turned out to be a significant implementation concern. (2) Make the pNFS protocol simpler. Right now, the sessions solution to a race condition involves identifying the outstanding operation(s), which is somewhat more involved than having the client and server track a per-layout sequence number. (?3?) The result may be more robust. With sessions, if the server misses an outstanding operation in the sessions state (lots of concurrency there, so lots of opportunities to get things subtly wrong), things go awry. With a sequence number, the check is based on state instead of existence of outstanding operations, and there's much less potential concurrency involved. The "?"s are because I'm not sure how strongly I want to lean on this argument, and it's primarily a consequence of (2) anyhow. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > Trond Myklebust wrote: > > On Mon, 2007-07-09 at 14:31 -0400, Noveck, Dave wrote: > >> I'm getting confused here. Originally, there was a=20 > >> proposal to add stateid's to to layouts. Now it seems > >> that something entirely different is being proposed. > >> > >> It sounds like David Is proposing a single global > >> (for every pair of client and meta-data server) sequence > >> id. Is that in fact the case? It doesn't sound like > >> the fact that stateid's have sequence values meets his > >> requirement to have a "a single sequence count *that is=20 > >> included in all the relevant operations, including callbacks*" > >> at least as part as the "single" part. With stateid's > >> you still have the same issue with delegation recall > >> that Trond points out. =20 > >=20 > > I believe that David is proposing that the client supply a sequence id > > (presumably modelled on the scheme used by LOCK in the v4.0 spec) in the > > GETLAYOUT call, and that the server then uses that sequence id as part > > of the stateid. That way the client always knows whether or not the > > stateid refers to an outstanding call or a completed call. David is that > > correct? >=20 > I won't speak for David, but what I had in mind is a layout stateid per > that's incremented every time the layout changes, i.e. > on each LAYOUTGET and each LAYOUTRETURN. On CB_LAYOUTRECALL, the server > sends the last stateid it knows about for this file and the client must > wait on every outstanding LAYOUTGET and LAYOUTRETURN operation until > it gets this stateid back before starting to return layouts for this > recall. Any further LAYOUTGETs should be rejected by the server if they > conflict with the recall, otherwise they can be served. The recall is done > either by returning a NOMATCHINGLAYOUT error to CB_LAYOUTRECALL or by > a respective LAYOUTRETURN. >=20 > Again, I propose to make this explicit by e.g. quoting the layout stateid > the CB_LAYOUTRECALL was sent for otherwise it will be harder to handle an > inflight LAYOUTRETURN that hasn't been seen by the server before it sent > out the CB_LAYOUTRECALL and that will effectively complete the recall. >=20 > Note that the per-file layout stateid does not solve the problem for > recalling and returning layouts for FSID and ALL. A per-client layout > stateid may help here but it can limit parallelism. >=20 > Benny >=20 > >=20 > > Trond > >=20 > >> -----Original Message----- > >> From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 > >> Sent: Monday, July 09, 2007 1:22 PM > >> To: Black_David@emc.com > >> Cc: nfsv4@ietf.org > >> Subject: RE: [nfsv4] layout stateids and pNFS callbacks > >> > >> > >> On Mon, 2007-07-09 at 13:05 -0400, Black_David@emc.com wrote: > >>> That depends on the details of how they're used. We have=20 > experience > >>> (i.e., running code) with FMP for MPFS that a single=20 > sequence count > >>> *that is included in all the relevant operations,=20 > including callbacks* > >>> is sufficient to sort this out if one pays close=20 > attention to all the > >>> details. > >>> > >>> The class of race you describe is handled at the client=20 > by observing > >>> that the callback carries seqid "n", but the client=20 > hasn't processed > >>> the reply to operation "n", and hence the client holds=20 > the callback > >>> until operation "n" (the OPEN) is processed. OTOH, if=20 > the callback > >>> doesn't carry a seqid, the game's over ... and the fix is=20 > not to make > >>> that design mistake ;-). > >> OK. I see where you're coming from now. Basically you are=20 > extending the > >> v4.0 sequencing scheme to work with callbacks? I suppose=20 > that can work, > >> but it does seem a tad inelegant. > >> > >> Why do you want an alternative to sessions? > >> > >> Trond > >> > >> > >> _______________________________________________ > >> nfsv4 mailing list > >> nfsv4@ietf.org > >> https://www1.ietf.org/mailman/listinfo/nfsv4 > >=20 > >=20 > > _______________________________________________ > > nfsv4 mailing list > > nfsv4@ietf.org > > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 >=20 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 16 10:27:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IARY4-00071Y-H7; Mon, 16 Jul 2007 10:27:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IARY3-00071E-2j for nfsv4@ietf.org; Mon, 16 Jul 2007 10:27:39 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IARY2-0008H2-FZ for nfsv4@ietf.org; Mon, 16 Jul 2007 10:27:39 -0400 X-IronPort-AV: E=Sophos;i="4.16,542,1175497200"; d="scan'208";a="82554443" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 16 Jul 2007 07:26:32 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6GEQVPH007221; Mon, 16 Jul 2007 07:26:31 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 07:26:31 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 07:26:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] layout stateids and pNFS callbacks Date: Mon, 16 Jul 2007 10:26:29 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] layout stateids and pNFS callbacks Thread-Index: AcfCx5v+wv3/ChKeTd+3liahzDVr/QDf0iUwAAekW8A= From: "Noveck, Dave" To: , , X-OriginalArrivalTime: 16 Jul 2007 14:26:31.0336 (UTC) FILETIME=[4DE74A80:01C7C7B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org > (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm > hearing that sessions have turned out to be a significant > implementation concern. V4.0.5? Is there going to be a spec for this and if so, who is going to write it? And if not, how are you going to get inter-operable implementations? If you have implementation concerns about sessions, then you will really have them about a protocol without a spec. If the result is a better v4.1, I'm perfectly OK with this change, but I think trying to optimize V4.1 for V4.0.5 is a real mistake. -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: Saturday, July 14, 2007 2:52 PM To: bhalevy@panasas.com; trond.myklebust@fys.uio.no Cc: nfsv4@ietf.org; Black_David@emc.com Subject: RE: [nfsv4] layout stateids and pNFS callbacks Sorry for the delay in getting back to this, but between Trond and Benny, what's been discussed is a specific example of what I had in mind - thanks. Also, Trond asked: > >> Why do you want an alternative to sessions? (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm hearing that sessions have turned out to be a significant implementation concern. (2) Make the pNFS protocol simpler. Right now, the sessions solution to a race condition involves identifying the outstanding operation(s), which is somewhat more involved than having the client and server track a per-layout sequence number. (?3?) The result may be more robust. With sessions, if the server misses an outstanding operation in the sessions state (lots of concurrency there, so lots of opportunities to get things subtly wrong), things go awry. With a sequence number, the check is based on state instead of existence of outstanding operations, and there's much less potential concurrency involved. The "?"s are because I'm not sure how strongly I want to lean on this argument, and it's primarily a consequence of (2) anyhow. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > Trond Myklebust wrote: > > On Mon, 2007-07-09 at 14:31 -0400, Noveck, Dave wrote: > >> I'm getting confused here. Originally, there was a proposal to add > >> stateid's to to layouts. Now it seems that something entirely=20 > >> different is being proposed. > >> > >> It sounds like David Is proposing a single global (for every pair > >> of client and meta-data server) sequence id. Is that in fact the=20 > >> case? It doesn't sound like the fact that stateid's have sequence=20 > >> values meets his requirement to have a "a single sequence count=20 > >> *that is included in all the relevant operations, including=20 > >> callbacks*" > >> at least as part as the "single" part. With stateid's you still=20 > >> have the same issue with delegation recall that Trond points out. > >=20 > > I believe that David is proposing that the client supply a sequence id > > (presumably modelled on the scheme used by LOCK in the v4.0 spec) in the > > GETLAYOUT call, and that the server then uses that sequence id as part > > of the stateid. That way the client always knows whether or not the > > stateid refers to an outstanding call or a completed call. David is that > > correct? >=20 > I won't speak for David, but what I had in mind is a layout stateid per > that's incremented every time the layout changes, i.e. > on each LAYOUTGET and each LAYOUTRETURN. On CB_LAYOUTRECALL, the server > sends the last stateid it knows about for this file and the client must > wait on every outstanding LAYOUTGET and LAYOUTRETURN operation until > it gets this stateid back before starting to return layouts for this=20 > recall. Any further LAYOUTGETs should be rejected by the server if they > conflict with the recall, otherwise they can be served. The recall is done > either by returning a NOMATCHINGLAYOUT error to CB_LAYOUTRECALL or by > a respective LAYOUTRETURN. >=20 > Again, I propose to make this explicit by e.g. quoting the layout stateid > the CB_LAYOUTRECALL was sent for otherwise it will be harder to handle an > inflight LAYOUTRETURN that hasn't been seen by the server before it sent > out the CB_LAYOUTRECALL and that will effectively complete the recall. >=20 > Note that the per-file layout stateid does not solve the problem for > recalling and returning layouts for FSID and ALL. A per-client layout > stateid may help here but it can limit parallelism. >=20 > Benny >=20 > >=20 > > Trond > >=20 > >> -----Original Message----- > >> From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] > >> Sent: Monday, July 09, 2007 1:22 PM > >> To: Black_David@emc.com > >> Cc: nfsv4@ietf.org > >> Subject: RE: [nfsv4] layout stateids and pNFS callbacks > >> > >> > >> On Mon, 2007-07-09 at 13:05 -0400, Black_David@emc.com wrote: > >>> That depends on the details of how they're used. We have > experience > >>> (i.e., running code) with FMP for MPFS that a single > sequence count > >>> *that is included in all the relevant operations, > including callbacks* > >>> is sufficient to sort this out if one pays close > attention to all the > >>> details. > >>> > >>> The class of race you describe is handled at the client > by observing > >>> that the callback carries seqid "n", but the client > hasn't processed > >>> the reply to operation "n", and hence the client holds > the callback > >>> until operation "n" (the OPEN) is processed. OTOH, if > the callback > >>> doesn't carry a seqid, the game's over ... and the fix is > not to make > >>> that design mistake ;-). > >> OK. I see where you're coming from now. Basically you are > extending the > >> v4.0 sequencing scheme to work with callbacks? I suppose > that can work, > >> but it does seem a tad inelegant. > >> > >> Why do you want an alternative to sessions? > >> > >> Trond > >> > >> > >> _______________________________________________ > >> nfsv4 mailing list > >> nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 > >=20 > >=20 > > _______________________________________________ > > nfsv4 mailing list > > nfsv4@ietf.org > > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 >=20 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From yanxu@nyu.edu Mon Jul 16 10:38:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IARiN-0001dt-G2 for nfsv4-archive@lists.ietf.org; Mon, 16 Jul 2007 10:38:19 -0400 Received: from anantes-256-1-118-253.w90-1.abo.wanadoo.fr ([90.1.245.253]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IARiD-0000G1-Mn for nfsv4-archive@lists.ietf.org; Mon, 16 Jul 2007 10:38:19 -0400 Received: from dlqik ([211.68.94.127]) by ANantes-256-1-118-253.w90-1.abo.wanadoo.fr with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Jul 2007 16:37:40 +0200 Message-ID: <469B82B4.1080802@nyu.edu> Date: Mon, 16 Jul 2007 16:37:40 +0200 From: Morris User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: I can't get my mind around the involvement of Honda but it's a intriguing sidebar to this. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.5 (+++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 SZSN Announces Sales Income UP 37.6% Over Last Year! Shandong Zhouyuan Seed and Nursery Co., Ltd (SZSN) $0.38 UP 15% (9:36AM EST) SZSN continues to climb as more great news unfolds. Read the news and get on SZSN today! you go, Danger Mouse! " Of course they are accessible NO-BODY wants to talk to Coulthard, Button, or Schumi; they aren't making news. back to "topic", las vegas, the capital of hedonism, is the worst place to hold a gp. We have been getting to the finals but it seemed like we couldn't finish the deal. What will the Red Army become; the Snap, Crackle, Pops? we'll toss it to our esteemed colleague Allan Brewer to keep ya up to date on tomorrow's doings at Nashville Super Speedway. George and Peter will tell you, I'm one of the hard core Ferrari fans around these parts, and even I'm not blasting Ron for this. Yes, another overt Ferrari dirty trick to add to their legacy of high crimes and misdemeanors! He is with his son as a priviledge and I hope the proper authorities revoke that priviledge. going to have to start over again with driver interviews if this goes on much longer. Maybe we could pass "the hat" to get her another? That was an important team win for everyone. We were strong at Watkins Glen, so we're excited about Mid Ohio. Raping and pillaging is the key to his business model. I was trying to think like a sane businessman. Franchitti won at Indianapolis, Iowa and Richmond. He's not going to be racing forever. She was mine before she was Todt's. After all, if he can't perform on the track, who would want to talk to him? I can't believe they'd fire him, as long as the market continues to grow and expand. We were strong at Watkins Glen, so we're excited about Mid Ohio. At the very least, the world got to know more than four ICS drivers a little better tonight! Still, we are not convinced. Also, how would Ferrari pull off such a blatant move on a world stage - THAT THEY instigated? Despite starting from the back, Massa confirmed the pace of the red cars. Bob Varsha posed the notion that Ferrari was so concerned about Stepney leaving after fourteen years that they were attempting to sabotage his reputation. Proud of the Iceman, though. He has the knowledge of everything Ferrari has done, good bad or otherwise, in their dominating Schumi years. UPDATE: According to an e-mail I just received, this is apparently 'my Car': Works for me! We hope the IHJ throws down some LAW on Sam Sr. actually embarasses Vince. IRL News: MoneyTeaser: Just One Week From Today. After all, if he can't perform on the track, who would want to talk to him? Button on the other hand would have charged straight in with a rendition of "Rule Britania". Each time we came up behind somebody, it never seemed to go our way. corporate greed is one of the worst things our society is facing right now and to let it happen in a sporting venue seen worldwide is "the most" damaging issue to our beloved way of life. From then on, we were struggling to get back up to him. Where's the long-term planning in that? Try to contain your glee as you anticipate our stellar reports and images from the scene. I wonder if she has others? the world is in a fight for it's econcomic life against those who would love to see us all pray to allah and have all women to wear birkas and lose the few rights they have fought for. As to where it should go next? Target Chip Ganassi Racing and Rahal Letterman Racing enter the Indy Pro Series for the first time. First he starts off by refusing to talk to the pre-race broadcasters. Does McLaren have some sort of gag order on him? To be honest, our car just seemed to get stronger throughout the race. From nfsv4-bounces@ietf.org Mon Jul 16 12:09:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAT8z-0003sh-5I; Mon, 16 Jul 2007 12:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAT8w-0003sZ-Ui; Mon, 16 Jul 2007 12:09:50 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAT8r-00010K-QF; Mon, 16 Jul 2007 12:09:50 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm86469bb83e; Tue, 17 Jul 2007 00:21:27 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm7f4696eb48; Fri, 13 Jul 2007 06:09:40 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 13 Jul 2007 06:09:40 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I954I-0004oO-4V; Thu, 12 Jul 2007 16:15:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9543-0003qo-1k; Thu, 12 Jul 2007 16:15:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9542-0003xV-Nt; Thu, 12 Jul 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 934F726E86; Thu, 12 Jul 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I9542-0006cJ-DR; Thu, 12 Jul 2007 16:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 12 Jul 2007 16:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.2 (++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: nfsv4@ietf.org Subject: [nfsv4] I-D ACTION:draft-ietf-nfsv4-minorversion1-12.txt X-BeenThere: nfsv4@ietf.org Reply-To: internet-drafts@ietf.org List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF. Title : NFSv4 Minor Version 1 Author(s) : S. Shepler, et al. Filename : draft-ietf-nfsv4-minorversion1-12.txt Pages : 491 Date : 2007-7-12 This Internet-Draft describes NFSv4 minor version one, including features retained from the base protocol and protocol extensions made subsequently. The current draft includes description of the major extensions, Sessions, Directory Delegations, and parallel NFS (pNFS). This Internet-Draft is an active work item of the NFSv4 working group. Active and resolved issues may be found in the issue tracker at: http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4. New issues related to this document should be raised with the NFSv4 Working Group nfsv4@ietf.org and logged in the issue tracker. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nfsv4-minorversion1-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nfsv4-minorversion1-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-12154408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nfsv4-minorversion1-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nfsv4-minorversion1-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12154408.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --NextPart-- From nfsv4-bounces@ietf.org Mon Jul 16 13:05:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAU0Z-0006oC-5Z; Mon, 16 Jul 2007 13:05:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAU0X-0006nj-JW for nfsv4@ietf.org; Mon, 16 Jul 2007 13:05:13 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAU0W-0005Pr-Ur for nfsv4@ietf.org; Mon, 16 Jul 2007 13:05:13 -0400 X-IronPort-AV: E=Sophos;i="4.16,542,1175497200"; d="scan'208";a="82611228" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 16 Jul 2007 10:05:11 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6GH1qsT024011; Mon, 16 Jul 2007 10:04:27 -0700 (PDT) Received: from SACEXMV01.hq.netapp.com ([10.99.190.107]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 10:01:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] layout stateids and pNFS callbacks Date: Mon, 16 Jul 2007 10:01:54 -0700 Message-ID: <01AE8AF878612047A442668306EAEB05C17C9F@SACEXMV01.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] layout stateids and pNFS callbacks Thread-Index: AcfCx5v+wv3/ChKeTd+3liahzDVr/QDf0iUwAAekW8AAWUT00A== References: From: "Muntz, Daniel" To: "Noveck, Dave" , , , X-OriginalArrivalTime: 16 Jul 2007 17:01:56.0119 (UTC) FILETIME=[03E84270:01C7C7CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org If someone is thinking of doing pNFS for v3/v4.0, sign me up. I bet there are a few others with similar interests. -Dan -----Original Message----- From: Noveck, Dave=20 Sent: Monday, July 16, 2007 7:26 AM To: Black_David@emc.com; bhalevy@panasas.com; trond.myklebust@fys.uio.no Cc: nfsv4@ietf.org Subject: RE: [nfsv4] layout stateids and pNFS callbacks > (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm > hearing that sessions have turned out to be a significant > implementation concern. V4.0.5? Is there going to be a spec for this and if so, who is going to write it? And if not, how are you going to get inter-operable implementations? If you have implementation concerns about sessions, then you will really have them about a protocol without a spec. If the result is a better v4.1, I'm perfectly OK with this change, but I think trying to optimize V4.1 for V4.0.5 is a real mistake. -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Saturday, July 14, 2007 2:52 PM To: bhalevy@panasas.com; trond.myklebust@fys.uio.no Cc: nfsv4@ietf.org; Black_David@emc.com Subject: RE: [nfsv4] layout stateids and pNFS callbacks Sorry for the delay in getting back to this, but between Trond and Benny, what's been discussed is a specific example of what I had in mind - thanks. Also, Trond asked: > >> Why do you want an alternative to sessions? (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm hearing that sessions have turned out to be a significant implementation concern. (2) Make the pNFS protocol simpler. Right now, the sessions solution to a race condition involves identifying the outstanding operation(s), which is somewhat more involved than having the client and server track a per-layout sequence number. (?3?) The result may be more robust. With sessions, if the server misses an outstanding operation in the sessions state (lots of concurrency there, so lots of opportunities to get things subtly wrong), things go awry. With a sequence number, the check is based on state instead of existence of outstanding operations, and there's much less potential concurrency involved. The "?"s are because I'm not sure how strongly I want to lean on this argument, and it's primarily a consequence of (2) anyhow. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > Trond Myklebust wrote: > > On Mon, 2007-07-09 at 14:31 -0400, Noveck, Dave wrote: > >> I'm getting confused here. Originally, there was a proposal to add > >> stateid's to to layouts. Now it seems that something entirely=20 > >> different is being proposed. > >> > >> It sounds like David Is proposing a single global (for every pair=20 > >> of client and meta-data server) sequence id. Is that in fact the=20 > >> case? It doesn't sound like the fact that stateid's have sequence=20 > >> values meets his requirement to have a "a single sequence count=20 > >> *that is included in all the relevant operations, including=20 > >> callbacks*" > >> at least as part as the "single" part. With stateid's you still=20 > >> have the same issue with delegation recall that Trond points out. > >=20 > > I believe that David is proposing that the client supply a sequence id > > (presumably modelled on the scheme used by LOCK in the v4.0 spec) in the > > GETLAYOUT call, and that the server then uses that sequence id as part > > of the stateid. That way the client always knows whether or not the=20 > > stateid refers to an outstanding call or a completed call. David is that > > correct? >=20 > I won't speak for David, but what I had in mind is a layout stateid per > that's incremented every time the layout changes, i.e. > on each LAYOUTGET and each LAYOUTRETURN. On CB_LAYOUTRECALL, the server > sends the last stateid it knows about for this file and the client must > wait on every outstanding LAYOUTGET and LAYOUTRETURN operation until=20 > it gets this stateid back before starting to return layouts for this=20 > recall. Any further LAYOUTGETs should be rejected by the server if they > conflict with the recall, otherwise they can be served. The recall is done > either by returning a NOMATCHINGLAYOUT error to CB_LAYOUTRECALL or by=20 > a respective LAYOUTRETURN. >=20 > Again, I propose to make this explicit by e.g. quoting the layout stateid > the CB_LAYOUTRECALL was sent for otherwise it will be harder to handle an > inflight LAYOUTRETURN that hasn't been seen by the server before it sent > out the CB_LAYOUTRECALL and that will effectively complete the recall. >=20 > Note that the per-file layout stateid does not solve the problem for=20 > recalling and returning layouts for FSID and ALL. A per-client layout > stateid may help here but it can limit parallelism. >=20 > Benny >=20 > >=20 > > Trond > >=20 > >> -----Original Message----- > >> From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] > >> Sent: Monday, July 09, 2007 1:22 PM > >> To: Black_David@emc.com > >> Cc: nfsv4@ietf.org > >> Subject: RE: [nfsv4] layout stateids and pNFS callbacks > >> > >> > >> On Mon, 2007-07-09 at 13:05 -0400, Black_David@emc.com wrote: > >>> That depends on the details of how they're used. We have > experience > >>> (i.e., running code) with FMP for MPFS that a single > sequence count > >>> *that is included in all the relevant operations, > including callbacks* > >>> is sufficient to sort this out if one pays close > attention to all the > >>> details. > >>> > >>> The class of race you describe is handled at the client > by observing > >>> that the callback carries seqid "n", but the client > hasn't processed > >>> the reply to operation "n", and hence the client holds > the callback > >>> until operation "n" (the OPEN) is processed. OTOH, if > the callback > >>> doesn't carry a seqid, the game's over ... and the fix is > not to make > >>> that design mistake ;-). > >> OK. I see where you're coming from now. Basically you are > extending the > >> v4.0 sequencing scheme to work with callbacks? I suppose > that can work, > >> but it does seem a tad inelegant. > >> > >> Why do you want an alternative to sessions? > >> > >> Trond > >> > >> > >> _______________________________________________ > >> nfsv4 mailing list > >> nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 > >=20 > >=20 > > _______________________________________________ > > nfsv4 mailing list > > nfsv4@ietf.org > > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 >=20 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 16 13:41:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUZd-0006U0-HQ; Mon, 16 Jul 2007 13:41:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUZb-0006Ra-Ru for nfsv4@ietf.org; Mon, 16 Jul 2007 13:41:27 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAUZX-0004UX-0v for nfsv4@ietf.org; Mon, 16 Jul 2007 13:41:27 -0400 Received: by nz-out-0506.google.com with SMTP id n1so875242nzf for ; Mon, 16 Jul 2007 10:41:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=mWgN1KXP6CDoikB5jRmFJ9k9M1b71HnVkaqqZZvgV8Nzq4J9rrM2RQwhQnw5n72lpEug0Yk14gyaj4kdDds+a1Aq8a+ZF6SUFkKxGTZhVvtPkw8HBonK+KVoe+h3aOchXizUwY4IfsJ1wzXjxVqUcbMgKht2/K2eAyzN7JxLzsQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=c9l377L1po8tJsK7pRic3lGgW7UnT85nNauZlkNP92aaTiWV/600Ah4Sdb66P4lbwXGqw34bDvnJMnv8QHyGHhbWl1pat4Q4nydFhZRnxqvxI0f0CYrNExtocgJfip+awjBUasyrGtqvX5M7y2YdUQ7TCOKkETStQ8mirQt7ZEk= Received: by 10.143.161.3 with SMTP id n3mr336973wfo.1184607682092; Mon, 16 Jul 2007 10:41:22 -0700 (PDT) Received: by 10.142.98.1 with HTTP; Mon, 16 Jul 2007 10:41:21 -0700 (PDT) Message-ID: <89c397150707161041j2fa87f28jd43e34e97c7cc12a@mail.gmail.com> Date: Mon, 16 Jul 2007 13:41:21 -0400 From: "William A. (Andy) Adamson" To: "Noveck, Dave" Subject: Re: [nfsv4] layout stateids and pNFS callbacks In-Reply-To: MIME-Version: 1.0 References: X-Google-Sender-Auth: 7e34116d3ecd841d X-Spam-Score: 0.1 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: bhalevy@panasas.com, Black_David@emc.com, nfsv4@ietf.org, trond.myklebust@fys.uio.no X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1469471922==" Errors-To: nfsv4-bounces@ietf.org --===============1469471922== Content-Type: multipart/alternative; boundary="----=_Part_51110_31258588.1184607681461" ------=_Part_51110_31258588.1184607681461 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/16/07, Noveck, Dave wrote: > > > (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm > > hearing that sessions have turned out to be a significant > > implementation concern. > > V4.0.5? Is there going to be a spec for this and if so, who is going to > write it? And if not, how are you going to get inter-operable > implementations? If you have implementation concerns about sessions, > then you will really have them about a protocol without a spec. > > If the result is a better v4.1, I'm perfectly OK with this change, but I > think trying to optimize V4.1 for V4.0.5 is a real mistake. If I remember correctly, the main reason that pNFS requires Sessions is to handle the races between LAYOUTGET/RETURN etc. Perhaps what David is suggesting it that NFSv4.1 pNFS with his proposed stateid changes would not require sessions, and therefore be an independent 4.1 feature. -->Andy -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Saturday, July 14, 2007 2:52 PM > To: bhalevy@panasas.com; trond.myklebust@fys.uio.no > Cc: nfsv4@ietf.org; Black_David@emc.com > Subject: RE: [nfsv4] layout stateids and pNFS callbacks > > Sorry for the delay in getting back to this, but between Trond and > Benny, what's been discussed is a specific example of what I had in mind > - thanks. > > Also, Trond asked: > > > >> Why do you want an alternative to sessions? > > (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm > hearing that sessions have turned out to be a significant > implementation concern. > (2) Make the pNFS protocol simpler. Right now, the sessions > solution to a race condition involves identifying the > outstanding operation(s), which is somewhat more involved > than having the client and server track a per-layout sequence > number. > (?3?) The result may be more robust. With sessions, if the server > misses an outstanding operation in the sessions state (lots > of concurrency there, so lots of opportunities to get things > subtly wrong), things go awry. With a sequence number, the > check is based on state instead of existence of outstanding > operations, and there's much less potential concurrency > involved. The "?"s are because I'm not sure how strongly > I want to lean on this argument, and it's primarily a > consequence of (2) anyhow. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > Trond Myklebust wrote: > > > On Mon, 2007-07-09 at 14:31 -0400, Noveck, Dave wrote: > > >> I'm getting confused here. Originally, there was a proposal to add > > >> stateid's to to layouts. Now it seems that something entirely > > >> different is being proposed. > > >> > > >> It sounds like David Is proposing a single global (for every pair > > >> of client and meta-data server) sequence id. Is that in fact the > > >> case? It doesn't sound like the fact that stateid's have sequence > > >> values meets his requirement to have a "a single sequence count > > >> *that is included in all the relevant operations, including > > >> callbacks*" > > >> at least as part as the "single" part. With stateid's you still > > >> have the same issue with delegation recall that Trond points out. > > > > > > I believe that David is proposing that the client supply a sequence > id > > > (presumably modelled on the scheme used by LOCK in the v4.0 spec) in > the > > > GETLAYOUT call, and that the server then uses that sequence id as > part > > > of the stateid. That way the client always knows whether or not the > > > stateid refers to an outstanding call or a completed call. David is > that > > > correct? > > > > I won't speak for David, but what I had in mind is a layout stateid > per > > that's incremented every time the layout changes, > i.e. > > on each LAYOUTGET and each LAYOUTRETURN. On CB_LAYOUTRECALL, the > server > > sends the last stateid it knows about for this file and the client > must > > wait on every outstanding LAYOUTGET and LAYOUTRETURN operation until > > it gets this stateid back before starting to return layouts for this > > recall. Any further LAYOUTGETs should be rejected by the server if > they > > conflict with the recall, otherwise they can be served. The recall is > done > > either by returning a NOMATCHINGLAYOUT error to CB_LAYOUTRECALL or by > > a respective LAYOUTRETURN. > > > > Again, I propose to make this explicit by e.g. quoting the layout > stateid > > the CB_LAYOUTRECALL was sent for otherwise it will be harder to handle > an > > inflight LAYOUTRETURN that hasn't been seen by the server before it > sent > > out the CB_LAYOUTRECALL and that will effectively complete the recall. > > > > Note that the per-file layout stateid does not solve the problem for > > recalling and returning layouts for FSID and ALL. A per-client layout > > > stateid may help here but it can limit parallelism. > > > > Benny > > > > > > > > Trond > > > > > >> -----Original Message----- > > >> From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] > > >> Sent: Monday, July 09, 2007 1:22 PM > > >> To: Black_David@emc.com > > >> Cc: nfsv4@ietf.org > > >> Subject: RE: [nfsv4] layout stateids and pNFS callbacks > > >> > > >> > > >> On Mon, 2007-07-09 at 13:05 -0400, Black_David@emc.com wrote: > > >>> That depends on the details of how they're used. We have > > experience > > >>> (i.e., running code) with FMP for MPFS that a single > > sequence count > > >>> *that is included in all the relevant operations, > > including callbacks* > > >>> is sufficient to sort this out if one pays close > > attention to all the > > >>> details. > > >>> > > >>> The class of race you describe is handled at the client > > by observing > > >>> that the callback carries seqid "n", but the client > > hasn't processed > > >>> the reply to operation "n", and hence the client holds > > the callback > > >>> until operation "n" (the OPEN) is processed. OTOH, if > > the callback > > >>> doesn't carry a seqid, the game's over ... and the fix is > > not to make > > >>> that design mistake ;-). > > >> OK. I see where you're coming from now. Basically you are > > extending the > > >> v4.0 sequencing scheme to work with callbacks? I suppose > > that can work, > > >> but it does seem a tad inelegant. > > >> > > >> Why do you want an alternative to sessions? > > >> > > >> Trond > > >> > > >> > > >> _______________________________________________ > > >> nfsv4 mailing list > > >> nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 > > > > > > > > > _______________________________________________ > > > nfsv4 mailing list > > > nfsv4@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nfsv4 > > > > > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > ------=_Part_51110_31258588.1184607681461 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 7/16/07, Noveck, Dave <Dave.Noveck@netapp.com> wrote:
> (1) Make it possible for pNFS to work in v4.0 w/o sessions.  I'm
>       hearing that sessions have turned out to be a significant
>       implementation concern.

V4.0.5?  Is there going to be a spec for this and if so, who is going to
write it?  And if not, how are you going to get inter-operable
implementations?  If you have implementation concerns about sessions,
then you will really have them about a protocol without a spec.

If the result is a better v4.1, I'm perfectly OK with this change, but I
think trying to optimize V4.1 for V4.0.5 is a real mistake.


If I remember correctly, the main reason that pNFS requires Sessions is to handle the races between LAYOUTGET/RETURN etc. Perhaps what David is suggesting it that NFSv4.1 pNFS with his proposed stateid changes would not require sessions, and therefore be an independent 4.1 feature.

-->Andy

-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Saturday, July 14, 2007 2:52 PM
To: bhalevy@panasas.com; trond.myklebust@fys.uio.no
Cc: nfsv4@ietf.org; Black_David@emc.com
Subject: RE: [nfsv4] layout stateids and pNFS callbacks

Sorry for the delay in getting back to this, but between Trond and
Benny, what's been discussed is a specific example of what I had in mind
- thanks.

Also, Trond asked:

> >> Why do you want an alternative to sessions?

(1) Make it possible for pNFS to work in v4.0 w/o sessions.  I'm
        hearing that sessions have turned out to be a significant
        implementation concern.
(2) Make the pNFS protocol simpler.  Right now, the sessions
        solution to a race condition involves identifying the
        outstanding operation(s), which is somewhat more involved
        than having the client and server track a per-layout sequence
        number.
(?3?) The result may be more robust.  With sessions, if the server
        misses an outstanding operation in the sessions state (lots
        of concurrency there, so lots of opportunities to get things
        subtly wrong), things go awry.  With a sequence number, the
        check is based on state instead of existence of outstanding
        operations, and there's much less potential concurrency
        involved.  The "?"s are because I'm not sure how strongly
        I want to lean on this argument, and it's primarily a
        consequence of (2) anyhow.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------

> Trond Myklebust wrote:
> > On Mon, 2007-07-09 at 14:31 -0400, Noveck, Dave wrote:
> >> I'm getting confused here.  Originally, there was a proposal to add
> >> stateid's to to layouts.  Now it seems that something entirely
> >> different is being proposed.
> >>
> >> It sounds like David Is proposing a single global (for every pair
> >> of client and meta-data server) sequence id.  Is that in fact the
> >> case?  It doesn't sound like the fact that stateid's have sequence
> >> values meets his requirement to have a "a single sequence count
> >> *that is included in all the relevant operations, including
> >> callbacks*"
> >> at least as part as the "single" part.  With stateid's you still
> >> have the same issue with delegation recall that Trond points out.
> >
> > I believe that David is proposing that the client supply a sequence
id
> > (presumably modelled on the scheme used by LOCK in the v4.0 spec) in
the
> > GETLAYOUT call, and that the server then uses that sequence id as
part
> > of the stateid. That way the client always knows whether or not the
> > stateid refers to an outstanding call or a completed call. David is
that
> > correct?
>
> I won't speak for David, but what I had in mind is a layout stateid
per
> <mds, client, file> that's incremented every time the layout changes,
i.e.
> on each LAYOUTGET and each LAYOUTRETURN.  On CB_LAYOUTRECALL, the
server
> sends the last stateid it knows about for this file and the client
must
> wait on every outstanding LAYOUTGET and LAYOUTRETURN operation until
> it gets this stateid back before starting to return layouts for this
> recall.  Any further LAYOUTGETs should be rejected by the server if
they
> conflict with the recall, otherwise they can be served.  The recall is
done
> either by returning a NOMATCHINGLAYOUT error to CB_LAYOUTRECALL or by
> a respective LAYOUTRETURN.
>
> Again, I propose to make this explicit by e.g. quoting the layout
stateid
> the CB_LAYOUTRECALL was sent for otherwise it will be harder to handle
an
> inflight LAYOUTRETURN that hasn't been seen by the server before it
sent
> out the CB_LAYOUTRECALL and that will effectively complete the recall.
>
> Note that the per-file layout stateid does not solve the problem for
> recalling and returning layouts for FSID and ALL.  A per-client layout

> stateid may help here but it can limit parallelism.
>
> Benny
>
> >
> > Trond
> >
> >> -----Original Message-----
> >> From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no ]
> >> Sent: Monday, July 09, 2007 1:22 PM
> >> To: Black_David@emc.com
> >> Cc: nfsv4@ietf.org
> >> Subject: RE: [nfsv4] layout stateids and pNFS callbacks
> >>
> >>
> >> On Mon, 2007-07-09 at 13:05 -0400, Black_David@emc.com wrote:
> >>> That depends on the details of how they're used.  We have
> experience
> >>> (i.e., running code) with FMP for MPFS that a single
> sequence count
> >>> *that is included in all the relevant operations,
> including callbacks*
> >>> is sufficient to sort this out if one pays close
> attention to all the
> >>> details.
> >>>
> >>> The class of race you describe is handled at the client
> by observing
> >>> that the callback carries seqid "n", but the client
> hasn't processed
> >>> the reply to operation "n", and hence the client holds
> the callback
> >>> until operation "n" (the OPEN) is processed.  OTOH, if
> the callback
> >>> doesn't carry a seqid, the game's over ... and the fix is
> not to make
> >>> that design mistake ;-).
> >> OK. I see where you're coming from now. Basically you are
> extending the
> >> v4.0 sequencing scheme to work with callbacks? I suppose
> that can work,
> >> but it does seem a tad inelegant.
> >>
> >> Why do you want an alternative to sessions?
> >>
> >> Trond
> >>
> >>
> >> _______________________________________________
> >> nfsv4 mailing list
> >> nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www1.ietf.org/mailman/listinfo/nfsv4
>
>
>

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4


------=_Part_51110_31258588.1184607681461-- --===============1469471922== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============1469471922==-- From nfsv4-bounces@ietf.org Mon Jul 16 14:07:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUyM-0007Vn-7W; Mon, 16 Jul 2007 14:07:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAUyJ-0007SR-Qe for nfsv4@ietf.org; Mon, 16 Jul 2007 14:06:59 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAUyE-0005yY-P8 for nfsv4@ietf.org; Mon, 16 Jul 2007 14:06:59 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6GI6scF016321 for ; Mon, 16 Jul 2007 18:06:54 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLA00D01A12UE00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Mon, 16 Jul 2007 12:06:54 -0600 (MDT) Received: from [10.1.194.250] ([192.18.98.62]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLA004QQABHDMA6@mail-amer.sun.com>; Mon, 16 Jul 2007 12:06:54 -0600 (MDT) Date: Mon, 16 Jul 2007 13:06:57 -0500 From: Robert Gordon Subject: Re: [nfsv4] layout stateids and pNFS callbacks In-reply-to: To: Black_David@emc.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <1184007222.6468.50.camel@heimdal.trondhjem.org> <46933B43.50702@panasas.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: bhalevy@panasas.com, nfsv4@ietf.org, trond.myklebust@fys.uio.no X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 14, 2007, at 1:52 PM, Black_David@emc.com wrote: >>>> Why do you want an alternative to sessions? > > (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm > hearing that sessions have turned out to be a significant > implementation concern. Perhaps the approach should be to identify those implementation concerns and address those issues, rather than having the appearance (perceived or real) of back tracking. Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 16 14:20:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVBQ-0003ka-2C; Mon, 16 Jul 2007 14:20:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVBN-0003NU-Jt for nfsv4@ietf.org; Mon, 16 Jul 2007 14:20:29 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAVBN-0007kU-2Q for nfsv4@ietf.org; Mon, 16 Jul 2007 14:20:29 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6GIJ0F3023273 for ; Mon, 16 Jul 2007 18:19:00 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLA00401AU8CN00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 16 Jul 2007 12:19:00 -0600 (MDT) Received: from [192.168.0.3] (brmea-proxy-3.Sun.COM [192.18.98.64]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLA000WWAVMVC20@mail-amer.sun.com> for nfsv4@ietf.org; Mon, 16 Jul 2007 12:19:00 -0600 (MDT) Date: Mon, 16 Jul 2007 13:19:16 -0500 From: Spencer Shepler Subject: Re: [nfsv4] layout stateids and pNFS callbacks In-reply-to: <89c397150707161041j2fa87f28jd43e34e97c7cc12a@mail.gmail.com> To: nfsv4@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <89c397150707161041j2fa87f28jd43e34e97c7cc12a@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 16, 2007, at 12:41 PM, William A. (Andy) Adamson wrote: > > > On 7/16/07, Noveck, Dave wrote: > (1) Make > it possible for pNFS to work in v4.0 w/o sessions. I'm > > hearing that sessions have turned out to be a significant > > implementation concern. > > V4.0.5? Is there going to be a spec for this and if so, who is > going to > write it? And if not, how are you going to get inter-operable > implementations? If you have implementation concerns about sessions, > then you will really have them about a protocol without a spec. > > If the result is a better v4.1, I'm perfectly OK with this change, > but I > think trying to optimize V4.1 for V4.0.5 is a real mistake. > > > If I remember correctly, the main reason that pNFS requires > Sessions is to handle the races between LAYOUTGET/RETURN etc. > Perhaps what David is suggesting it that NFSv4.1 pNFS with his > proposed stateid changes would not require sessions, and therefore > be an independent 4.1 feature. I am having a difficult time understanding what "an independent 4.1 feature" would be. NFSv4.1 requires Sessions. That has been decided long ago and the main reason for its mandatory nature for 4.1 was the variety of issues we would have in defining features in two flavors "with sessions" and "without sessions". We deemed it as too much work and complexity for the flexibility in implementation. As with any of the features defined in the NFSv4.1 Internet Draft, if there is concern or experience about the unneeded or untenable complexity of implementation, they need to be discussed here. The issues may be real and may or should require a change in the specification. It may be that there is a misunderstanding of what has been included in the Internet Draft and we just need to clarify the language. Please bring the issues forward and participate in the discussion. I really don't want any surprises as we move forward. Spencer > > -->Andy > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Saturday, July 14, 2007 2:52 PM > To: bhalevy@panasas.com; trond.myklebust@fys.uio.no > Cc: nfsv4@ietf.org; Black_David@emc.com > Subject: RE: [nfsv4] layout stateids and pNFS callbacks > > Sorry for the delay in getting back to this, but between Trond and > Benny, what's been discussed is a specific example of what I had in > mind > - thanks. > > Also, Trond asked: > > > >> Why do you want an alternative to sessions? > > (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm > hearing that sessions have turned out to be a significant > implementation concern. > (2) Make the pNFS protocol simpler. Right now, the sessions > solution to a race condition involves identifying the > outstanding operation(s), which is somewhat more involved > than having the client and server track a per-layout sequence > number. > (?3?) The result may be more robust. With sessions, if the server > misses an outstanding operation in the sessions state (lots > of concurrency there, so lots of opportunities to get things > subtly wrong), things go awry. With a sequence number, the > check is based on state instead of existence of outstanding > operations, and there's much less potential concurrency > involved. The "?"s are because I'm not sure how strongly > I want to lean on this argument, and it's primarily a > consequence of (2) anyhow. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > Trond Myklebust wrote: > > > On Mon, 2007-07-09 at 14:31 -0400, Noveck, Dave wrote: > > >> I'm getting confused here. Originally, there was a proposal > to add > > >> stateid's to to layouts. Now it seems that something entirely > > >> different is being proposed. > > >> > > >> It sounds like David Is proposing a single global (for every pair > > >> of client and meta-data server) sequence id. Is that in fact the > > >> case? It doesn't sound like the fact that stateid's have > sequence > > >> values meets his requirement to have a "a single sequence count > > >> *that is included in all the relevant operations, including > > >> callbacks*" > > >> at least as part as the "single" part. With stateid's you still > > >> have the same issue with delegation recall that Trond points out. > > > > > > I believe that David is proposing that the client supply a > sequence > id > > > (presumably modelled on the scheme used by LOCK in the v4.0 > spec) in > the > > > GETLAYOUT call, and that the server then uses that sequence id as > part > > > of the stateid. That way the client always knows whether or not > the > > > stateid refers to an outstanding call or a completed call. > David is > that > > > correct? > > > > I won't speak for David, but what I had in mind is a layout stateid > per > > that's incremented every time the layout > changes, > i.e. > > on each LAYOUTGET and each LAYOUTRETURN. On CB_LAYOUTRECALL, the > server > > sends the last stateid it knows about for this file and the client > must > > wait on every outstanding LAYOUTGET and LAYOUTRETURN operation until > > it gets this stateid back before starting to return layouts for this > > recall. Any further LAYOUTGETs should be rejected by the server if > they > > conflict with the recall, otherwise they can be served. The > recall is > done > > either by returning a NOMATCHINGLAYOUT error to CB_LAYOUTRECALL > or by > > a respective LAYOUTRETURN. > > > > Again, I propose to make this explicit by e.g. quoting the layout > stateid > > the CB_LAYOUTRECALL was sent for otherwise it will be harder to > handle > an > > inflight LAYOUTRETURN that hasn't been seen by the server before it > sent > > out the CB_LAYOUTRECALL and that will effectively complete the > recall. > > > > Note that the per-file layout stateid does not solve the problem for > > recalling and returning layouts for FSID and ALL. A per-client > layout > > > stateid may help here but it can limit parallelism. > > > > Benny > > > > > > > > Trond > > > > > >> -----Original Message----- > > >> From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no ] > > >> Sent: Monday, July 09, 2007 1:22 PM > > >> To: Black_David@emc.com > > >> Cc: nfsv4@ietf.org > > >> Subject: RE: [nfsv4] layout stateids and pNFS callbacks > > >> > > >> > > >> On Mon, 2007-07-09 at 13:05 -0400, Black_David@emc.com wrote: > > >>> That depends on the details of how they're used. We have > > experience > > >>> (i.e., running code) with FMP for MPFS that a single > > sequence count > > >>> *that is included in all the relevant operations, > > including callbacks* > > >>> is sufficient to sort this out if one pays close > > attention to all the > > >>> details. > > >>> > > >>> The class of race you describe is handled at the client > > by observing > > >>> that the callback carries seqid "n", but the client > > hasn't processed > > >>> the reply to operation "n", and hence the client holds > > the callback > > >>> until operation "n" (the OPEN) is processed. OTOH, if > > the callback > > >>> doesn't carry a seqid, the game's over ... and the fix is > > not to make > > >>> that design mistake ;-). > > >> OK. I see where you're coming from now. Basically you are > > extending the > > >> v4.0 sequencing scheme to work with callbacks? I suppose > > that can work, > > >> but it does seem a tad inelegant. > > >> > > >> Why do you want an alternative to sessions? > > >> > > >> Trond > > >> > > >> > > >> _______________________________________________ > > >> nfsv4 mailing list > > >> nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 > > > > > > > > > _______________________________________________ > > > nfsv4 mailing list > > > nfsv4@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nfsv4 > > > > > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 16 14:23:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVEc-0007Wq-Iu; Mon, 16 Jul 2007 14:23:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVEb-0007Wb-EO for nfsv4@ietf.org; Mon, 16 Jul 2007 14:23:49 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAVEa-0007rr-Tf for nfsv4@ietf.org; Mon, 16 Jul 2007 14:23:49 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6GINWP0023726 for ; Mon, 16 Jul 2007 18:23:32 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLA00J01AU5PC00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 16 Jul 2007 12:23:32 -0600 (MDT) Received: from [192.168.0.3] (brmea-proxy-3.Sun.COM [192.18.98.64]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLA003PHB36QF10@mail-amer.sun.com>; Mon, 16 Jul 2007 12:23:31 -0600 (MDT) Date: Mon, 16 Jul 2007 13:23:47 -0500 From: Spencer Shepler Subject: Re: [nfsv4] layout stateids and pNFS callbacks In-reply-to: To: Black_David@emc.com Message-id: <0079CDBC-081D-4535-887B-829116C13292@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <1184007222.6468.50.camel@heimdal.trondhjem.org> <46933B43.50702@panasas.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: bhalevy@panasas.com, nfsv4@ietf.org, trond.myklebust@fys.uio.no X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 14, 2007, at 1:52 PM, Black_David@emc.com wrote: > Sorry for the delay in getting back to this, but between Trond > and Benny, what's been discussed is a specific example of what > I had in mind - thanks. > > Also, Trond asked: > >>>> Why do you want an alternative to sessions? > > (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm > hearing that sessions have turned out to be a significant > implementation concern. You need to clarify this David. Was this a typo and you meant "in v4.1 w/o sessions" or did you mean using NFSv4.0 as a new files based layout type? > (2) Make the pNFS protocol simpler. Right now, the sessions > solution to a race condition involves identifying the > outstanding operation(s), which is somewhat more involved > than having the client and server track a per-layout sequence > number. We will continue the stateid proposal for layouts and see if it can be adapted to provide what is mentioned. However, Sessions is still going to be a mandatory to implement feature unless there is a good reason not to and then the proposals should be in the form of what issues there are with Sessions and if/how they can be addressed. Before we go off to far in the deep end, it may be best to give David an opportunity to respond. Spencer > (?3?) The result may be more robust. With sessions, if the server > misses an outstanding operation in the sessions state (lots > of concurrency there, so lots of opportunities to get things > subtly wrong), things go awry. With a sequence number, the > check is based on state instead of existence of outstanding > operations, and there's much less potential concurrency > involved. The "?"s are because I'm not sure how strongly > I want to lean on this argument, and it's primarily a > consequence of (2) anyhow. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > >> Trond Myklebust wrote: >>> On Mon, 2007-07-09 at 14:31 -0400, Noveck, Dave wrote: >>>> I'm getting confused here. Originally, there was a >>>> proposal to add stateid's to to layouts. Now it seems >>>> that something entirely different is being proposed. >>>> >>>> It sounds like David Is proposing a single global >>>> (for every pair of client and meta-data server) sequence >>>> id. Is that in fact the case? It doesn't sound like >>>> the fact that stateid's have sequence values meets his >>>> requirement to have a "a single sequence count *that is >>>> included in all the relevant operations, including callbacks*" >>>> at least as part as the "single" part. With stateid's >>>> you still have the same issue with delegation recall >>>> that Trond points out. >>> >>> I believe that David is proposing that the client supply a sequence > id >>> (presumably modelled on the scheme used by LOCK in the v4.0 spec) in > the >>> GETLAYOUT call, and that the server then uses that sequence id as > part >>> of the stateid. That way the client always knows whether or not the >>> stateid refers to an outstanding call or a completed call. David is > that >>> correct? >> >> I won't speak for David, but what I had in mind is a layout stateid > per >> that's incremented every time the layout changes, > i.e. >> on each LAYOUTGET and each LAYOUTRETURN. On CB_LAYOUTRECALL, the > server >> sends the last stateid it knows about for this file and the client > must >> wait on every outstanding LAYOUTGET and LAYOUTRETURN operation until >> it gets this stateid back before starting to return layouts for this >> recall. Any further LAYOUTGETs should be rejected by the server if > they >> conflict with the recall, otherwise they can be served. The >> recall is > done >> either by returning a NOMATCHINGLAYOUT error to CB_LAYOUTRECALL or by >> a respective LAYOUTRETURN. >> >> Again, I propose to make this explicit by e.g. quoting the layout > stateid >> the CB_LAYOUTRECALL was sent for otherwise it will be harder to >> handle > an >> inflight LAYOUTRETURN that hasn't been seen by the server before it > sent >> out the CB_LAYOUTRECALL and that will effectively complete the >> recall. >> >> Note that the per-file layout stateid does not solve the problem for >> recalling and returning layouts for FSID and ALL. A per-client >> layout >> stateid may help here but it can limit parallelism. >> >> Benny >> >>> >>> Trond >>> >>>> -----Original Message----- >>>> From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] >>>> Sent: Monday, July 09, 2007 1:22 PM >>>> To: Black_David@emc.com >>>> Cc: nfsv4@ietf.org >>>> Subject: RE: [nfsv4] layout stateids and pNFS callbacks >>>> >>>> >>>> On Mon, 2007-07-09 at 13:05 -0400, Black_David@emc.com wrote: >>>>> That depends on the details of how they're used. We have >> experience >>>>> (i.e., running code) with FMP for MPFS that a single >> sequence count >>>>> *that is included in all the relevant operations, >> including callbacks* >>>>> is sufficient to sort this out if one pays close >> attention to all the >>>>> details. >>>>> >>>>> The class of race you describe is handled at the client >> by observing >>>>> that the callback carries seqid "n", but the client >> hasn't processed >>>>> the reply to operation "n", and hence the client holds >> the callback >>>>> until operation "n" (the OPEN) is processed. OTOH, if >> the callback >>>>> doesn't carry a seqid, the game's over ... and the fix is >> not to make >>>>> that design mistake ;-). >>>> OK. I see where you're coming from now. Basically you are >> extending the >>>> v4.0 sequencing scheme to work with callbacks? I suppose >> that can work, >>>> but it does seem a tad inelegant. >>>> >>>> Why do you want an alternative to sessions? >>>> >>>> Trond >>>> >>>> >>>> _______________________________________________ >>>> nfsv4 mailing list >>>> nfsv4@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/nfsv4 >>> >>> >>> _______________________________________________ >>> nfsv4 mailing list >>> nfsv4@ietf.org >>> https://www1.ietf.org/mailman/listinfo/nfsv4 >> >> >> > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 16 14:53:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVgv-0001XH-JB; Mon, 16 Jul 2007 14:53:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVgu-0001X7-NT for nfsv4@ietf.org; Mon, 16 Jul 2007 14:53:04 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAVgs-0000Bk-Fn for nfsv4@ietf.org; Mon, 16 Jul 2007 14:53:04 -0400 X-IronPort-AV: E=Sophos;i="4.16,542,1175497200"; d="scan'208,217";a="82649124" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 16 Jul 2007 11:52:53 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6GIqr6b011726; Mon, 16 Jul 2007 11:52:53 -0700 (PDT) Received: from SACEXMV01.hq.netapp.com ([10.99.190.107]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 11:52:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [nfsv4] layout stateids and pNFS callbacks Date: Mon, 16 Jul 2007 11:52:51 -0700 Message-ID: <01AE8AF878612047A442668306EAEB05C17CDE@SACEXMV01.hq.netapp.com> In-Reply-To: <89c397150707161041j2fa87f28jd43e34e97c7cc12a@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] layout stateids and pNFS callbacks Thread-Index: AcfH0NHi3fmOojr4RBOilHReN5T/1wACI4/g References: <89c397150707161041j2fa87f28jd43e34e97c7cc12a@mail.gmail.com> From: "Muntz, Daniel" To: "William A. \(Andy\) Adamson" , "Noveck, Dave" X-OriginalArrivalTime: 16 Jul 2007 18:52:53.0037 (UTC) FILETIME=[83BD55D0:01C7C7DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8bebc843ecf489bb7d907f63ccb001af Cc: bhalevy@panasas.com, trond.myklebust@fys.uio.no, Black_David@emc.com, nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1894481521==" Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. --===============1894481521== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C7DA.836152EC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C7DA.836152EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perhaps what Andy is suggesting is that pNFS could be a feature, independent of 4.1. I think there might even have been research/prototyping done in this area, including distributed metadata service. =20 -Dan ________________________________ From: William A. (Andy) Adamson [mailto:andros@citi.umich.edu]=20 Sent: Monday, July 16, 2007 10:41 AM To: Noveck, Dave Cc: bhalevy@panasas.com; Black_David@emc.com; nfsv4@ietf.org; trond.myklebust@fys.uio.no Subject: Re: [nfsv4] layout stateids and pNFS callbacks On 7/16/07, Noveck, Dave wrote:=20 > (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm > hearing that sessions have turned out to be a significant > implementation concern. =09 V4.0.5? Is there going to be a spec for this and if so, who is going to=20 write it? And if not, how are you going to get inter-operable implementations? If you have implementation concerns about sessions, then you will really have them about a protocol without a spec. =09 If the result is a better v4.1, I'm perfectly OK with this change, but I think trying to optimize V4.1 for V4.0.5 is a real mistake. If I remember correctly, the main reason that pNFS requires Sessions is to handle the races between LAYOUTGET/RETURN etc. Perhaps what David is suggesting it that NFSv4.1 pNFS with his proposed stateid changes would not require sessions, and therefore be an independent 4.1 feature. -->Andy -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com] Sent: Saturday, July 14, 2007 2:52 PM To: bhalevy@panasas.com; trond.myklebust@fys.uio.no Cc: nfsv4@ietf.org; Black_David@emc.com Subject: RE: [nfsv4] layout stateids and pNFS callbacks =09 Sorry for the delay in getting back to this, but between Trond and Benny, what's been discussed is a specific example of what I had in mind - thanks.=20 =09 Also, Trond asked: =09 > >> Why do you want an alternative to sessions? =09 (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm hearing that sessions have turned out to be a significant=20 implementation concern. (2) Make the pNFS protocol simpler. Right now, the sessions solution to a race condition involves identifying the outstanding operation(s), which is somewhat more involved=20 than having the client and server track a per-layout sequence number. (?3?) The result may be more robust. With sessions, if the server misses an outstanding operation in the sessions state (lots=20 of concurrency there, so lots of opportunities to get things subtly wrong), things go awry. With a sequence number, the check is based on state instead of existence of outstanding operations, and there's much less potential concurrency=20 involved. The "?"s are because I'm not sure how strongly I want to lean on this argument, and it's primarily a consequence of (2) anyhow. =09 Thanks, --David ----------------------------------------------------=20 David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754=20 ---------------------------------------------------- =09 > Trond Myklebust wrote: > > On Mon, 2007-07-09 at 14:31 -0400, Noveck, Dave wrote: > >> I'm getting confused here. Originally, there was a proposal to add=20 > >> stateid's to to layouts. Now it seems that something entirely > >> different is being proposed. > >> > >> It sounds like David Is proposing a single global (for every pair=20 > >> of client and meta-data server) sequence id. Is that in fact the > >> case? It doesn't sound like the fact that stateid's have sequence > >> values meets his requirement to have a "a single sequence count=20 > >> *that is included in all the relevant operations, including > >> callbacks*" > >> at least as part as the "single" part. With stateid's you still > >> have the same issue with delegation recall that Trond points out.=20 > > > > I believe that David is proposing that the client supply a sequence id > > (presumably modelled on the scheme used by LOCK in the v4.0 spec) in the > > GETLAYOUT call, and that the server then uses that sequence id as=20 part > > of the stateid. That way the client always knows whether or not the > > stateid refers to an outstanding call or a completed call. David is that > > correct? > > I won't speak for David, but what I had in mind is a layout stateid=20 per > that's incremented every time the layout changes, i.e. > on each LAYOUTGET and each LAYOUTRETURN. On CB_LAYOUTRECALL, the server > sends the last stateid it knows about for this file and the client=20 must > wait on every outstanding LAYOUTGET and LAYOUTRETURN operation until > it gets this stateid back before starting to return layouts for this > recall. Any further LAYOUTGETs should be rejected by the server if=20 they > conflict with the recall, otherwise they can be served. The recall is done > either by returning a NOMATCHINGLAYOUT error to CB_LAYOUTRECALL or by > a respective LAYOUTRETURN. > > Again, I propose to make this explicit by e.g. quoting the layout stateid > the CB_LAYOUTRECALL was sent for otherwise it will be harder to handle an > inflight LAYOUTRETURN that hasn't been seen by the server before it sent > out the CB_LAYOUTRECALL and that will effectively complete the recall.=20 > > Note that the per-file layout stateid does not solve the problem for > recalling and returning layouts for FSID and ALL. A per-client layout =09 > stateid may help here but it can limit parallelism.=20 > > Benny > > > > > Trond > > > >> -----Original Message----- > >> From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no ] > >> Sent: Monday, July 09, 2007 1:22 PM > >> To: Black_David@emc.com > >> Cc: nfsv4@ietf.org > >> Subject: RE: [nfsv4] layout stateids and pNFS callbacks=20 > >> > >> > >> On Mon, 2007-07-09 at 13:05 -0400, Black_David@emc.com wrote: > >>> That depends on the details of how they're used. We have=20 > experience > >>> (i.e., running code) with FMP for MPFS that a single > sequence count > >>> *that is included in all the relevant operations, > including callbacks* > >>> is sufficient to sort this out if one pays close=20 > attention to all the > >>> details. > >>> > >>> The class of race you describe is handled at the client > by observing > >>> that the callback carries seqid "n", but the client=20 > hasn't processed > >>> the reply to operation "n", and hence the client holds > the callback > >>> until operation "n" (the OPEN) is processed. OTOH, if=20 > the callback > >>> doesn't carry a seqid, the game's over ... and the fix is > not to make > >>> that design mistake ;-). > >> OK. I see where you're coming from now. Basically you are=20 > extending the > >> v4.0 sequencing scheme to work with callbacks? I suppose > that can work, > >> but it does seem a tad inelegant. > >> > >> Why do you want an alternative to sessions?=20 > >> > >> Trond > >> > >> > >> _______________________________________________ > >> nfsv4 mailing list > >> nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 > > > > > > _______________________________________________ > > nfsv4 mailing list=20 > > nfsv4@ietf.org > > https://www1.ietf.org/mailman/listinfo/nfsv4 > > > =09 _______________________________________________=20 nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 =09 _______________________________________________=20 nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 =09 =09 ------_=_NextPart_001_01C7C7DA.836152EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Perhaps what Andy is suggesting is that = pNFS could be=20 a feature, independent of 4.1.  I think there might even have been=20 research/prototyping done in this area, including distributed metadata=20 service.
 
  -Dan

From: William A. (Andy) Adamson=20 [mailto:andros@citi.umich.edu]
Sent: Monday, July 16, 2007 = 10:41=20 AM
To: Noveck, Dave
Cc: bhalevy@panasas.com;=20 Black_David@emc.com; nfsv4@ietf.org;=20 trond.myklebust@fys.uio.no
Subject: Re: [nfsv4] layout = stateids and=20 pNFS callbacks



On 7/16/07, Noveck,=20 Dave <Dave.Noveck@netapp.com>=20 wrote:
>=20 (1) Make it possible for pNFS to work in v4.0 w/o=20 sessions.  I'm
>       = hearing=20 that sessions have turned out to be a=20 significant
>       implementation = concern.

V4.0.5?  Is there going to be a spec for = this and if=20 so, who is going to
write it?  And if not, how are you = going to=20 get inter-operable
implementations?  If you have = implementation=20 concerns about sessions,
then you will really have them about a = protocol=20 without a spec.

If the result is a better v4.1, I'm perfectly = OK with=20 this change, but I
think trying to optimize V4.1 for V4.0.5 is a = real=20 mistake.


If I remember correctly, the main reason that pNFS requires = Sessions is to handle the races between LAYOUTGET/RETURN etc. Perhaps = what David=20 is suggesting it that NFSv4.1 pNFS with his proposed stateid changes = would not=20 require sessions, and therefore be an independent 4.1=20 feature.

-->Andy

-----Original=20 Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: = Saturday,=20 July 14, 2007 2:52 PM
To: bhalevy@panasas.com; trond.myklebust@fys.uio.no=
Cc:=20 nfsv4@ietf.org; Black_David@emc.com
Subject: = RE:=20 [nfsv4] layout stateids and pNFS callbacks

Sorry for the delay = in=20 getting back to this, but between Trond and
Benny, what's been = discussed is=20 a specific example of what I had in mind
- thanks.

Also, = Trond=20 asked:

> >> Why do you want an alternative to=20 sessions?

(1) Make it possible for pNFS to work in v4.0 w/o=20 = sessions.  I'm
       &nb= sp;hearing=20 that sessions have turned out to be a significant=20
        implementation=20 concern.
(2) Make the pNFS protocol simpler.  Right now, = the=20 sessions
        solution = to a race=20 condition involves identifying=20 the
        outstanding=20 operation(s), which is somewhat more involved=20
        than having the = client and=20 server track a per-layout=20 = sequence
        number.
(?= 3?)=20 The result may be more robust.  With sessions, if the=20 server
        misses an=20 outstanding operation in the sessions state (lots=20
        of concurrency = there, so=20 lots of opportunities to get=20 things
        subtly = wrong),=20 things go awry.  With a sequence number,=20 the
        check is based = on state=20 instead of existence of=20 = outstanding
        operations= , and=20 there's much less potential concurrency=20 =
        involved.  = The=20 "?"s are because I'm not sure how=20 strongly
        I want to = lean on=20 this argument, and it's primarily=20 a
        consequence of = (2)=20 = anyhow.

Thanks,
--David
------------------------------------= ----------------=20
David L. Black, Senior Technologist
EMC Corporation, 176 South = St.,=20 Hopkinton, MA  01748
+1 (508)=20 = 293-7953           = ; =20 FAX: +1 (508) 293-7786
black_david@emc.com  &n= bsp;     Mobile:=20 +1 (978) 394-7754=20
----------------------------------------------------

> = Trond=20 Myklebust wrote:
> > On Mon, 2007-07-09 at 14:31 -0400, = Noveck, Dave=20 wrote:
> >> I'm getting confused = here.  Originally,=20 there was a proposal to add
> >> stateid's to to=20 layouts.  Now it seems that something entirely
> = >>=20 different is being proposed.
> >>
> >> It = sounds like=20 David Is proposing a single global (for every pair
> >> = of client=20 and meta-data server) sequence id.  Is that in fact = the
>=20 >> case?  It doesn't sound like the fact that = stateid's have=20 sequence
> >> values meets his requirement to have a "a = single=20 sequence count
> >> *that is included in all the relevant = operations, including
> >> callbacks*"
> >> at = least=20 as part as the "single" part.  With stateid's you = still
>=20 >> have the same issue with delegation recall that Trond points = out.=20
> >
> > I believe that David is proposing that the = client=20 supply a sequence
id
> > (presumably modelled on the = scheme used=20 by LOCK in the v4.0 spec) in
the
> > GETLAYOUT call, and = that the=20 server then uses that sequence id as
part
> > of the = stateid.=20 That way the client always knows whether or not the
> > = stateid=20 refers to an outstanding call or a completed call. David = is
that
>=20 > correct?
>
> I won't speak for David, but what I had = in mind=20 is a layout stateid
per
> <mds, client, file> that's=20 incremented every time the layout changes,
i.e.
> on each = LAYOUTGET=20 and each LAYOUTRETURN.  On CB_LAYOUTRECALL, = the
server
>=20 sends the last stateid it knows about for this file and the client=20
must
> wait on every outstanding LAYOUTGET and LAYOUTRETURN=20 operation until
> it gets this stateid back before starting to = return=20 layouts for this
> recall.  Any further LAYOUTGETs = should be=20 rejected by the server if
they
> conflict with the recall, = otherwise=20 they can be served.  The recall is
done
> either by = returning a NOMATCHINGLAYOUT error to CB_LAYOUTRECALL or by
> a=20 respective LAYOUTRETURN.
>
> Again, I propose to make this = explicit by e.g. quoting the layout
stateid
> the = CB_LAYOUTRECALL was=20 sent for otherwise it will be harder to handle
an
> inflight=20 LAYOUTRETURN that hasn't been seen by the server before = it
sent
> out=20 the CB_LAYOUTRECALL and that will effectively complete the recall.=20
>
> Note that the per-file layout stateid does not solve = the=20 problem for
> recalling and returning layouts for FSID and=20 ALL.  A per-client layout

> stateid may help here = but it=20 can limit parallelism.
>
> Benny
>
> = >
>=20 > Trond
> >
> >> -----Original = Message-----
>=20 >> From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no=20 ]
> >> Sent: Monday, July 09, 2007 1:22 PM
> = >>=20 To: Black_David@emc.com
>=20 >> Cc: nfsv4@ietf.org
>=20 >> Subject: RE: [nfsv4] layout stateids and pNFS callbacks =
>=20 >>
> >>
> >> On Mon, 2007-07-09 at 13:05 = -0400,=20 Black_David@emc.com = wrote:
>=20 >>> That depends on the details of how they're = used.  We=20 have
> experience
> >>> (i.e., running code) = with FMP=20 for MPFS that a single
> sequence count
> >>> = *that is=20 included in all the relevant operations,
> including = callbacks*
>=20 >>> is sufficient to sort this out if one pays close
> = attention to all the
> >>> details.
>=20 >>>
> >>> The class of race you describe is = handled at=20 the client
> by observing
> >>> that the callback = carries=20 seqid "n", but the client
> hasn't processed
> = >>> the=20 reply to operation "n", and hence the client holds
> the=20 callback
> >>> until operation "n" (the OPEN) is=20 processed.  OTOH, if
> the callback
> = >>>=20 doesn't carry a seqid, the game's over ... and the fix is
> not = to=20 make
> >>> that design mistake ;-).
> >> = OK. I see=20 where you're coming from now. Basically you are
> extending = the
>=20 >> v4.0 sequencing scheme to work with callbacks? I = suppose
> that=20 can work,
> >> but it does seem a tad inelegant.
>=20 >>
> >> Why do you want an alternative to sessions? =
>=20 >>
> >> Trond
> >>
> = >>
>=20 >> _______________________________________________
> = >>=20 nfsv4 mailing list
> >> nfsv4@ietf.org https://www1.ietf.o= rg/mailman/listinfo/nfsv4
>=20 >
> >
> >=20 _______________________________________________
> > nfsv4 = mailing=20 list
> > nfsv4@ietf.org
>=20 > https://www1.ietf.o= rg/mailman/listinfo/nfsv4
>
>
>

____________= ___________________________________=20
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/nfsv4

____________________________________= ___________=20
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/nfsv4


------_=_NextPart_001_01C7C7DA.836152EC-- --===============1894481521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============1894481521==-- From nfsv4-bounces@ietf.org Mon Jul 16 14:59:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVnV-00073E-52; Mon, 16 Jul 2007 14:59:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVnU-000734-Ae for nfsv4@ietf.org; Mon, 16 Jul 2007 14:59:52 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAVnT-0000Q6-QN for nfsv4@ietf.org; Mon, 16 Jul 2007 14:59:52 -0400 Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6GIxABd006944; Mon, 16 Jul 2007 14:59:10 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6GIwPvn003591; Mon, 16 Jul 2007 14:59:08 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 14:59:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Jul 2007 14:59:01 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: pNFS and sessions Thread-Index: AcfH1iLq+n8yt7gkR0+uq9AW1m6d3AAACDnw References: <89c397150707161041j2fa87f28jd43e34e97c7cc12a@mail.gmail.com> To: , X-OriginalArrivalTime: 16 Jul 2007 18:59:02.0534 (UTC) FILETIME=[5FFA1A60:01C7C7DB] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: Subject: [nfsv4] pNFS and sessions X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Spencer (and Dave), > > (1) Make it possible for pNFS to work in v4.0 w/o sessions. I'm > > > hearing that sessions have turned out to be a significant > > > implementation concern. > > > > V4.0.5? Is there going to be a spec for this and if so, who is =20 > > going to write it? And if not, how are you going to get inter-operable > > implementations? If you have implementation concerns about sessions, > > then you will really have them about a protocol without a spec. > > > > If the result is a better v4.1, I'm perfectly OK with this change, =20 > > but I think trying to optimize V4.1 for V4.0.5 is a real mistake. The result is definitely a better v4.1 courtesy of (2), which says that a sequence number is a simpler, better and (arguably) more robust way to solve the problems: (2) Make the pNFS protocol simpler. Right now, the sessions solution to a race condition involves identifying the outstanding operation(s), which is somewhat more involved than having the client and server track a per-layout sequence number. The fact that this approach also functionally separates pNFS from sessions, thereby making it possible to specify pNFS for v4.0 without sessions (IMHO, sessions are and should be v4.1 only) is a bonus - that's mostly a side effect of introducing orthogonality between pNFS and sessions (a good idea in general, IMHO). FWIW, I agree with Dave Noveck's comment that in order to use pNFS interoperably with v4.0, a specification for doing so is required - that would be something to be done in the future if there's sufficient interest. > > If I remember correctly, the main reason that pNFS requires =20 > > Sessions is to handle the races between LAYOUTGET/RETURN etc. =20 > > Perhaps what David is suggesting it that NFSv4.1 pNFS with his =20 > > proposed stateid changes would not require sessions, and therefore =20 > > be an independent 4.1 feature. >=20 > I am having a difficult time understanding what "an independent 4.1 =20 > feature" would be. Distinct features are independent when there is an absence of functional cross-coupling that requires one feature to understand the internal state of another - as currently specified, pNFS requires understanding the internal state of sessions. Absence of functional cross-coupling helps with implementation modularity, even when all the features involved are mandatory to implement. To the extent that everyone already knows this, I apologize for the architectural pedantry. > NFSv4.1 requires Sessions. That has been decided long ago and > the main reason for its mandatory nature for 4.1 was the variety > of issues we would have in defining features in two flavors "with =20 > sessions" and "without sessions". We deemed it as too much work > and complexity for the flexibility in implementation. That's ok - I have no problem with this approach. > As with any of the features defined in the NFSv4.1 Internet Draft, > if there is concern or experience about the unneeded or untenable > complexity of implementation, they need to be discussed here. > The issues may be real and may or should require a change in the > specification. It may be that there is a misunderstanding of what > has been included in the Internet Draft and we just need to clarify > the language. >=20 > Please bring the issues forward and participate in the discussion. > I really don't want any surprises as we move forward. IMHO, sessions are needed in v4.1 for reasons other than pNFS - or to turn it around, if the only use of sessions were pNFS, (IMHO) sessions would not be in v4.1. I don't have any general issue with sessions as a required v4.1 feature - the concern here starts from our original decision to take advantage of sessions to remove some pNFS race conditions because sessions were already in the spec. Recent discussion suggests that using a sequence number is a better way (IMHO) to deal with pNFS race conditions, and hence the concern is not about whether sessions should be a required v4.1 feature, but rather about whether pNFS should be obligated to use sessions when there is a better solution possible. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 16 17:15:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAXum-0006ul-VF; Mon, 16 Jul 2007 17:15:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAXul-0006mE-GS for nfsv4@ietf.org; Mon, 16 Jul 2007 17:15:31 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAXuW-0003ji-6T for nfsv4@ietf.org; Mon, 16 Jul 2007 17:15:31 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6GLDbrv011471 for ; Mon, 16 Jul 2007 21:13:37 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLA00M01IMGP300@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 16 Jul 2007 15:13:37 -0600 (MDT) Received: from [70.3.183.174] (032-482-660.area7.spcsdns.net [70.3.183.174]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLA00CCTIYL1N20@mail-amer.sun.com> for nfsv4@ietf.org; Mon, 16 Jul 2007 15:13:37 -0600 (MDT) Date: Mon, 16 Jul 2007 16:13:49 -0500 From: Spencer Shepler Subject: Re: [nfsv4] pNFS: Open issues (from chapter 12 & 13 reviews) In-reply-to: <4679B30E.9000705@netapp.com> To: nfsv4@ietf.org Message-id: <6356FDF4-6E80-44AE-885F-FCC357876A87@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <4679B30E.9000705@netapp.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jun 20, 2007, at 6:06 PM, Garth Goodson wrote: > Pulled from meeting minutes thanks to Lisa and Sam. > > Chapter 12: Common pNFS > ----------------------- > > * Open Issue 1: Layout hint attribute on OPEN (or a later SETATTR) > > (Line 12890 of draft 10) > - Dictates the use of a persistent reply cache if layout hints > are to > be used. General agreement that this is not good. > - SETATTR after an exclusive create may be a viable option (servers > may be fine with this) > > Noveck's proposed solution: Encourage, but not require a persistent > reply cache for layout_hint. A client can do a layout_hint on > EXCLUSIVE CREATE, but the server may or may not be able to handle > it effectively. I would like to clarify this a little to close on the issue. I agree that if a client is attempting to combine the semantics of OPEN with exclusive create and providing a layout_hint, that it should be encouraged to use Sessions persistent reply cache. This would be embodied as a OPEN with createmode4 == GUARDED4. This brings me to the clarification; the entire reason for this issue is that with createmode4 == EXCLUSIVE4, the client is unable to provide attributes for the create and then the second suggestion that the server may or may not be able to "handle it" doesn't make sense given that the OPEN call can not be encoded that way. So, am I to assume that "EXCLUSIVE CREATE" be replaced with SETATTR or layout_hint? This seems reasonable to me. Should there be any additional guidance given other than "may or may not be able to handle it"? Should the server silently ignore the attribute if not supported? Is there a timeframe when a server is most likely to be able to handle the hint? For example, before the first read/write to the file? Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 16 17:43:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAYMG-0000Cy-KQ; Mon, 16 Jul 2007 17:43:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAYME-0000Ce-SQ for nfsv4@ietf.org; Mon, 16 Jul 2007 17:43:54 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAYMA-0003YB-Fu for nfsv4@ietf.org; Mon, 16 Jul 2007 17:43:54 -0400 X-IronPort-AV: E=Sophos;i="4.16,543,1175497200"; d="scan'208";a="82709765" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 16 Jul 2007 14:43:48 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6GLhlWB024031; Mon, 16 Jul 2007 14:43:47 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 14:43:47 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 14:43:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] pNFS: Open issues (from chapter 12 & 13 reviews) Date: Mon, 16 Jul 2007 17:43:45 -0400 Message-ID: In-Reply-To: <6356FDF4-6E80-44AE-885F-FCC357876A87@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] pNFS: Open issues (from chapter 12 & 13 reviews) Thread-Index: AcfH7rb01sBQz32xRxOUM7xvsMdVKAAAy7lg From: "Noveck, Dave" To: "Spencer Shepler" , X-OriginalArrivalTime: 16 Jul 2007 21:43:46.0900 (UTC) FILETIME=[6384A940:01C7C7F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org > So, am I to assume that "EXCLUSIVE CREATE" be replaced=20 > with SETATTR or layout_hint? That's what I was assuming. > This seems reasonable to me. Should there be any additional=20 > guidance given other than "may or may not be able to handle it"? =20 > Should the server silently ignore the attribute if not supported? =20 It is a hint so either the server would ignore it or the server would return NOTSUPP and the client would ignore that. > Is there a timeframe when a server is most likely to be able to=20 > handle the hint? For example, before the first read/write to the=20 > file? I would go so far as to say the server SHOULD support setting this at least once before the first IO to the newly created file.=20 -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Monday, July 16, 2007 5:14 PM To: nfsv4@ietf.org Subject: Re: [nfsv4] pNFS: Open issues (from chapter 12 & 13 reviews) On Jun 20, 2007, at 6:06 PM, Garth Goodson wrote: > Pulled from meeting minutes thanks to Lisa and Sam. > > Chapter 12: Common pNFS > ----------------------- > > * Open Issue 1: Layout hint attribute on OPEN (or a later SETATTR) > > (Line 12890 of draft 10) > - Dictates the use of a persistent reply cache if layout hints are=20 > to > be used. General agreement that this is not good. > - SETATTR after an exclusive create may be a viable option (servers > may be fine with this) > > Noveck's proposed solution: Encourage, but not require a persistent=20 > reply cache for layout_hint. A client can do a layout_hint on=20 > EXCLUSIVE CREATE, but the server may or may not be able to handle it=20 > effectively. I would like to clarify this a little to close on the issue. I agree that if a client is attempting to combine the semantics of OPEN with exclusive create and providing a layout_hint, that it should be encouraged to use Sessions persistent reply cache. This would be embodied as a OPEN with createmode4 =3D=3D GUARDED4. This brings me to the clarification; the entire reason for this issue is that with createmode4 =3D=3D EXCLUSIVE4, the client is unable to provide attributes for the create and then the second suggestion that the server may or may not be able to "handle it" doesn't make sense given that the OPEN call can not be encoded that way. So, am I to assume that "EXCLUSIVE CREATE" be replaced with SETATTR or layout_hint? This seems reasonable to me. Should there be any additional guidance given other than "may or may not be able to handle it"? Should the server silently ignore the attribute if not supported? Is there a timeframe when a server is most likely to be able to handle the hint? For example, before the first read/write to the file? Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 16 19:07:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAZee-000276-JL; Mon, 16 Jul 2007 19:07:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAZed-00026w-1n for nfsv4@ietf.org; Mon, 16 Jul 2007 19:06:59 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAZeY-0005hM-HV for nfsv4@ietf.org; Mon, 16 Jul 2007 19:06:58 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6GN6scb023415 for ; Mon, 16 Jul 2007 23:06:54 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLA00101O0PPL00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 16 Jul 2007 17:06:54 -0600 (MDT) Received: from [129.153.128.212] (sca-ea-proxy-4.Sun.COM [192.18.43.29]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLA00G3GO7GIL00@mail-amer.sun.com>; Mon, 16 Jul 2007 17:06:54 -0600 (MDT) Date: Mon, 16 Jul 2007 18:07:10 -0500 From: Spencer Shepler Subject: Re: [nfsv4] pNFS: Open issues (from chapter 12 & 13 reviews) In-reply-to: To: "Noveck, Dave" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 16, 2007, at 4:43 PM, Noveck, Dave wrote: >> So, am I to assume that "EXCLUSIVE CREATE" be replaced >> with SETATTR or layout_hint? > > That's what I was assuming. > >> This seems reasonable to me. Should there be any additional >> guidance given other than "may or may not be able to handle it"? >> Should the server silently ignore the attribute if not supported? > > It is a hint so either the server would ignore it or the server > would return NOTSUPP and the client would ignore that. > >> Is there a timeframe when a server is most likely to be able to >> handle the hint? For example, before the first read/write to the >> file? > > I would go so far as to say the server SHOULD support setting this > at least once before the first IO to the newly created file. Agreed. Okay, I will work this into the next version of the I-D presupposing no further comment. Spencer > > -----Original Message----- > From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM] > Sent: Monday, July 16, 2007 5:14 PM > To: nfsv4@ietf.org > Subject: Re: [nfsv4] pNFS: Open issues (from chapter 12 & 13 reviews) > > > On Jun 20, 2007, at 6:06 PM, Garth Goodson wrote: > >> Pulled from meeting minutes thanks to Lisa and Sam. >> >> Chapter 12: Common pNFS >> ----------------------- >> >> * Open Issue 1: Layout hint attribute on OPEN (or a later SETATTR) >> >> (Line 12890 of draft 10) >> - Dictates the use of a persistent reply cache if layout hints are >> to >> be used. General agreement that this is not good. >> - SETATTR after an exclusive create may be a viable option (servers >> may be fine with this) >> >> Noveck's proposed solution: Encourage, but not require a persistent >> reply cache for layout_hint. A client can do a layout_hint on >> EXCLUSIVE CREATE, but the server may or may not be able to handle it >> effectively. > > I would like to clarify this a little to close on the issue. > > I agree that if a client is attempting to combine the semantics of > OPEN > with exclusive create and providing a layout_hint, that it should be > encouraged to use Sessions persistent reply cache. This would be > embodied as a OPEN with createmode4 == GUARDED4. > This brings me to the clarification; the entire reason for this > issue is > that with createmode4 == EXCLUSIVE4, the client is unable to provide > attributes for the create and then the second suggestion that the > server > may or may not be able to "handle it" doesn't make sense given that > the > OPEN call can not be encoded that way. > > So, am I to assume that "EXCLUSIVE CREATE" be replaced with SETATTR or > layout_hint? > This seems reasonable to me. Should there be any additional guidance > given other than "may or may not be able to handle it"? Should the > server silently ignore the attribute if not supported? Is there a > timeframe when a server is most likely to be able to handle the hint? > For example, before the first read/write to the file? > > Spencer > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 17 08:22:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAm3y-00040q-EV; Tue, 17 Jul 2007 08:21:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAm3P-0002Xm-Ep for nfsv4@ietf.org; Tue, 17 Jul 2007 08:21:23 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAm3F-000682-UH for nfsv4@ietf.org; Tue, 17 Jul 2007 08:21:23 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6HCKcGv018504; Tue, 17 Jul 2007 08:20:38 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 17 Jul 2007 08:20:38 -0400 Received: from [192.168.0.140] ([172.17.28.142]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 08:20:38 -0400 Message-ID: <469CB414.3020005@panasas.com> Date: Tue, 17 Jul 2007 15:20:36 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: [nfsv4] pNFS: Open issues (from chapter 12 & 13 reviews) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 12:20:38.0432 (UTC) FILETIME=[E26F5A00:01C7C86C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: "Noveck, Dave" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Spencer Shepler wrote: > On Jul 16, 2007, at 4:43 PM, Noveck, Dave wrote: > >>> So, am I to assume that "EXCLUSIVE CREATE" be replaced >>> with SETATTR or layout_hint? >> That's what I was assuming. Only if persistent sessions aren't supported by the server, otherwise the client MUST still use GUARDED, right? >> >>> This seems reasonable to me. Should there be any additional >>> guidance given other than "may or may not be able to handle it"? >>> Should the server silently ignore the attribute if not supported? >> It is a hint so either the server would ignore it or the server >> would return NOTSUPP and the client would ignore that. >> >>> Is there a timeframe when a server is most likely to be able to >>> handle the hint? For example, before the first read/write to the >>> file? >> I would go so far as to say the server SHOULD support setting this >> at least once before the first IO to the newly created file. > > Agreed. > > Okay, I will work this into the next version of the I-D > presupposing no further comment. > > Spencer > >> -----Original Message----- >> From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM] >> Sent: Monday, July 16, 2007 5:14 PM >> To: nfsv4@ietf.org >> Subject: Re: [nfsv4] pNFS: Open issues (from chapter 12 & 13 reviews) >> >> >> On Jun 20, 2007, at 6:06 PM, Garth Goodson wrote: >> >>> Pulled from meeting minutes thanks to Lisa and Sam. >>> >>> Chapter 12: Common pNFS >>> ----------------------- >>> >>> * Open Issue 1: Layout hint attribute on OPEN (or a later SETATTR) >>> >>> (Line 12890 of draft 10) >>> - Dictates the use of a persistent reply cache if layout hints are >>> to >>> be used. General agreement that this is not good. >>> - SETATTR after an exclusive create may be a viable option (servers >>> may be fine with this) >>> >>> Noveck's proposed solution: Encourage, but not require a persistent >>> reply cache for layout_hint. A client can do a layout_hint on >>> EXCLUSIVE CREATE, but the server may or may not be able to handle it >>> effectively. >> I would like to clarify this a little to close on the issue. >> >> I agree that if a client is attempting to combine the semantics of >> OPEN >> with exclusive create and providing a layout_hint, that it should be >> encouraged to use Sessions persistent reply cache. This would be >> embodied as a OPEN with createmode4 == GUARDED4. >> This brings me to the clarification; the entire reason for this >> issue is >> that with createmode4 == EXCLUSIVE4, the client is unable to provide >> attributes for the create and then the second suggestion that the >> server >> may or may not be able to "handle it" doesn't make sense given that >> the >> OPEN call can not be encoded that way. >> >> So, am I to assume that "EXCLUSIVE CREATE" be replaced with SETATTR or >> layout_hint? >> This seems reasonable to me. Should there be any additional guidance >> given other than "may or may not be able to handle it"? Should the >> server silently ignore the attribute if not supported? Is there a >> timeframe when a server is most likely to be able to handle the hint? >> For example, before the first read/write to the file? >> >> Spencer >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 17 09:09:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmo4-0005DF-Cx; Tue, 17 Jul 2007 09:09:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmo3-0005Cq-JR for nfsv4@ietf.org; Tue, 17 Jul 2007 09:09:35 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAmo1-0007cN-4M for nfsv4@ietf.org; Tue, 17 Jul 2007 09:09:35 -0400 X-IronPort-AV: E=Sophos;i="4.16,546,1175497200"; d="scan'208";a="82928232" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 17 Jul 2007 06:09:31 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6HD9UHL009855; Tue, 17 Jul 2007 06:09:30 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 06:09:31 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 06:09:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] pNFS: Open issues (from chapter 12 & 13 reviews) Date: Tue, 17 Jul 2007 09:09:29 -0400 Message-ID: In-Reply-To: <469CB414.3020005@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] pNFS: Open issues (from chapter 12 & 13 reviews) Thread-Index: AcfIbQRns70SGhFORNqnvcIrCFrSIAABf9lw From: "Noveck, Dave" To: "Benny Halevy" , "Spencer Shepler" X-OriginalArrivalTime: 17 Jul 2007 13:09:30.0882 (UTC) FILETIME=[B64FB620:01C7C873] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org > Only if persistent sessions aren't supported by the server, > otherwise the client MUST still use GUARDED, right? The server MUST return NOTSUPP if EXCLUSIVE is done on a persistent session. If the client wants to get NOTSUPP, he MAY use EXCLUSIVE as much as he wishes :-)=20 -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Tuesday, July 17, 2007 8:21 AM To: Spencer Shepler Cc: Noveck, Dave; nfsv4@ietf.org Subject: Re: [nfsv4] pNFS: Open issues (from chapter 12 & 13 reviews) Spencer Shepler wrote: > On Jul 16, 2007, at 4:43 PM, Noveck, Dave wrote: >=20 >>> So, am I to assume that "EXCLUSIVE CREATE" be replaced >>> with SETATTR or layout_hint? >> That's what I was assuming. Only if persistent sessions aren't supported by the server, otherwise the client MUST still use GUARDED, right? >> >>> This seems reasonable to me. Should there be any additional >>> guidance given other than "may or may not be able to handle it"? >>> Should the server silently ignore the attribute if not supported? >> It is a hint so either the server would ignore it or the server >> would return NOTSUPP and the client would ignore that. >> >>> Is there a timeframe when a server is most likely to be able to >>> handle the hint? For example, before the first read/write to the >>> file? >> I would go so far as to say the server SHOULD support setting this >> at least once before the first IO to the newly created file. >=20 > Agreed. >=20 > Okay, I will work this into the next version of the I-D > presupposing no further comment. >=20 > Spencer >=20 >> -----Original Message----- >> From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM] >> Sent: Monday, July 16, 2007 5:14 PM >> To: nfsv4@ietf.org >> Subject: Re: [nfsv4] pNFS: Open issues (from chapter 12 & 13 reviews) >> >> >> On Jun 20, 2007, at 6:06 PM, Garth Goodson wrote: >> >>> Pulled from meeting minutes thanks to Lisa and Sam. >>> >>> Chapter 12: Common pNFS >>> ----------------------- >>> >>> * Open Issue 1: Layout hint attribute on OPEN (or a later SETATTR) >>> >>> (Line 12890 of draft 10) >>> - Dictates the use of a persistent reply cache if layout hints are >>> to >>> be used. General agreement that this is not good. >>> - SETATTR after an exclusive create may be a viable option (servers >>> may be fine with this) >>> >>> Noveck's proposed solution: Encourage, but not require a persistent >>> reply cache for layout_hint. A client can do a layout_hint on >>> EXCLUSIVE CREATE, but the server may or may not be able to handle it >>> effectively. >> I would like to clarify this a little to close on the issue. >> >> I agree that if a client is attempting to combine the semantics of =20 >> OPEN >> with exclusive create and providing a layout_hint, that it should be >> encouraged to use Sessions persistent reply cache. This would be >> embodied as a OPEN with createmode4 =3D=3D GUARDED4. >> This brings me to the clarification; the entire reason for this =20 >> issue is >> that with createmode4 =3D=3D EXCLUSIVE4, the client is unable to = provide >> attributes for the create and then the second suggestion that the =20 >> server >> may or may not be able to "handle it" doesn't make sense given that =20 >> the >> OPEN call can not be encoded that way. >> >> So, am I to assume that "EXCLUSIVE CREATE" be replaced with SETATTR or >> layout_hint? >> This seems reasonable to me. Should there be any additional guidance >> given other than "may or may not be able to handle it"? Should the >> server silently ignore the attribute if not supported? Is there a >> timeframe when a server is most likely to be able to handle the hint? >> For example, before the first read/write to the file? >> >> Spencer >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 17 09:57:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAnYa-00067W-9c; Tue, 17 Jul 2007 09:57:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAnYX-000678-Au for nfsv4@ietf.org; Tue, 17 Jul 2007 09:57:37 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAnYW-0000qd-00 for nfsv4@ietf.org; Tue, 17 Jul 2007 09:57:37 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6HDvZva020951; Tue, 17 Jul 2007 09:57:35 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 17 Jul 2007 09:57:35 -0400 Received: from [192.168.0.140] ([172.17.28.142]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 09:57:34 -0400 Message-ID: <469CCACD.7040104@panasas.com> Date: Tue, 17 Jul 2007 16:57:33 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Spencer Shepler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 13:57:35.0137 (UTC) FILETIME=[6D761910:01C7C87A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: NFSv4 Subject: [nfsv4] Stateid Structure in draft-12 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Spencer, the text added in draft-12 to section 8.1.3.1 about incrementing seqid looks syntactically weird to me.... 8001 below, the NFSv4.1 specification requires the server to increment 8002 seqid field by one (1) whenever it returns a stateid with an "other" 8003 field on that is different that that of the previous stateid it ^^ ^n^? 8012 generated for the state owner/file combination. The purpose of the But, in the next paragraph it says: 8028 In the case of stateids associated with opens, i.e. the stateids 8029 returned by OPEN (the state for the open, rather than that for the 8030 delegation), OPEN_DOWNGRADE, or CLOSE, the server MUST provide an 8031 "seqid" value starting at one for the first use of a given "other" 8032 value and incremented by one with each subsequent operation returning 8033 a stateid. Doesn't that contradict the text on lines 8000-8012? What am I missing? Benny _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 17 10:41:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoEc-0005V6-JM; Tue, 17 Jul 2007 10:41:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoEb-0005QT-3d for nfsv4@ietf.org; Tue, 17 Jul 2007 10:41:05 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAoEZ-0002Oa-KN for nfsv4@ietf.org; Tue, 17 Jul 2007 10:41:04 -0400 X-IronPort-AV: E=Sophos;i="4.16,546,1175497200"; d="scan'208";a="82961889" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 17 Jul 2007 07:40:59 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6HEes3f006094; Tue, 17 Jul 2007 07:40:54 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 07:40:53 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 07:35:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Stateid Structure in draft-12 Date: Tue, 17 Jul 2007 10:30:35 -0400 Message-ID: In-Reply-To: <469CCACD.7040104@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Stateid Structure in draft-12 Thread-Index: AcfIercRykoTPg7wTF6T8JDL/DvBMwAAJnqw From: "Noveck, Dave" To: "Benny Halevy" , "Spencer Shepler" X-OriginalArrivalTime: 17 Jul 2007 14:35:02.0580 (UTC) FILETIME=[A90AAF40:01C7C87F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I don't think you are missing anything. This issue has been recently discussed back and forth and I think we have come to a resolution but the text has not been correctly updated and as it stands now is inconsistent. So here is what I think we have agreed on: Seqids are used to distinguish any difference in the sets of locks designated by a particular "other" value (I think we different word than that). The server must send a seqid of one on the creation of a stateid with a new other value that represents some set of locks with a given ownership status and file. When there is a change in that set of locks (different=20 byte ranges and/or upgrade/downgrade) but the file and ownership status is the same, then the server must send back a stateid with the same other value and seqid=20 incremented by one. The client may send to the server a stateid with a=20 specific owner value and the seqid set to zero. (This would typically be done for READ and WRITE). In this case, this designates the current stateid corresponding to that other value, no matter what the seqid. The client may also send to server a stated with a=20 non-zero seqid value in which case the server checks=20 that that is the most recent seqid for the given other value. (This is typically used for CLOSE). If the=20 seqid is lower than the current value OLD_STATEID is returned while if it is higher than the current value, BAD_STATEID is returned. There need to be a set of rules about whether current=20 stateid is gotten with zero seqid ot not. My current version of that is that for CLOSE it has the seqid set while for anything else it substitutes zero. Anybody have any operations where they think the seqid should be propagated? -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Tuesday, July 17, 2007 9:58 AM To: Spencer Shepler Cc: NFSv4 Subject: [nfsv4] Stateid Structure in draft-12 Spencer, the text added in draft-12 to section 8.1.3.1 about incrementing seqid looks syntactically weird to me.... 8001 below, the NFSv4.1 specification requires the server to increment 8002 seqid field by one (1) whenever it returns a stateid with an "other" 8003 field on that is different that that of the previous stateid it ^^ ^n^?=20 8012 generated for the state owner/file combination. The purpose of the But, in the next paragraph it says: 8028 In the case of stateids associated with opens, i.e. the stateids 8029 returned by OPEN (the state for the open, rather than that for the 8030 delegation), OPEN_DOWNGRADE, or CLOSE, the server MUST provide an 8031 "seqid" value starting at one for the first use of a given "other" 8032 value and incremented by one with each subsequent operation returning 8033 a stateid. Doesn't that contradict the text on lines 8000-8012? What am I missing? Benny _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 17 15:37:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsrR-0005LU-QF; Tue, 17 Jul 2007 15:37:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAsrP-0005LO-UB for nfsv4@ietf.org; Tue, 17 Jul 2007 15:37:27 -0400 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAsrO-0005Gy-Om for nfsv4@ietf.org; Tue, 17 Jul 2007 15:37:27 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1218979nzf for ; Tue, 17 Jul 2007 12:37:26 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=eMjADyzSzvWtY0/pNUWfHjqQzmOBZ4NqAgdO8PhpT61iX0mNq8NBvuWhhVu21l9rFXCJe00sQeUEROlo4J6j+CFLqnKHcGP5fdBPKFT8BJYRlPzjQ4r+vO4hqt/Kq1Dp8wErsgBSZFKpj8KHsAj6IbmsRUlfPHSKEh+ThAtSP4A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:x-google-sender-auth; b=VmLLY2uCQrrOQQy5G39ZcaYPt9p++TzEbs5jj5+8Wq4sThnMmldjnBcACvVc0/u7zNx0F/2h2PMu5n4lPVin5KWkRb63qBTOKbZVA7ZO4Le4LY5mOoQXOoQpT0seMKfcWzRxQPIMKfQnwkMEuWxz+wyTLEdj114lCmRUeLkaF2Y= Received: by 10.143.160.1 with SMTP id m1mr58338wfo.1184701045962; Tue, 17 Jul 2007 12:37:25 -0700 (PDT) Received: by 10.142.98.1 with HTTP; Tue, 17 Jul 2007 12:37:25 -0700 (PDT) Message-ID: <89c397150707171237t2ade5fbaq6aa312514f1902d4@mail.gmail.com> Date: Tue, 17 Jul 2007 15:37:25 -0400 From: "William A. (Andy) Adamson" To: NFSv4 MIME-Version: 1.0 X-Google-Sender-Auth: b985caca156c55f3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: nfsv4 Subject: [nfsv4] Announcing the Fall 2007 NFSv4.1 CITI sponsored Bakeathon X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1308338460==" Errors-To: nfsv4-bounces@ietf.org --===============1308338460== Content-Type: multipart/alternative; boundary="----=_Part_62979_29347145.1184701045938" ------=_Part_62979_29347145.1184701045938 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline CITI is pleased to sponsor an NFSv4.1 bakeathon October 8 - 12 2007. The purpose of this event is to test implementation interoperability of NFSv4.1protocol features including Sessions and pNFS. Registration will open the first week of August. For more information please visit: http://www.citi.umich.edu/projects/nfsv4/citi_bakeathon/14th_nfsv4_bakeathon.html -->Andy Adamson ------=_Part_62979_29347145.1184701045938 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline CITI is pleased to sponsor an NFSv4.1 bakeathon October 8 - 12 2007. The purpose of this event is to test implementation interoperability of NFSv4.1 protocol features including Sessions and pNFS.

Registration will open the first week of August. For more information please visit:

http://www.citi.umich.edu/projects/nfsv4/citi_bakeathon/14th_nfsv4_bakeathon.html

-->Andy Adamson
------=_Part_62979_29347145.1184701045938-- --===============1308338460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 --===============1308338460==-- From nfsv4-bounces@ietf.org Fri Jul 20 11:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBubN-0003q3-Cd; Fri, 20 Jul 2007 11:41:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBubL-0003oe-Oq for nfsv4@ietf.org; Fri, 20 Jul 2007 11:41:07 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBubK-0001dR-Hv for nfsv4@ietf.org; Fri, 20 Jul 2007 11:41:07 -0400 Received: by citi.umich.edu (Postfix, from userid 103558) id 50BE64B4B; Fri, 20 Jul 2007 11:41:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by citi.umich.edu (Postfix) with ESMTP id 4E63E4B43 for ; Fri, 20 Jul 2007 11:41:06 -0400 (EDT) Date: Fri, 20 Jul 2007 11:41:06 -0400 (EDT) From: Fredric Isaman To: nfsv4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [nfsv4] draft-12 xdr comment X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org The new draft added the following lines to the .x file: const NFLH4_CARE_DENSE = NFL4_UFLG_DENSE; const NFLH4_CARE_COMMIT_THRU_MDS = NFL4_UFLG_COMMIT_THRU_MDS; While it is certainly clear what is meant here, I would just like to note that using an identifier on the right is not actually valid XDR. >From rfc 4506: constant: decimal-constant | hexadecimal-constant | octal-constant constant-def: "const" identifier "=" constant ";" Fred _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Jul 20 13:35:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwNc-0004d2-SD; Fri, 20 Jul 2007 13:35:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBwNb-0004bi-Sv for nfsv4@ietf.org; Fri, 20 Jul 2007 13:35:03 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBwNa-0003jg-HO for nfsv4@ietf.org; Fri, 20 Jul 2007 13:35:03 -0400 X-IronPort-AV: E=Sophos;i="4.16,563,1175497200"; d="scan'208";a="84171779" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 20 Jul 2007 10:35:01 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6KHZ1jR021116 for ; Fri, 20 Jul 2007 10:35:01 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 10:35:01 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 10:35:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jul 2007 13:35:00 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue with reclaim open-upgrades Thread-Index: AcfK9Ew0k83b52T+QcukAl1Meiuilw== From: "Noveck, Dave" To: "NFSv4" X-OriginalArrivalTime: 20 Jul 2007 17:35:01.0516 (UTC) FILETIME=[4CF2CCC0:01C7CAF4] X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [nfsv4] Issue with reclaim open-upgrades X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org The current spec has the following and I've been pondering what to do about it as part of the rewrite of the locking chapters. Therefore, the client MUST NOT perform an OPEN reclaim that is also an OPEN upgrade (Section 8.10) unless the client precedes the OPEN upgrade/reclaim with a TEST_STATEID operation in the same COMPOUND. The stateid used in TEST_STATEID will be that returned by the reclaim OPEN the OPEN upgrade/reclaim is upgrading the open state from. Alternatively, the client can avoid OPEN upgrade during the reclaim phase. It seems to me that this text is making an assumption that isn't really valid and that each op of the COMPOUND will be executed during the same reboot instance of the server. It seems weird to say that that won't happen but consider that we are dealing with persistent sessions and there are counter-intuitive situations. Consider a COMPOUND that has a rename of A to B and another op that renames C to D. Clearly the server can fail after one but before executing the other. What that means is that if the session is persistent that COMPOUND is reissued then you will have a situation is which reply cache provides the result, presumably OK for the first rename and the second rename is not found in the reply cache, since it wasn't executed in the earlier server instance. So there we have a clear case in which a COMPOUND contains ops executed in two different reboot instances. So given that that is possible in general, why isn't possible for the TEST_STATEID above. That is, why can you assume that because the TEST_STATEID succeeded the open-upgrade-reclaim that follows is fact going to be treated as an upgrade. Couldn't the TEST_STATEID be take from the reply cache and when the open is executed you are in a state in which the stateid isn't valid. So isn't the TEST_STATEID pointless? So some ways to fix this: Simply don't allow open-upgrade on reclaim. It doesn't seem like it is really necessary. Add some special rule about TEST_STATEID and persistent=20 sessions, which basically says that since they are=20 idempotent, they need not be saved, and must not be saved until some non-idempotent op has been processed (or just one more additional of any type), and then allow the=20 open-upgrade-reclaim if it is suitably close to the=20 TEST_STATEID. Change the sessions/recovery model to avoid this kind of=20 situation. In particular, this issue seems to result from the fact that we force the clientid to be persistent, in=20 situation which state had been lost and you are then in a=20 situation in which it is hard for the server to know=20 exactly what operations are associated with what server=20 instance. So I guess what I'm asking here is whether it would be better to avoid the situation in which you get reclaim-needed on an existing session and clientid and then proceed to do those reclaims. Might it not be better to require heo client to establish a clientid and a new session for the reclaim. He would have access to old session but primarily for the purpose of redoing COMPOUNDs that he hadn't got a reply to, i.e. to get the reply cache information saved persistently. Are there others? _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Jul 22 16:25:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IChyy-0006MP-SP; Sun, 22 Jul 2007 16:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IChyx-0006MJ-MP for nfsv4@ietf.org; Sun, 22 Jul 2007 16:24:47 -0400 Received: from mail3.sea5.speakeasy.net ([69.17.117.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IChyx-0004QH-8f for nfsv4@ietf.org; Sun, 22 Jul 2007 16:24:47 -0400 Received: (qmail 27930 invoked from network); 22 Jul 2007 20:24:46 -0000 Received: from dsl092-066-197.bos1.dsl.speakeasy.net (HELO d.namei) ([66.92.66.197]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Jul 2007 20:24:46 -0000 Date: Sun, 22 Jul 2007 16:24:45 -0400 (EDT) From: James Morris X-X-Sender: jmorris@d.namei To: nfsv4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [nfsv4] ANN: Labeled NFS mailing list X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org The folk at linux-nfs.org have kindly setup a mailing list for the Labeled NFS development effort. The purpose of the list is for initial analysis and design of a mandatory access control (MAC) extension to NFSv4, in support of SELinux and other MAC schemes across different platforms. For mailing list subscription information, please see: http://linux-nfs.org/cgi-bin/mailman/listinfo/labeled-nfs Prior discussion of this project (which started out as SELinux-specific) may be found at: http://thread.gmane.org/gmane.linux.nfsv4/5341 -- James Morris _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From SammyprepMoody@angelesinn.com Mon Jul 23 04:10:24 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICszn-0007zg-T1 for nfsv4-archive@lists.ietf.org; Mon, 23 Jul 2007 04:10:23 -0400 Received: from [122.164.147.182] (helo=airtelbroadband.in) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICszj-0005cu-Ke for nfsv4-archive@lists.ietf.org; Mon, 23 Jul 2007 04:10:23 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host24332675.angelesinn.com (8.13.1/8.13.1) with SMTP id 66kpGKBO77.804752.vRI.5xn.0949253786933 for ; Tue, 1 Jan 2002 06:41:24 -0530 Message-ID: <704c01c19261$6ef668d0$07330101@sys13win7> From: "Rufus Lindsey" To: nfsv4-archive@lists.ietf.org Subject: Fwd: Thanks, we are ready to lend money regardless of Credit Date: Tue, 1 Jan 2002 06:41:24 -0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_7048_01C19261.6EF668D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.4 (++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is a multi-part message in MIME format. ------=_NextPart_000_7048_01C19261.6EF668D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Your credit history does not matter to us! If you OWN property and want IMMEDIATE pin money to spend ANY way you = like, or simply require to LOWER your entire payment by a third or more, = here is the deal we can offer you TODAY (hurry, this offer will expire = THIS NIGHT): $241,000+ loan AND EVEN MORE: After further review, our lenders have established the = lowest payments! Hurry, when our deal is gone, it is gone. Simply finish this = user-friendly form... Do not worry about approval, your credit will not disqualify you! http://inkhealthhealth.com/ ------=_NextPart_000_7048_01C19261.6EF668D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20
Your credit history does not = matter to us!
=20
 
If you OWN property and want = IMMEDIATE pin money=20 to spend ANY way you like, or simply require to LOWER your entire = payment by a=20 third or more, here is the deal we can offer you TODAY (hurry, this = offer will=20 expire THIS NIGHT):
=20
 
$241,000+ loan
 
AND EVEN MORE: After further review, = our lenders=20 have established the lowest payments!
=20
 
Hurry, when our deal is gone, it = is gone.=20 Simply finish this user-friendly form...
=20
 
Do not worry about approval, your = credit will=20 not disqualify you!
=20
 
http://inkhealthhealth.com/
------=_NextPart_000_7048_01C19261.6EF668D0-- From nfsv4-bounces@ietf.org Tue Jul 24 17:36:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDS3I-0007Jj-IK; Tue, 24 Jul 2007 17:36:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDS3G-0007Iz-Jd for nfsv4@ietf.org; Tue, 24 Jul 2007 17:36:18 -0400 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDS3F-0003cC-Gq for nfsv4@ietf.org; Tue, 24 Jul 2007 17:36:18 -0400 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDS3E-00015l-Mk for nfsv4@ietf.org; Tue, 24 Jul 2007 23:36:16 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx2.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDS3E-0001Ox-1R for nfsv4@ietf.org; Tue, 24 Jul 2007 23:36:16 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx2.uio.no with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1IDS3D-0001Ot-Gq for nfsv4@ietf.org; Tue, 24 Jul 2007 23:36:15 +0200 From: Trond Myklebust To: nfsv4@ietf.org Content-Type: text/plain Date: Tue, 24 Jul 2007 17:36:14 -0400 Message-Id: <1185312974.6586.73.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.061) X-UiO-Scanned: CD3B3567425E6D32F0E7F655F92C0D95CD139B31 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 223 total 2956695 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Subject: [nfsv4] Global Namespaces Chapters Review #1 - minutes X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Note: Some of the attributions here may be incorrect. In particular, Dan Ellard turned up late and failed to notify us when he did. Please check attributions for correctness... -------------------------------------------------- Mike Eisler (NetApp) Daniel Ellard (NetApp) Craig Everhart (NetApp) Reader Trond Myklebust (NetApp) Scribe Dave Noveck (NetApp) Author Theresa Raj (NetApp) Renu Tewari (IBM) Robert Thurlow (SUN) Spencer Shepler (SUN) Moderator Fred Isaman (CITI) --------------------------------------------------------- Spencer kicked off the meeting with the usual cautions about all your comments are belong to IETF. ----------- 7633 Everhart Is it "Name Space" or "Namespace"? Both editors appear to prefer "namespace" Wikipedia appears to agree, so it must be true! ....Craig went off to print out Draft 11.... 7681 Myklebust To a first-time reader, it would not be obvious that this paragraph refers to NFSv2/v3. Perhaps a better strategy would be to discuss NFSv2/v3 first, then NFSv4? Thurlow Join paragraphs 2 & 3? ----- 7710 Myklebust Do you really require a unique fsid for each pseudo filesystem? Concensus is to retain the requirement but expand to a MUST. Thurlow Can we have /a/b also be a pseudo-filesystem? Noveck It cannot have symlinks etc. Eisler Can you return fs_location? Consensus is no... Note that pseudo filesystem is there in order to bridge v2/v3 namespace and v4 namespace. ----- 7715 Everhart Clarify the text to explain that the pseudo-filesystem solution is implementation advice, not normative. Toss out the words "DOS" and note that MacOS 9 is unlikely to ever implement a v4.1 server. Myklebust MacOSX does not have this issue. ----- 7732 Ellard? Delete section 7.5. It is obvious that pseudofilesystems may use volatile filehandles. Myklebust Move this to the section on volatile filehandles? It is a major justification for implementing them. Noveck Agrees. ----- 7754 Eisler Convert archaic references to "disk" to "filesystem" in the examples. ---- 7795 Myklebust What is the recommended practice for dealing with LOOKUP/READDIR without confusing client caches? Should the pseudo-fs allow READDIR lookups for the entire shadowed directory? You cannot have both the pseudo-filesystem and the filesystem mounted, so if the server returns different filesystems based on security mechanism used by the user then that will confuse the client. Could we add text to clarify that this is not allowed? Noveck You should use WRONGSEC to tell the user when to change security mechanism. Eisler You should always return the same content. Consensus.... ---- 7823 Ellard? Need clarification of this paragraph. The intention is that the client should always be able to traverse down to a given exported filesystem. Myklebust The pseudofilesystem should always support all security mechanisms that are supported by the filesystems it is bridging. Eisler You don't need to return the contents of the pathnames. ---- ---- Chapter 10.... ---- 10665 Eisler Attributes are recommended, so should multi-server name space be RECOMMENDED? Consensus is that use is "OPTIONAL", implementation is "RECOMMENDED" ---- 10700 Thurlow Why have both fs_status and fs_absent? Noveck Histerical reasons... fs_absent should probably go... Consensus.... ---- 10786 Raj Should we be using the change attribute to tell the client whether it can change policies such as referrals and secinfo? Myklebust Could we please use a separate attribute to signify changes to policy? Consensus is that we can and should. ---- 10790 Raj What should the value of the fsid be? Noveck Any value as long as it is unique. Thurlow If the client has accessed a filesystem, will it observe that fsid change if the filesystem is migrated? Noveck No, the fsid should not change. Myklebust That would require the fsid to be stored somewhere. Consensus is this needs clarification ---- 10837 Raj The example at 12077 conflicts with this paragraph. Everhart Deal with that later... ---- 10957 Thurlow The sentence starting "Where file systems are writable..." is unclear. Is the requirement too strong? Everhart It is talking about the clustered case. Consensus is that entire section needs work... Everhart Should writeable filesystems always be in sync? Noveck That was indeed the intent. Need to take this to the lists.... Myklebust Does this apply to locks too? Needs further discussion. ---- 11024 Ellard? Is inconsistent with the discussion in 10957. Thurlow Wording works better for me here. 11038 Everhart What is the scope for the word "similar". Take this to the lists ---- 11068 Everhart This line is inconsistent with lines 11024 & 10957. ---- 11076 Everhart See the earlier discussion of RECOMMENDED vs OPTIONAL. Noveck Agrees this para should reflect that. ---- 11113 Myklebust Is this an issue? The client needs to manage its own namespace anyway: it can never rely on the results of LOOKUPP in order to determine whether or not it is crossing a mountpoint. Move this to the more general point of mountpoint crossing? Eisler The point is that the client may assume that whereas submounts of the replicated filesystem are the same, the parent namespace is not. Noveck will rewrite the paragraph to make Mike's point more apparent. Thurlow Suggest adding a forward reference in the Single Server namespace chapter "Entries in a pseudofilesystem may be directories containing any of the following: referrals or the mountpoints of present filesystems." No consensus: take this to the lists. ---- 11122 Ellard? This paragraph really belongs under LOOKUPP. Nothing to do with referrals. ---- Raj Since migration/replication is OPTIONAL, there could be cases where the client doesn't support referrals. It would be useful for the server to know this. Eisler EXCHANGE_ID already tells the server this info. We should add a reference. ---- Everhart Is there a time-to-live? Isaman There is on 12628, but it doesn't refer to referrals. Myklebust Is this a useful concept? The server can't offer promises on behalf of the administrator. We have no equivalent for any of our other caches. No consensus... ---- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 24 17:37:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDS47-00089N-2h; Tue, 24 Jul 2007 17:37:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDS45-00089H-RF for nfsv4@ietf.org; Tue, 24 Jul 2007 17:37:09 -0400 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDS44-0007Si-Km for nfsv4@ietf.org; Tue, 24 Jul 2007 17:37:09 -0400 Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDS43-0001Nl-PC for nfsv4@ietf.org; Tue, 24 Jul 2007 23:37:07 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx1.uio.no) by mail-mx1.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDS43-000688-8d for nfsv4@ietf.org; Tue, 24 Jul 2007 23:37:07 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx1.uio.no with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1IDS42-000681-Nq for nfsv4@ietf.org; Tue, 24 Jul 2007 23:37:07 +0200 From: Trond Myklebust To: nfsv4@ietf.org Content-Type: text/plain Date: Tue, 24 Jul 2007 17:37:05 -0400 Message-Id: <1185313025.6586.75.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.081) X-UiO-Scanned: 3DE3DFBB257D6747D308496DC8A11787EB9E489D X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 230 total 2956702 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 1.8 (+) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Subject: [nfsv4] Global Namespaces Chapters Review #2 - minutes X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Daniel Ellard (NetApp) Craig Everhart (NetApp) Reader Trond Myklebust (NetApp) Scribe Dave Noveck (NetApp) Author Theresa Raj (NetApp) Renu Tewari (IBM) Robert Thurlow (SUN) Spencer Shepler (SUN) Moderator ------------------------------------------ Spencer started off with reminding us of the IETF blurb... ----- 11357 Myklebust How is staleness reported by the server? Noveck Text is modelled on v4.0. Might need to go back now that we have sessions and see whether we need to expand text or reference. ----- 11446 Myklebust Do we need a discussion here about the combination of volatile filehandles and volatile fileids. Noveck Agrees we need a paragraph based on the discussion we had on the list. Ellard Is there a situation where either filehandles or fileids (but not both) are volatile? Noveck Yes. Thurlow You cannot rely on fileids since they are not mandatory. Maybe there are some shoulds that should be SHOULDs.... Agreed to take this to the list ----- 11458 Noveck Maybe FSLI4F_MULTI_FS should be a separate section since it is being introduced here. ----- 11511 Everhart Dave promised a discussion on filesystem replication. Trond Will bring this up on the list. ----- 11529 Everhart 'it does necessarily mean' should be '...does not...' ----- Trond Need a better 'reclaim is done' marker. Noveck Can do RECLAIM COMPLETE. Everhart How does the server know all clients have sent reclaim complete? Trond Could we discuss an alternative based on a special session? Will bring to the list. ----- 11653 Everhart See [comment.8]. Noveck Need to look at this more. Will return to the group ----- 11638 Raj Does the server need to remember that it has sent an ERR_MOVED? You need to send LEASE_MOVED prior to that. Everhart Also need to wait for the GETATTR w/ fs_locations Noveck Once client gets LEASE_MOVED, it needs to iterate through filesystems and do a GETATTR to get ERR_MOVED. The iteration should only stop when the LEASE_MOVED flag is cleared. Thurlow Should we talk about fs_status rather than fs_locations_info since that is a lighter weight operation. Noveck The GETATTR doesn't need to be fs_locations_info. It is the ERR_MOVED result that counts. fs_status might be good alternative to ERR_MOVED Trond Could you use NVERIFY with fs_status followed by a fs_locations_info in order to do one-pass? Noveck The server will clear LEASE_MOVED on first successful fs_locations_info ----- 11722 Everhart The NOTE there is obsolete. The paragraph already addresses the issue of scope. Noveck Agrees. ----- 11728 Ellard The server may declare that all verifiers are invalid. Everhart Yes. Client should fall back to synchronous writes. This would be the case if server keeps going up and down... Noveck The thing to stress is to not recognise a verifier as valid when it is not. Then delete the rest of the text. ----- Pause while we waited for the author to change rooms.... ----- 11935 Thurlow Much handwaving there is in this text! Could we simplify it? Noveck Agrees ----- 12077 Trond rdattr_error should be NFS_OK because the READDIR request included fs_locations_info? Noveck Agrees 12709 Noveck Typo... 12085 Thurlow What is the reference. Noveck attributes are not included 'cos of NFS4ERR_MOVED ------ 12087 Noveck Delete section 10.8 since we don't need fs_absent. ----- 12167 Everhart should -> SHOULD Noveck OK. Trond Should we have any recommendations about when it is incorrect to fail to implement fs_locations_info. Basically list the cases that the fs_locations_info enables, and that cannot be supported by fs_locations. Noveck Agrees. In cases where fs_locations_info will return different results to fs_locations you SHOULD implement former. Otherwise client has no way of knowing what it should do. Extend paragraph starting at 12212. Trond will suggest text. ----- 12255 Thurlow Need to add context in order to explain that is offsets into fs_locations_info. ----- Everhart What is the scope of fs_locations_info? Will all replicas give the same fs_locations_info? Noveck No. There is no requirement that fs_locations_info be synchronised. One replica may know about the existence of other replicas that are not known to all. Even attributes may differ. Filehandles may be of the same class when you go in one direction (from replica A to replica B), but not when you go in the reverse direction. Need text to discuss this at end of 12339. ----- 12345 Raj Is fls_currency supposed to be globally consistent? Noveck Yes. ----- 12553 Everhart Do we need a READDIR cookie change class? Noveck Hadn't thought of that. Maybe... Trond Could we use READDIR verifiers? Noveck Problem is that you need to agree on verifiers across servers. Consensus is add READDIR change class Noveck Need to change CLVERIFIER to reflect it is write verifier. Don't need change directory verifier. That is part of cookie change class. ----- 12424 Thurlow Guarantee implied here. Is that enforcable? Noveck Issue is what clients can depend upon. If client migrates, it needs to know that it doesn't have to replay committed writes. Thurlow A client may still want to migrate if it has no choice.... Thurlow will initiate further discussion on the lists. ----- 12567 Thurlow Don't like the fact that server can order me to a particular replica. Noveck Add language to clarify. Load balancing considerations may not be part of a client calculation. Otherwise server should be conservative with ordering. ----- 12628 Thurlow What is fli_valid_for? Not defined in the structure. Noveck Will add to structure. Needs to be int32. ----- 12648 Thurlow Incomplete sentence? Noveck Need to extend sentence. Governs what 12660 is about. Move this sentence over to 12662 ----- 12660 Thurlow We need a centralised location for documenting substituted variables so that administrators can know. IANA registry? Informational RFC? Needs further discussion. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 24 17:44:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSAo-0005wh-ED; Tue, 24 Jul 2007 17:44:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDSAm-0005wb-W0 for nfsv4@ietf.org; Tue, 24 Jul 2007 17:44:04 -0400 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDSAl-0003nd-NA for nfsv4@ietf.org; Tue, 24 Jul 2007 17:44:04 -0400 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDSAl-00034G-69 for nfsv4@ietf.org; Tue, 24 Jul 2007 23:44:03 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx2.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDSAk-0001kX-Rc for nfsv4@ietf.org; Tue, 24 Jul 2007 23:44:03 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx2.uio.no with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1IDSAk-0001kT-Ff for nfsv4@ietf.org; Tue, 24 Jul 2007 23:44:02 +0200 Subject: Re: [nfsv4] Global Namespaces Chapters Review #1 - minutes From: Trond Myklebust To: nfsv4@ietf.org In-Reply-To: <1185312974.6586.73.camel@localhost> References: <1185312974.6586.73.camel@localhost> Content-Type: text/plain Date: Tue, 24 Jul 2007 17:44:00 -0400 Message-Id: <1185313440.6586.84.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.061) X-UiO-Scanned: 4E66D1AABC90AC468AA12FB2DB35E657287B4FF1 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 274 total 2956746 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Tue, 2007-07-24 at 17:36 -0400, Trond Myklebust wrote: > Note: Some of the attributions here may be incorrect. In particular, Dan > Ellard turned up late and failed to notify us when he did. Please check > attributions for correctness... > > -------------------------------------------------- > Mike Eisler (NetApp) > Daniel Ellard (NetApp) > Craig Everhart (NetApp) Reader > Trond Myklebust (NetApp) Scribe > Dave Noveck (NetApp) Author > Theresa Raj (NetApp) > > Renu Tewari (IBM) > > Robert Thurlow (SUN) > Spencer Shepler (SUN) Moderator > > > Fred Isaman (CITI) > > --------------------------------------------------------- > > Spencer kicked off the meeting with the usual cautions about > all your comments are belong to IETF. > > ----------- > > 7633 Everhart Is it "Name Space" or "Namespace"? > Both editors appear to prefer "namespace" > Wikipedia appears to agree, so it must be true! > > ....Craig went off to print out Draft 11.... I should perhaps have pointed out here that the line numbers in these minutes are all relative to Draft 11 of the NFSv4.1 spec since the previous reviews have all been relative to draft 10... Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 25 09:30:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDgwg-0000L9-En; Wed, 25 Jul 2007 09:30:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDgwf-0000FV-3l for nfsv4@ietf.org; Wed, 25 Jul 2007 09:30:29 -0400 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDgwe-0003Up-7y for nfsv4@ietf.org; Wed, 25 Jul 2007 09:30:28 -0400 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDgwd-0006G3-8h for nfsv4@ietf.org; Wed, 25 Jul 2007 15:30:27 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx2.uio.no) by mail-mx2.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDgwc-0004SK-PX for nfsv4@ietf.org; Wed, 25 Jul 2007 15:30:27 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx2.uio.no with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1IDgwc-0004RU-DP for nfsv4@ietf.org; Wed, 25 Jul 2007 15:30:26 +0200 From: Trond Myklebust To: nfsv4@ietf.org Content-Type: text/plain Date: Wed, 25 Jul 2007 09:30:24 -0400 Message-Id: <1185370224.6585.58.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.059) X-UiO-Scanned: C0CB20B657D2A62229866A71FB884576EE61005D X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 405 total 2966773 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [nfsv4] Fallout from the global namespaces review: state recovery... X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org As seen from the minutes of the review, there was some concern about the recovery semantics suggested in the paragraph starting at line 11578: In place of a file-system-specific version of RECLAIM_COMPLETE, servers may assume that an attempt to obtain a new lock, other than be reclaim, indicate the end of the client's attempt to reclaim locks for that file system. [NOTE: The alternative would be to adapt RECLAIM_COMPLETE to this task]. For one thing, this requires clients to keep the filesystem entirely quiescent while doing recovery. More worrisome is perhaps the fact that it relies on the existence of some process running on the client that requires a new lock in order to complete the state recovery. There is no suggestion for what the client should do if it only wants to recover existing state, and doesn't need to open a new file or take a lock. In order to address issues like this, I'd therefore like to propose an alternative to the current state recovery model. Rather than extend RECLAIM_COMPLETE to take an fsid argument etc..., I'd like to propose a model that extends the sessions model. I believe this has several advantages over the existing idiom. --------- The proposal is to add a new csa_flag CREATE_SESSION4_FLAG_RECOVER that indicates to the server that the session being created will be used for state recovery. If none of the exported filesystems are in grace at the time, then the server should return an error NFS4ERR_NO_GRACE. If the client MUST not set CREATE_SESSION4_FLAG_CONN_BACK_CHAN in conjunction with CREATE_SESSION4_FLAG_RECOVER (return NFS4ERR_INVAL). Once the recovery session has been established, then all state recovery operations MUST be sent using that session. It is an error for the client to issue non-recovery OPEN, LOCK, WANT_DELEGATION operations on the recovery session, and a server should return NFS4ERR_OP_ILLEGAL in this case. While state recovery is going on, servers MAY choose to return NFS4ERR_DELAY on all requests issued on non-recovery sessions in order to optimise performance for state recovery, or if it does not satisfy the requirements to safely process lock, READ or WRITE requests during the grace period. Once the client is done recovering state, it indicates this to the server by issuing a DESTROY_SESSION call for the recovery session. The server may also choose to terminate the grace period early by invalidating the session (although it SHOULD NOT do so before at least one lease period has expired in order to give clients the opportunity to discover the reboot). ------------ This proposal would also obsolete the RECLAIM_COMPLETE operation, since the DESTROY_SESSION operation takes over its role. Cheers Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 25 09:37:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDh3a-0004f9-9B; Wed, 25 Jul 2007 09:37:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDh3Y-0004ek-Kq for nfsv4@ietf.org; Wed, 25 Jul 2007 09:37:36 -0400 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDh3W-0007jq-Q8 for nfsv4@ietf.org; Wed, 25 Jul 2007 09:37:36 -0400 Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDh3W-0008MM-2t for nfsv4@ietf.org; Wed, 25 Jul 2007 15:37:34 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx6.uio.no) by mail-mx6.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDh3V-0007Z0-QX for nfsv4@ietf.org; Wed, 25 Jul 2007 15:37:34 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx6.uio.no with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1IDh3V-0007Yw-Es for nfsv4@ietf.org; Wed, 25 Jul 2007 15:37:33 +0200 Subject: Re: [nfsv4] Fallout from the global namespaces review: state recovery... From: Trond Myklebust To: nfsv4@ietf.org In-Reply-To: <1185370224.6585.58.camel@localhost> References: <1185370224.6585.58.camel@localhost> Content-Type: text/plain Date: Wed, 25 Jul 2007 09:37:32 -0400 Message-Id: <1185370652.6585.64.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.096) X-UiO-Scanned: 5419FED666558FE6A1011141E2A82904AD73811F X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 493 total 2966861 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Wed, 2007-07-25 at 09:30 -0400, Trond Myklebust wrote: > Once the client is done recovering state, it indicates this to the > server by issuing a DESTROY_SESSION call for the recovery session. The > server may also choose to terminate the grace period early by > invalidating the session (although it SHOULD NOT do so before at least > one lease period has expired in order to give clients the opportunity to > discover the reboot). I forgot to mention. One other of the advantages of using a special session when it comes to migration, is that in addition to telling the server when recovery has ended it also gives it an idea of whether or not the client has _started_ recovery. Unlike the traditional reboot recovery process, when migrating from one server to another, it may turn out that the client already holds state on the new server. If so, then looking out for an EXCHANGE_ID or traditional SESSION_CREATE does not suffice in order to figure out if the client wants to recover state. Looking out for the creation of a recovery session does... Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 25 10:36:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDhyU-0007V1-O4; Wed, 25 Jul 2007 10:36:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDhyU-0007Uw-5c for nfsv4@ietf.org; Wed, 25 Jul 2007 10:36:26 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDhyS-0000M2-JF for nfsv4@ietf.org; Wed, 25 Jul 2007 10:36:26 -0400 X-IronPort-AV: E=Sophos;i="4.16,581,1175497200"; d="scan'208";a="85772680" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 25 Jul 2007 07:36:23 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6PEaMF7005625; Wed, 25 Jul 2007 07:36:22 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 07:36:20 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 07:36:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Fallout from the global namespaces review: state recovery... Date: Wed, 25 Jul 2007 10:36:18 -0400 Message-ID: In-Reply-To: <1185370224.6585.58.camel@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Fallout from the global namespaces review: state recovery... Thread-Index: AcfOwEWWSMwKU4YeQPKPsDcPg9NVYQAAfDVg From: "Noveck, Dave" To: "Trond Myklebust" , X-OriginalArrivalTime: 25 Jul 2007 14:36:20.0234 (UTC) FILETIME=[2AA1BEA0:01C7CEC9] X-Spam-Score: -4.0 (----) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org One issue that concerns me is the need to try to clamp down on changes to the minimum necessary to address problems found in the current spec. In other words, we have reached the point where simply making the protocol better, as opposed to workable or correct, is a sufficient reason to make a change. I think Tronds's proposal is kind of neat, but I think that by creating kinds of sessions, devoted to particular purposes, it probably means significant change to some of the text of the sessions chapter, or at least another careful review, to make sure that we don't need any. This is a substantial conceptual change, even though I think it is a direction that might have been worth exploring if the v4.1 clock were not so far along.=20 So Trond raises the issue of a client with no locks to get beyond those, if any, that it has reclaimed. I agree this is a problem, but I don't think his change really addresses it. It has the same sort of problem that RECLAIM_COMPLETE does. As he indicates, DESTROY_SESSION, for the appropriate type of session, is the equivalent of RECLAIM_COMPLETE. Given that it has the same issue of delineating the scope of recovery completion with regard to transferred fs's. A number of fs's can be transferred at approximately the same time so it not clear that when you create such a session, how you can ensure that the client and server have the same view of the set of fs's for which recovery will be done by a particular session, and thus whose recovery phase will be terminated by the associated DESTROY_SESSION. At the review meeting, I attempted to hand-wave away the need for an fs-specific recovery-complete mechanism, by arguing that if source and destination fs's were sufficiently co-ordinated for the set of clients with locks to be known by the destination, then it isn't much harder for the source to tell the destination all of the locks, in which case recovery-complete is not necessary since you can mark off the locks as they are actually recovered. The problem with that argument is that it is valid in the case of a planned transfer but perhaps not in the case of an unplanned transfer. Clearly it is much easier for the source to notify the destination of each new client that has locks than it is to update the destination so its image of the client lock corpus is precisely in sync with that of the source. On the other hand, transfers of writable filesystem (and read-only ones are trivial with regard to recovery-complete issues), sufficient to meet the semantic requirements for those to work effectively, would need extensive interaction between source and destination, in any case. At that point we have to deal with the fact that exact semantics for transfers of writable file systems is still not fully settled. So I think our options here are: Explain why this case is unlikely be important, and argue=20 that the worst thing that the absence of any specific provision for it will result in a normal-sized grace period in a case that is unlikely to happen very much. Strengthen the kludge suggested in the text by making it clear that any attempt to get a lock via non-reclaim means, even=20 if not well-formed (e.g. share mode of none, or zero-length string as the name) will be recognized as ending the=20 reclaim for the client if done with the current-fh in the fs. This would allow a client to do something to delimit the recovery phase even if he didn't want to get any additional locks. =20 Add a RECLAIM_COMPLETE_FS which takes an fsid and tell the client to use it. I think the idea of building on the session model is interesting and probably will be important as v4.x goes forward (someday), but it just seems too late for 4.1. =20 -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Wednesday, July 25, 2007 9:30 AM To: nfsv4@ietf.org Subject: [nfsv4] Fallout from the global namespaces review: state recovery... As seen from the minutes of the review, there was some concern about the recovery semantics suggested in the paragraph starting at line 11578: In place of a file-system-specific version of RECLAIM_COMPLETE, servers may assume that an attempt to obtain a new lock, other than be reclaim, indicate the end of the client's attempt to reclaim locks for that file system. [NOTE: The alternative would be to adapt RECLAIM_COMPLETE to this task]. For one thing, this requires clients to keep the filesystem entirely quiescent while doing recovery. More worrisome is perhaps the fact that it relies on the existence of some process running on the client that requires a new lock in order to complete the state recovery. There is no suggestion for what the client should do if it only wants to recover existing state, and doesn't need to open a new file or take a lock. In order to address issues like this, I'd therefore like to propose an alternative to the current state recovery model. Rather than extend RECLAIM_COMPLETE to take an fsid argument etc..., I'd like to propose a model that extends the sessions model. I believe this has several advantages over the existing idiom. --------- The proposal is to add a new csa_flag CREATE_SESSION4_FLAG_RECOVER that indicates to the server that the session being created will be used for state recovery. If none of the exported filesystems are in grace at the time, then the server should return an error NFS4ERR_NO_GRACE. If the client MUST not set CREATE_SESSION4_FLAG_CONN_BACK_CHAN in conjunction with CREATE_SESSION4_FLAG_RECOVER (return NFS4ERR_INVAL).=20 Once the recovery session has been established, then all state recovery operations MUST be sent using that session. It is an error for the client to issue non-recovery OPEN, LOCK, WANT_DELEGATION operations on the recovery session, and a server should return NFS4ERR_OP_ILLEGAL in this case.=20 While state recovery is going on, servers MAY choose to return NFS4ERR_DELAY on all requests issued on non-recovery sessions in order to optimise performance for state recovery, or if it does not satisfy the requirements to safely process lock, READ or WRITE requests during the grace period. Once the client is done recovering state, it indicates this to the server by issuing a DESTROY_SESSION call for the recovery session. The server may also choose to terminate the grace period early by invalidating the session (although it SHOULD NOT do so before at least one lease period has expired in order to give clients the opportunity to discover the reboot). ------------ This proposal would also obsolete the RECLAIM_COMPLETE operation, since the DESTROY_SESSION operation takes over its role. Cheers Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 25 12:16:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjXk-0007TT-OM; Wed, 25 Jul 2007 12:16:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjXi-0007PG-RP for nfsv4@ietf.org; Wed, 25 Jul 2007 12:16:55 -0400 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDjXd-0003ZD-4O for nfsv4@ietf.org; Wed, 25 Jul 2007 12:16:54 -0400 Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6PGGgQ8027226; Wed, 25 Jul 2007 16:16:42 GMT Received: from [10.7.250.28] (punchin-client-10-7-250-28.SFBay.Sun.COM [10.7.250.28]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l6PGGf3w927735; Wed, 25 Jul 2007 09:16:41 -0700 (PDT) Message-ID: <46A77767.8060805@sun.com> Date: Wed, 25 Jul 2007 10:16:39 -0600 From: Robert Thurlow User-Agent: Thunderbird 2.0b2 (X11/20070227) MIME-Version: 1.0 To: Trond Myklebust References: <1185313025.6586.75.camel@localhost> In-Reply-To: <1185313025.6586.75.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.0 (+++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: nfsv4@ietf.org Subject: [nfsv4] Replica currency X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org In a message with Subject "Global Namespaces Chapters Review #2 - minutes", Trond Myklebust wrote: > 12424 Thurlow Guarantee implied here. Is that enforcable? > Noveck Issue is what clients can depend upon. If client > migrates, it needs to know that it doesn't have > to replay committed writes. > Thurlow A client may still want to migrate if it has no > choice.... > > Thurlow will initiate further discussion on the lists. Here's what that was about. The clause in question is from 10.10.1, regarding fs_locations_server4: 12419 The general file system characteristics flag (at octet index 12420 FSLI4BX_GFLAGS) has the following bits defined within it: 12421 12422 o FSLI4GF_WRITABLE indicates that this fs target is writable, 12423 allowing it to be selected by clients which may need to write on 12424 this file system. When the current file system instance is 12425 writable, then any other file system to which the client might 12426 switch must incorporate within its data any committed write made 12427 on the current file system instance. My read of this is placing high standards on how the server does replication of received changes. The language seems to want to make it safe for the client to switch without facing any possibility that a previous change was not reflected. This seems different in intent from a distinct theme present in other parts of the draft that want to give the client good information about the currency of replicas and let them choose. I would expect that if a very good replica is available, there will be no difference in outcomes, but if the only writable copy is out-of-date, the language above implies to me that the client will not be offered that copy. I think we should move towards providing good information to the client rather than trying to require the server to meet this guarantee in all cases. Thoughts? Rob T _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 25 12:35:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjq7-0006e2-IQ; Wed, 25 Jul 2007 12:35:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjq5-0006b5-RE for nfsv4@ietf.org; Wed, 25 Jul 2007 12:35:53 -0400 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDjq5-0000eZ-Ds for nfsv4@ietf.org; Wed, 25 Jul 2007 12:35:53 -0400 Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDjq4-0005pe-Pm; Wed, 25 Jul 2007 18:35:52 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx5.uio.no) by mail-mx5.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDjq4-0002GY-9t; Wed, 25 Jul 2007 18:35:52 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx5.uio.no with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1IDjq3-0002GS-U2; Wed, 25 Jul 2007 18:35:52 +0200 Subject: RE: [nfsv4] Fallout from the global namespaces review: state recovery... From: Trond Myklebust To: "Eisler, Michael" In-Reply-To: <044B81DE141D7443BCE91E8F44B3C1E2068651CE@exsvl02.hq.netapp.com> References: <044B81DE141D7443BCE91E8F44B3C1E2068651CE@exsvl02.hq.netapp.com> Content-Type: text/plain Date: Wed, 25 Jul 2007 12:35:50 -0400 Message-Id: <1185381350.6585.85.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.082) X-UiO-Scanned: 7CAA2579FD05BA28ECFB582B068C9CC1DCE14E71 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 347 total 2968559 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Wed, 2007-07-25 at 08:22 -0700, Eisler, Michael wrote: > > The proposal is to add a new csa_flag > > CREATE_SESSION4_FLAG_RECOVER that > > indicates to the server that the session being created will > > be used for > > state recovery. If none of the exported filesystems are in > > grace at the > > time, then the server should return an error NFS4ERR_NO_GRACE. > > If the client MUST not set CREATE_SESSION4_FLAG_CONN_BACK_CHAN in > > conjunction with CREATE_SESSION4_FLAG_RECOVER (return NFS4ERR_INVAL). > > I didn't quite parse the last sentence; I can guess, but would rather > the > typo were cleaned up so that I can more fully grok the proposal. Sorry. That sentence should read "The client MUST not set CREATE_SESSION4_FLAG_CONN_BACK_CHAN in conjunction with CREATE_SESSION4_FLAG_RECOVER (return NFS4ERR_INVAL)." Basically, it makes little sense to set up a back channel on a session that is meant only for recovery, and that will be destroyed as soon as normal stateful operations resume. Cheers Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 25 13:54:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDl4H-0006rn-NB; Wed, 25 Jul 2007 13:54:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDl4F-0006i8-MJ for nfsv4@ietf.org; Wed, 25 Jul 2007 13:54:35 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDl4E-0007zV-Ay for nfsv4@ietf.org; Wed, 25 Jul 2007 13:54:35 -0400 X-IronPort-AV: E=Sophos;i="4.16,581,1175497200"; d="scan'208";a="85841350" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 25 Jul 2007 10:54:33 -0700 Received: from sacexrs02.hq.netapp.com (sacexrs02.hq.netapp.com [10.99.190.106]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6PHsNPS020162; Wed, 25 Jul 2007 10:54:32 -0700 (PDT) Received: from RTPEXMV01.hq.netapp.com ([10.100.157.176]) by sacexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 10:54:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Replica currency Date: Wed, 25 Jul 2007 13:54:28 -0400 Message-ID: In-Reply-To: <46A77767.8060805@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Replica currency Thread-Index: AcfO13/AskKCy7YnR7CIJmqrYBV4bgACy8YA References: <1185313025.6586.75.camel@localhost> <46A77767.8060805@sun.com> From: "Everhart, Craig" To: "Robert Thurlow" , "Trond Myklebust" X-OriginalArrivalTime: 25 Jul 2007 17:54:30.0168 (UTC) FILETIME=[D995B180:01C7CEE4] X-Spam-Score: -1.0 (-) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Perhaps the goal is to treat writable replicas in a fundamentally different way from read-only ones? Read-only ones may age but writable ones may not? The NFSv4 spec probably can't legislate against multiple writable replicas that can be mutually out-of-date, whether we individually think that's a good idea or not. But I think we need something more than the current language and semantics to describe such cases. Today the fs4_status structure has fsstat_age and fsstat_version, which make perfect sense if there's only one sequence of updates for that filesystem, but which make much less sense if multiple streams of writes can be sustained. Well, perhaps fsstat_version could make some sense since it's a timestamp, but it doesn't seem very usable since a client really doesn't know whether a prior change is present or will ever be present. fsstat_age doesn't make sense among mutually-inconsistent writable replicas. Rob's scenario could make sense more or less within how I read draft-11's intent if what he means is that the only repository for the most recent writes has been deemed lost, so a set of servers is now promoting a relatively-recent replica to writable status with concomitant data losses. Craig > -----Original Message----- > From: Robert Thurlow [mailto:robert.thurlow@sun.com]=20 > Sent: Wednesday, July 25, 2007 12:17 PM > To: Trond Myklebust > Cc: nfsv4@ietf.org > Subject: [nfsv4] Replica currency >=20 > In a message with Subject "Global Namespaces Chapters Review=20 > #2 - minutes", Trond Myklebust wrote: >=20 > > 12424 Thurlow Guarantee implied here. Is that=20 > enforcable? > > Noveck Issue is what clients can depend upon. If client > > migrates, it needs to know that it doesn't have > > to replay committed writes. > > Thurlow A client may still want to migrate if it has no > > choice.... > >=20 > > Thurlow will initiate further discussion on the lists. >=20 > Here's what that was about. >=20 > The clause in question is from 10.10.1, regarding=20 > fs_locations_server4: >=20 >=20 > 12419 The general file system characteristics flag (at octet index > 12420 FSLI4BX_GFLAGS) has the following bits defined within it: > 12421 > 12422 o FSLI4GF_WRITABLE indicates that this fs target=20 > is writable, > 12423 allowing it to be selected by clients which may need to=20 > write on > 12424 this file system. When the current file system=20 > instance is > 12425 writable, then any other file system to which=20 > the client might > 12426 switch must incorporate within its data any=20 > committed write=20 > made > 12427 on the current file system instance. >=20 >=20 > My read of this is placing high standards on how the server=20 > does replication of received changes. The language seems to=20 > want to make it safe for the client to switch without facing=20 > any possibility that a previous change was not reflected. >=20 > This seems different in intent from a distinct theme present=20 > in other parts of the draft that want to give the client good=20 > information about the currency of replicas and let them choose. > I would expect that if a very good replica is available,=20 > there will be no difference in outcomes, but if the only=20 > writable copy is out-of-date, the language above implies to=20 > me that the client will not be offered that copy. I think we=20 > should move towards providing good information to the client=20 > rather than trying to require the server to meet this=20 > guarantee in all cases. >=20 > Thoughts? >=20 > Rob T >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 25 14:25:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlYU-0002SL-GE; Wed, 25 Jul 2007 14:25:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlYT-0002NL-9Y for nfsv4@ietf.org; Wed, 25 Jul 2007 14:25:49 -0400 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDlYR-0000na-N8 for nfsv4@ietf.org; Wed, 25 Jul 2007 14:25:49 -0400 Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDlYR-0004tU-4M; Wed, 25 Jul 2007 20:25:47 +0200 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx8.uio.no) by mail-mx8.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IDlYQ-0000Ys-Pv; Wed, 25 Jul 2007 20:25:46 +0200 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx8.uio.no with esmtpsa (SSLv3:RC4-MD5:128) (Exim 4.67) (envelope-from ) id 1IDlYQ-0000Yf-CA; Wed, 25 Jul 2007 20:25:46 +0200 Subject: RE: [nfsv4] Fallout from the global namespaces review: state recovery... From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Wed, 25 Jul 2007 14:25:44 -0400 Message-Id: <1185387944.6585.107.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-Spam-info: not spam, SpamAssassin (score=0.0, required=12.0, autolearn=disabled, AWL=0.020) X-UiO-Scanned: CE60C214F606B14584576DA2A2DF343AA594852A X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 210 total 2969376 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Wed, 2007-07-25 at 10:36 -0400, Noveck, Dave wrote: > So Trond raises the issue of a client with no locks to get beyond those, > if any, that it has reclaimed. I agree this is a problem, but I don't > think his change really addresses it. It has the same sort of problem > that RECLAIM_COMPLETE does. As he indicates, DESTROY_SESSION, for the > appropriate type of session, is the equivalent of RECLAIM_COMPLETE. > Given that it has the same issue of delineating the scope of recovery > completion with regard to transferred fs's. A number of fs's can be > transferred at approximately the same time so it not clear that when you > create such a session, how you can ensure that the client and server > have the same view of the set of fs's for which recovery will be done by > a particular session, and thus whose recovery phase will be terminated > by the associated DESTROY_SESSION. Yes. If the client is recovering state on several filesystems at the same time, then it does indeed mean that you have to keep all fses in grace until the last DESTROY_SESSION has been called. Maybe that is a reason to keep RECLAIM_COMPLETE_FSID? If you do not have the session, however, how exactly do you know that the client actually wants to recover state on one of the migrated filesystems? There may be several replicas on several servers, and the client may have chosen to migrate to one server for one of the filesystems, and another server for the other filesystem. Are you suggesting that clients must run through the entire list of replicas and call RECLAIM_COMPLETE_FSID on all servers? Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 25 17:02:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnzb-0004PO-GM; Wed, 25 Jul 2007 17:01:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnzZ-0004PE-VE for nfsv4@ietf.org; Wed, 25 Jul 2007 17:01:57 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDnzZ-0000yk-KD for nfsv4@ietf.org; Wed, 25 Jul 2007 17:01:57 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6PL1vrv004145 for ; Wed, 25 Jul 2007 21:01:57 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLR00C01649EE00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 25 Jul 2007 15:01:57 -0600 (MDT) Received: from [68.241.129.177] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLR007OV6F3M650@mail-amer.sun.com> for nfsv4@ietf.org; Wed, 25 Jul 2007 15:01:56 -0600 (MDT) Date: Wed, 25 Jul 2007 16:01:06 -0500 From: Spencer Shepler To: nfsv4@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [nfsv4] Minutes and Presentations from NFSv4 WG meeting are posted (IETF69) X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org You will find the draft minutes and presentations posted here: https://datatracker.ietf.org/meeting/69/materials.html in the midst of the rest of the meeting materials. Please have a look at the minutes as there was a lot of good discussion; for those present, please review and provide corrections if needed. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 25 17:47:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDohk-0006s1-FQ; Wed, 25 Jul 2007 17:47:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDohj-0006rv-06 for nfsv4@ietf.org; Wed, 25 Jul 2007 17:47:35 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDohi-0002Dc-2M for nfsv4@ietf.org; Wed, 25 Jul 2007 17:47:34 -0400 X-IronPort-AV: E=Sophos;i="4.16,581,1175497200"; d="scan'208";a="85922849" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 25 Jul 2007 14:47:33 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6PLlWIL027820; Wed, 25 Jul 2007 14:47:32 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 14:47:32 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 14:47:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Fallout from the global namespaces review: staterecovery... Date: Wed, 25 Jul 2007 17:47:29 -0400 Message-ID: In-Reply-To: <1185387944.6585.107.camel@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Fallout from the global namespaces review: staterecovery... Thread-Index: AcfO6T5LUqR6foIST8KVsU/I+yly7AAFXMgw From: "Noveck, Dave" To: "Trond Myklebust" X-OriginalArrivalTime: 25 Jul 2007 21:47:30.0996 (UTC) FILETIME=[66CEBF40:01C7CF05] X-Spam-Score: 1.8 (+) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org > Are you suggesting that clients must run through the entire list of > replicas and call RECLAIM_COMPLETE_FSID on all servers? No. Let's divide the cases up. First we have the most common case in which there is likely to be multiple replicas, where they are read-only. In that case it has always been assumed that locks don't really matter. Nobody can change anything, so the utility of locks for locking out other people changing things isn't there. They are locked out from changing things inherently. Maybe we need to make this more explicit, but I don't there is a substantive issue to resolve. The second case where there are multiple writable and replicas fs_locations_info indicates that the relationship among these is that they are all in the simultaneous-use class. In that case, getting a lock on one replica is the equivalent of getting it on another, whether because the various replica descriptions are alternate paths to the same thing or they are paths to different things which are kept in sync via some means (cluster-fs code etc.). In this case, RECLAIM_COMPLETE_FS (or whatever we do to delimit the end of the recovery period) done for one replica should be considered as done for the whole set. There should be sufficient co-ordination to allow this, by the nature of the relationship which is being advertised.=20 So now we get to the last category where we have multiple writable replicas which are declared such that a lock on is not a lock on all. This is related to the issue Rob Thurlow raised about moving the proposed text more to a model where we tell people what guarantees whey can and can't expect, rather than mandating one level of support here. However, given the fact that you giving people wrote, we have to be as clear as possible about the effects of proceeding without certain levels of guarantee. In the particular case transferring use from one fs to multiple writable fs's where these fs's are not co-ordinated as to locking, it is clear that the applications will have to be specifically tolerant of this situation because we are allowing, for example, an application which has opened file with DENY=3DALL, to, after the = transfer, have a corresponding (and otherwise conflicting) open done by another client. So in that case, I can still see you want a grace period so that the client can reclaim his OPENs, even though the guarantee he gets is quite reduced. However, I just don't see any way that these individual servers can implement a shortened grace period, because it may not see all the clients. So I would just say that in that situation, the servers if they set up that situation have to accept that they are buying into a full grace period rather than one that could be shortened due to reclaim-completion-indications. That doesn't mean that the client should not indicate that it is finished reclaiming locks, but in most cases, the value will be minimal. If the servers are capable of co-ordnating their reclaim-completion-indications, then they can do this. =20 > Yes. If the client is recovering state on several filesystems at the > same time, then it does indeed mean that you have to keep all fses in > grace until the last DESTROY_SESSION has been called. Maybe that is a > reason to keep RECLAIM_COMPLETE_FSID? I was worried not so much about the delay until the last DESTROY_SESSION, but the ambiguity about which fs's had or had not been reclaims. If I set up a session and I reclaim some locks for a particular fsid, then once I destroy that session the server can consider that my client's reclaims for that (or those) fsids has been completed. The troublesome case is if I don't have any current locks to reclaim. In that case, I can't see how the server can be aware of my client's completion of the (empty) recovery phase for that particular fs.=20 -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Wednesday, July 25, 2007 2:26 PM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: RE: [nfsv4] Fallout from the global namespaces review: staterecovery... On Wed, 2007-07-25 at 10:36 -0400, Noveck, Dave wrote: > So Trond raises the issue of a client with no locks to get beyond those, > if any, that it has reclaimed. I agree this is a problem, but I don't > think his change really addresses it. It has the same sort of problem > that RECLAIM_COMPLETE does. As he indicates, DESTROY_SESSION, for the > appropriate type of session, is the equivalent of RECLAIM_COMPLETE. > Given that it has the same issue of delineating the scope of recovery > completion with regard to transferred fs's. A number of fs's can be > transferred at approximately the same time so it not clear that when you > create such a session, how you can ensure that the client and server > have the same view of the set of fs's for which recovery will be done by > a particular session, and thus whose recovery phase will be terminated > by the associated DESTROY_SESSION. Yes. If the client is recovering state on several filesystems at the same time, then it does indeed mean that you have to keep all fses in grace until the last DESTROY_SESSION has been called. Maybe that is a reason to keep RECLAIM_COMPLETE_FSID? If you do not have the session, however, how exactly do you know that the client actually wants to recover state on one of the migrated filesystems? There may be several replicas on several servers, and the client may have chosen to migrate to one server for one of the filesystems, and another server for the other filesystem. Are you suggesting that clients must run through the entire list of replicas and call RECLAIM_COMPLETE_FSID on all servers? Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 25 18:18:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDpB7-0003bp-5j; Wed, 25 Jul 2007 18:17:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDpB1-0003aB-Sw for nfsv4@ietf.org; Wed, 25 Jul 2007 18:17:52 -0400 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDpB1-0005z8-Fb for nfsv4@ietf.org; Wed, 25 Jul 2007 18:17:51 -0400 Received: from bfields by fieldses.org with local (Exim 4.67) (envelope-from ) id 1IDpAw-00015f-I3; Wed, 25 Jul 2007 18:17:46 -0400 Date: Wed, 25 Jul 2007 18:17:46 -0400 To: "Noveck, Dave" Subject: Re: [nfsv4] Fallout from the global namespaces review: staterecovery... Message-ID: <20070725221746.GG7943@fieldses.org> References: <1185387944.6585.107.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) From: "J. Bruce Fields" X-Spam-Score: 1.8 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: nfsv4@ietf.org, Trond Myklebust X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Wed, Jul 25, 2007 at 05:47:29PM -0400, Noveck, Dave wrote: > Let's divide the cases up. First we have the most common case in which > there is likely to be multiple replicas, where they are read-only. In > that case it has always been assumed that locks don't really matter. > Nobody can change anything, so the utility of locks for locking out > other people changing things isn't there. I didn't think "read only" meant "static". I would have thought that read delegations could still be useful on a read-only replica, for example. So "locks don't really matter" seems like an overstatement. Uh, but I may have lost the point of the discussion here. If you're updaing read-only replicas using an occasional rsync, I suppose you'd still like to know how soon after a reboot it's safe to allow the rsync job to run. But in that particular case probably nobody cares much if the rsync has to be delayed by a minute longer than necessary. I dunno. --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Jul 25 18:27:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDpK0-00030k-RV; Wed, 25 Jul 2007 18:27:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDpJz-00030e-Ph for nfsv4@ietf.org; Wed, 25 Jul 2007 18:27:07 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDpJz-0002xU-19 for nfsv4@ietf.org; Wed, 25 Jul 2007 18:27:07 -0400 X-IronPort-AV: E=Sophos;i="4.16,581,1175497200"; d="scan'208";a="85934405" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 25 Jul 2007 15:27:05 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6PMR56r004975; Wed, 25 Jul 2007 15:27:05 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 15:27:05 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 15:27:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Fallout from the global namespaces review:staterecovery... Date: Wed, 25 Jul 2007 18:27:03 -0400 Message-ID: In-Reply-To: <20070725221746.GG7943@fieldses.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Fallout from the global namespaces review:staterecovery... Thread-Index: AcfPCaVT9XiEGJuzRe6hD3sSPsebiQAAEofQ From: "Noveck, Dave" To: "J. Bruce Fields" X-OriginalArrivalTime: 25 Jul 2007 22:27:04.0761 (UTC) FILETIME=[EDAE8A90:01C7CF0A] X-Spam-Score: 1.8 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: nfsv4@ietf.org, Trond Myklebust X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org You're right, I did exaggerate. There are cases where locks do matter in the case of read-only replicas and read delegations are a good example. With regard to the basic issue, I think we are still in the same place. As far as delimiting the end of the recovery-phase for that fs, there is no real way to truncate the grace period, if you are typically going to have a subset of the source's set of clients as your clients, unless you have some sort of=20 inter-replica co-ordination. So I think where this leaves us is: We need some way of indicating the end of the reclaim-phase for a particular fs in these cases. We aren't exactly sure=20 which one to choose. It is the server's responsibility to use that to shorten the grace period if it can and to ignore it, if it is of no value because it doesn't have the complete set of servers anyway. -----Original Message----- From: J. Bruce Fields [mailto:bfields@fieldses.org]=20 Sent: Wednesday, July 25, 2007 6:18 PM To: Noveck, Dave Cc: Trond Myklebust; nfsv4@ietf.org Subject: Re: [nfsv4] Fallout from the global namespaces review:staterecovery... On Wed, Jul 25, 2007 at 05:47:29PM -0400, Noveck, Dave wrote: > Let's divide the cases up. First we have the most common case in which > there is likely to be multiple replicas, where they are read-only. In > that case it has always been assumed that locks don't really matter. > Nobody can change anything, so the utility of locks for locking out > other people changing things isn't there. I didn't think "read only" meant "static". I would have thought that read delegations could still be useful on a read-only replica, for example. So "locks don't really matter" seems like an overstatement. Uh, but I may have lost the point of the discussion here. If you're updaing read-only replicas using an occasional rsync, I suppose you'd still like to know how soon after a reboot it's safe to allow the rsync job to run. But in that particular case probably nobody cares much if the rsync has to be delayed by a minute longer than necessary. I dunno. --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From agaustin@ma2t.net Thu Jul 26 05:33:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDzj2-0007hc-Bp for nfsv4-archive@lists.ietf.org; Thu, 26 Jul 2007 05:33:40 -0400 Received: from [203.215.180.174] (helo=ma2t.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IDzj0-0007Oq-6Z for nfsv4-archive@lists.ietf.org; Thu, 26 Jul 2007 05:33:40 -0400 Message-ID: <001001c7cf2e$0f7e5010$000aeb24@webserver> From: "Dolores Purvis" To: "nfsv4-archive" Subject: Fw: Thank you, we are ready to lend some cash Date: Thu, 26 Jul 2007 02:33:50 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C7CF2E.0F7E5010" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.4682 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.4682 X-Spam-Score: 3.0 (+++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 ------=_NextPart_000_000D_01C7CF2E.0F7E5010 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Your credit history doesn't matter to us! If you have your own business and need IMMEDIATE ready money to spend = ANY way you like or require Extra money to give the business a boost or = require A low interest loan - NO STRINGS ATTACHED, here is the deal we = can offer you TONIGHT (hurry, this deal will expire TODAY): $33,000+ loan Hurry, when the deal is gone, it is gone. Simply Call Us... Do not worry about approval, your your credit report will not disqualify = you! Call Us Free on 877-542-1880 ------=_NextPart_000_000D_01C7CF2E.0F7E5010 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Your credit history = doesn't matter to us!
 
If you have your own = business and wish IMMEDIATE money to spend ANY way you like or want = Extra money to give the company a boost or require A low interest loan = - NO STRINGS ATTACHED, here is our best deal we can offer you THIS NIGHT = (hurry, this tender will expire NOW):
 
$25,000+ = loan
 
Hurry, when our best = deal is gone, it is gone. Simply Call Us...
 
Do not worry about = approval, your credit will not disqualify you!
 
Call Us Free on = 877-542-1880
------=_NextPart_000_000D_01C7CF2E.0F7E5010-- From nfsv4-bounces@ietf.org Thu Jul 26 14:41:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8H2-0008IF-FR; Thu, 26 Jul 2007 14:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE8H1-0008I7-21 for nfsv4@ietf.org; Thu, 26 Jul 2007 14:41:19 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE8Gz-0006A2-G9 for nfsv4@ietf.org; Thu, 26 Jul 2007 14:41:19 -0400 X-IronPort-AV: E=Sophos;i="4.16,584,1175497200"; d="scan'208";a="86267925" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 26 Jul 2007 11:41:16 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6QIfFxe027508; Thu, 26 Jul 2007 11:41:16 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 11:41:15 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 11:41:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Replica currency Date: Thu, 26 Jul 2007 14:41:14 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Replica currency Thread-Index: AcfO13/AskKCy7YnR7CIJmqrYBV4bgACy8YAADQo1NA= From: "Noveck, Dave" To: "Everhart, Craig" , "Robert Thurlow" , "Trond Myklebust" X-OriginalArrivalTime: 26 Jul 2007 18:41:15.0695 (UTC) FILETIME=[8C38E3F0:01C7CFB4] X-Spam-Score: -1.0 (-) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org We can legislate all we want. We just don't have any enforcement powers. Not that I really want any, mind you. I think the important thing is to give the servers a way to communicate the guarantees they are giving the clients and to make it clear to the clients how to interpret the those guaranees, so that nobody is surprised. As regarding the currency issue, I don't really think that multiple independently-updated replicas really conform to that model very well. If we are going to allow this, I think we just have to say that when there no authoritative source (which is the case when there are multiple writable versions), we can't have a meaningful concept of being current and the thing we have to do is not pretend to provide what we can't provide. =20 -----Original Message----- From: Everhart, Craig=20 Sent: Wednesday, July 25, 2007 1:54 PM To: Robert Thurlow; Trond Myklebust Cc: nfsv4@ietf.org Subject: RE: [nfsv4] Replica currency Perhaps the goal is to treat writable replicas in a fundamentally different way from read-only ones? Read-only ones may age but writable ones may not? The NFSv4 spec probably can't legislate against multiple writable replicas that can be mutually out-of-date, whether we individually think that's a good idea or not. But I think we need something more than the current language and semantics to describe such cases. Today the fs4_status structure has fsstat_age and fsstat_version, which make perfect sense if there's only one sequence of updates for that filesystem, but which make much less sense if multiple streams of writes can be sustained. Well, perhaps fsstat_version could make some sense since it's a timestamp, but it doesn't seem very usable since a client really doesn't know whether a prior change is present or will ever be present. fsstat_age doesn't make sense among mutually-inconsistent writable replicas. Rob's scenario could make sense more or less within how I read draft-11's intent if what he means is that the only repository for the most recent writes has been deemed lost, so a set of servers is now promoting a relatively-recent replica to writable status with concomitant data losses. Craig > -----Original Message----- > From: Robert Thurlow [mailto:robert.thurlow@sun.com] > Sent: Wednesday, July 25, 2007 12:17 PM > To: Trond Myklebust > Cc: nfsv4@ietf.org > Subject: [nfsv4] Replica currency >=20 > In a message with Subject "Global Namespaces Chapters Review > #2 - minutes", Trond Myklebust wrote: >=20 > > 12424 Thurlow Guarantee implied here. Is that=20 > enforcable? > > Noveck Issue is what clients can depend upon. If client > > migrates, it needs to know that it doesn't have > > to replay committed writes. > > Thurlow A client may still want to migrate if it has no > > choice.... > >=20 > > Thurlow will initiate further discussion on the lists. >=20 > Here's what that was about. >=20 > The clause in question is from 10.10.1, regarding > fs_locations_server4: >=20 >=20 > 12419 The general file system characteristics flag (at octet index > 12420 FSLI4BX_GFLAGS) has the following bits defined within it: > 12421 > 12422 o FSLI4GF_WRITABLE indicates that this fs target=20 > is writable, > 12423 allowing it to be selected by clients which may need to=20 > write on > 12424 this file system. When the current file system=20 > instance is > 12425 writable, then any other file system to which=20 > the client might > 12426 switch must incorporate within its data any=20 > committed write > made > 12427 on the current file system instance. >=20 >=20 > My read of this is placing high standards on how the server does=20 > replication of received changes. The language seems to want to make=20 > it safe for the client to switch without facing any possibility that a > previous change was not reflected. >=20 > This seems different in intent from a distinct theme present in other=20 > parts of the draft that want to give the client good information about > the currency of replicas and let them choose. > I would expect that if a very good replica is available, there will be > no difference in outcomes, but if the only writable copy is=20 > out-of-date, the language above implies to me that the client will not > be offered that copy. I think we should move towards providing good=20 > information to the client rather than trying to require the server to=20 > meet this guarantee in all cases. >=20 > Thoughts? >=20 > Rob T >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Jul 27 01:09:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEI4W-00046M-8R; Fri, 27 Jul 2007 01:09:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEI4V-00046F-1E for nfsv4@ietf.org; Fri, 27 Jul 2007 01:09:03 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEI4U-00012c-0n for nfsv4@ietf.org; Fri, 27 Jul 2007 01:09:02 -0400 Received: from fe-amer-06.sun.com ([192.18.108.180]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6R591Yc002219 for ; Fri, 27 Jul 2007 05:09:01 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLT00H01N2R7A00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 26 Jul 2007 23:09:01 -0600 (MDT) Received: from [129.153.128.222] (sca-ea-proxy-4.Sun.COM [192.18.43.29]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLT0058QNN0TF40@mail-amer.sun.com> for nfsv4@ietf.org; Thu, 26 Jul 2007 23:09:01 -0600 (MDT) Date: Fri, 27 Jul 2007 00:08:55 -0500 From: Spencer Shepler To: nfsv4@ietf.org Message-id: <72967EA1-AC36-4C15-ADE5-06F05B55D3A4@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Subject: [nfsv4] Layout stateids X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Working from Mike's stateids in layouts proposal, the ensuing thread of discussion and then the continued discussion during Monday's WG meeting, I offer the following proposal for stateids in layouts. The main purpose of this change is to ensure the client has a layout that is correctly derived from a valid OPEN of the file and to tie the layout to the lease held by the client. Of secondary concern is to increase the potential for parallelism between LAYOUTGET and LAYOUTRETURN, and to ease the data server's validation of layouts. Some assumptions/observations: Layouts are similar to byte range file locks; they are range based, can merge, can be split. Thus, the ordering of LAYOUTGET and LAYOUTRETURN matters greatly to the shared view the client and server has for layout ranges. The addition of stateids for LAYOUTGET and LAYOUTRETURN will allow for the ordering of execution at the server to be communicated to the client via the stateid4.seqid field just like the OPEN and LOCK sequencing is communciated. Note that the iomode provide two distinct sets of layout ranges -- an upgrade path from the READ iomode to the READ/WRITE iomode does NOT exist. Layouts are similar to delegations in that the stateid is valid beyond the life of the OPEN stateid (file can be closed and the client can continue holding a valid layout stateid). The other similarity with delegations is that layout stateids are associated with the filehandle/client pairing (NOT filehandle/"layout owner" like byte range file locks). The presence of layout stateids does not remove the utility of Sessions' slot referencing mechanism on CB_SEQUENCE. This was the conclusion of the discussion during the NFSv4 WG meeting on Monday (Brent Welch may send an email with a discussion of the general issues of sequencing and race conditions). Proposal: LAYOUTGET will take a stateid and return one in the results. For the first LAYOUTGET, the client MUST use a valid stateid as returned by OPEN, OPEN_DOWNGRADE, LOCK, LOCKU, WANT_DELEGATION (open, lock, or delegation stateids). For subsequent LAYOUTGETs, the client will provide a layout stateid. The client MUST hold a valid layout for I/O to any storage device type. The use of special stateids for data server I/O is not allowed. Layout stateids follow the sequencing and use rules of all other stateid types. Same stateid4.other value is returned for all layouts on the file (e.g. multiple LAYOUTGETs and LAYOUTRETURNs to the same file). LAYOUTRETURN will take a layout stateid and return a stateid. If the server has recalled a CB_LAYOUTRECALL and the client is returning a layout as a result, the client will also provide the layout stateid specified in the CB_LAYOUTRECALL. LAYOUTCOMMIT will take a layout stateid; it will not return a stateid. Layout stateids persist across CLOSE and DELEGRETURN. As noted above, for the NFSv4.1 layout type, READ and WRITE to a data server will continue to require an open, lock, or delegation stateid. The data server SHOULD be able to map these stateids to the granted layout to make sure the client has a layout, but in any case the data server MUST reject I/Os to files that do not have layouts. As with other state, layout stateids might become invalid when the lease expires. Spencer ------- struct LAYOUTCOMMIT4args { /* CURRENT_FH: file */ offset4 loca_offset; length4 loca_length; bool loca_reclaim; + stateid4 loca_stateid; newoffset4 loca_last_write_offset; newtime4 loca_time_modify; newtime4 loca_time_access; layoutupdate4 loca_layoutupdate; }; ... struct LAYOUTGET4args { /* CURRENT_FH: file */ bool loga_signal_layout_avail; layouttype4 loga_layout_type; layoutiomode4 loga_iomode; offset4 loga_offset; length4 loga_length; length4 loga_minlength; + stateid4 loga_stateid; count4 loga_maxcount; }; struct LAYOUTGET4resok { bool logr_return_on_close; + stateid4 logr_stateid; layout4 logr_layout; }; union LAYOUTGET4res switch (nfsstat4 logr_status) { case NFS4_OK: LAYOUTGET4resok logr_resok4; case NFS4ERR_LAYOUTTRYLATER: bool logr_will_signal_layout_avail; default: void; }; +union layoutrecall_stateid switch (bool lrs_present) { +case TRUE: + stateid4 lrs_stateid; +case FALSE: + void; +}; + struct LAYOUTRETURN4args { /* CURRENT_FH: file */ bool lora_reclaim; + stateid4 lora_stateid; + recall_stateid lora_recallstateid; layouttype4 lora_layout_type; layoutiomode4 lora_iomode; layoutreturn4 lora_layoutreturn; }; struct LAYOUTRETURN4res { nfsstat4 lorr_status; + stateid4 lorr_stateid; }; ... enum layoutrecall_type4 { LAYOUTRECALL4_FILE = 1, LAYOUTRECALL4_FSID = 2, LAYOUTRECALL4_ALL = 3 }; struct layoutrecall_file4 { nfs_fh4 lor_fh; offset4 lor_offset; length4 lor_length; + stateid4 lor_stateid; }; union layoutrecall4 switch(layoutrecall_type4 recalltype) { case LAYOUTRECALL4_FILE: layoutrecall_file4 lor_layout; case LAYOUTRECALL4_FSID: fsid4 lor_fsid; case LAYOUTRECALL4_ALL: void; }; struct CB_LAYOUTRECALL4args { layouttype4 clora_type; layoutiomode4 clora_iomode; bool clora_changed; layoutrecall4 clora_recall; }; _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Jul 27 01:12:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEI7c-0005qC-7v; Fri, 27 Jul 2007 01:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEI7b-0005q7-6u for nfsv4@ietf.org; Fri, 27 Jul 2007 01:12:15 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEI7Z-0000qF-Tb for nfsv4@ietf.org; Fri, 27 Jul 2007 01:12:15 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6R5CDwD003466 for ; Fri, 27 Jul 2007 05:12:13 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLT00A01NIJXS00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 26 Jul 2007 23:12:13 -0600 (MDT) Received: from [129.153.128.222] (sca-ea-proxy-4.Sun.COM [192.18.43.29]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLT006T2NSCCK00@mail-amer.sun.com> for nfsv4@ietf.org; Thu, 26 Jul 2007 23:12:13 -0600 (MDT) Date: Fri, 27 Jul 2007 00:12:11 -0500 From: Spencer Shepler To: nfsv4@ietf.org Message-id: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [nfsv4] Device stateids X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org We seem to have consensus on Mike's device stateid proposal and I will work to integrate the changes into the next draft. If there are any tweaks needed, please speak up. I have included the original text for reference. Spencer Recallable Device ID to Device Address Mappings ----------------------------------------------- Proposal: Make each MDS server's device ID to device adddress mappings a single recallable object. Rationale: The specification is unclear as to when device ID to device address mappings can change. There are attempts single tie these to layouts and/or leases. They should be tied to leases, but layouts are separate, albeit, related concept, and besides which, the layout-type independent part of a layout doesn't have a device ID. More Details of Proposal: I have previously observed that device mappings and their semantics closely follow directories. The desire to have recall of all of some mappings resembles directory delegations and notifications represent a model that device mappings could use. Thus it seems possible use directory operations for manipulating device mappings. However doing this would not save any operations because a "PUTDEVFH" operation (with a layouttype argument) would have to be added to allow READDIR to replace GETDEVICELIST (and then we have to figure out how to have directory entries represent device ID to device address mappingfs -- presumably with attributes). And an operation to map a device ID to an address would still be needed, unless we make device IDs file handles (a 4 byte length followed by a 4 byte handle). Regardless, the complexity of simulating a directory, when there aren't POSIX APIs that want directory semantics (e.g. per entry cookies) for device mappings might not be worth it, nor is the timing great for doing this scale of change. It also dubious if any of the READDIR code would be shared for real directories and device maps. An alternative is proposed below. GETDEVICEINFO or GETDEVICELIST each return a device stateid that represents a recallable, read-only hold on the mappings. Recall of the device stateid will remove the mappings. Lease expiration can remove the mappings. The mappings stay in force until recall of the stateid or lease expiration. GETDEVICEINFO and GETDEVICELIST change the current file handle so the CB_RECALL can be used to recall the device stateid. All layouts using the device IDs remain in force, but the server MUST fence the client from accessing the affected data servers until the device IDs are re-mapped (via GETDEVICEINFO or GETDEVICELIST). There is at most one device stateid per { client ID, layout type } pair. CB_NOTIFY can modify, delete, or add mappings, if GETDEVICEINFO and GETDEVICELIST request notifications and if the server supports device notifications. The notifications available are: NOTIFY4_DELETE_DEVICE_ID Deletes all mappings using the specified device ID. The server MUST stop using the device ID. Any layouts remain in force, but aren't useful until new mappings are available. The server fences the client from the affected data server until all layouts with the device ID are returned, or the client obtains new mappings. The server provides a hint as to whether new mappings will arrive and if so how long. NOTIFY4_ADD_DEVICE_ID Adds a device ID to address mapping. This is for a device ID the that was not returned in a previous series GETDEVICELIST calls (where the series ended in gdlr_eof == TRUE). The client calls GETDEVICEINFO or GETDEVICELIST to determine the mappings for the new device ID. NOTIFY4_CHANGE_DEVICE_ID The client call GETDEVICEINFO or GETDEVICELIST to get updated device addresses for the device ID. Layouts remain in force. The client is fenced from any devices that were in the old address list, but not the new address list. SEQUENCE will have a status flag added to indicate that the device mappings have been partially deleted, fully deleted (e.g. recall or lease expiry), changed, or added to. The partially deleted flag stays on until the client responds to any and all _DELETE notifications, or it does a GETDEVICELIST. The fully deleted flag stays on until DELEGRETURN returns the device stateid. The changed and added flags stay on until a GETDEVICELIST or GETDEVICEINFO gets the affected mappings. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Jul 27 09:26:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEPpz-0001S3-64; Fri, 27 Jul 2007 09:26:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEPpx-0001Rt-2h for nfsv4@ietf.org; Fri, 27 Jul 2007 09:26:33 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IEPpw-0004Df-8d for nfsv4@ietf.org; Fri, 27 Jul 2007 09:26:32 -0400 X-IronPort-AV: E=Sophos;i="4.16,589,1175497200"; d="scan'208";a="86541624" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 27 Jul 2007 06:26:27 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6RDQQXM004001; Fri, 27 Jul 2007 06:26:26 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 06:26:26 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Jul 2007 06:26:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Device stateids Date: Fri, 27 Jul 2007 09:26:25 -0400 Message-ID: In-Reply-To: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Device stateids Thread-Index: AcfQDL0zcTwHV5hrSc+JPICA67YEbgARMsnA From: "Noveck, Dave" To: "Spencer Shepler" , X-OriginalArrivalTime: 27 Jul 2007 13:26:26.0614 (UTC) FILETIME=[BBDD9D60:01C7D051] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I will make a change to the state management chapter to add this to the list of things that stateids can designate.=20 -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Friday, July 27, 2007 1:12 AM To: nfsv4@ietf.org Subject: [nfsv4] Device stateids We seem to have consensus on Mike's device stateid proposal and I will work to integrate the changes into the next draft. If there are any tweaks needed, please speak up. I have included the original text for reference. Spencer Recallable Device ID to Device Address Mappings ----------------------------------------------- Proposal: Make each MDS server's device ID to device adddress mappings a single recallable object. Rationale: The specification is unclear as to when device ID to device address mappings can change. There are attempts single tie these to layouts and/or leases. They should be tied to leases, but layouts are separate, albeit, related concept, and besides which, the layout-type independent part of a layout doesn't have a device ID. More Details of Proposal: I have previously observed that device mappings and their semantics closely follow directories. The desire to have recall of all of some mappings resembles directory delegations and notifications represent a model that device mappings could use. Thus it seems possible use directory operations for manipulating device mappings. However doing this would not save any operations because a "PUTDEVFH" operation (with a layouttype argument) would have to be added to allow READDIR to replace GETDEVICELIST (and then we have to figure out how to have directory entries represent device ID to device address mappingfs -- presumably with attributes). And an operation to map a device ID to an address would still be needed, unless we make device IDs file handles (a 4 byte length followed by a 4 byte handle). Regardless, the complexity of simulating a directory, when there aren't POSIX APIs that want directory semantics (e.g. per entry cookies) for device mappings might not be worth it, nor is the timing great for doing this scale of change. It also dubious if any of the READDIR code would be shared for real directories and device maps. An alternative is proposed below. GETDEVICEINFO or GETDEVICELIST each return a device stateid that represents a recallable, read-only hold on the mappings. Recall of the device stateid will remove the mappings. Lease expiration can remove the mappings. The mappings stay in force until recall of the stateid or lease expiration. GETDEVICEINFO and GETDEVICELIST change the current file handle so the CB_RECALL can be used to recall the device stateid. All layouts using the device IDs remain in force, but the server MUST fence the client from accessing the affected data servers until the device IDs are re-mapped (via GETDEVICEINFO or GETDEVICELIST). There is at most one device stateid per { client ID, layout type } pair. CB_NOTIFY can modify, delete, or add mappings, if GETDEVICEINFO and GETDEVICELIST request notifications and if the server supports device notifications. The notifications available are: NOTIFY4_DELETE_DEVICE_ID Deletes all mappings using the specified device ID. The server MUST stop using the device ID. Any layouts remain in force, but aren't useful until new mappings are available. The server fences the client from the affected data server until all layouts with the device ID are returned, or the client obtains new mappings. The server provides a hint as to whether new mappings will arrive and if so how long. NOTIFY4_ADD_DEVICE_ID Adds a device ID to address mapping. This is for a device ID the that was not returned in a previous series GETDEVICELIST calls (where the series ended in gdlr_eof =3D=3D TRUE). The client calls GETDEVICEINFO or GETDEVICELIST to determine the mappings for the new device ID. NOTIFY4_CHANGE_DEVICE_ID The client call GETDEVICEINFO or GETDEVICELIST to get updated device addresses for the device ID. Layouts remain in force. The client is fenced from any devices that were in the old address list, but not the new address list. SEQUENCE will have a status flag added to indicate that the device mappings have been partially deleted, fully deleted (e.g. recall or lease expiry), changed, or added to. The partially deleted flag stays on until the client responds to any and all _DELETE notifications, or it does a GETDEVICELIST. The fully deleted flag stays on until DELEGRETURN returns the device stateid. The changed and added flags stay on until a GETDEVICELIST or GETDEVICEINFO gets the affected mappings. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Jul 29 13:15:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFCLy-0000Pu-Kd; Sun, 29 Jul 2007 13:14:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFCLx-0000Pp-9y for nfsv4@ietf.org; Sun, 29 Jul 2007 13:14:49 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFCLv-0000Ry-U7 for nfsv4@ietf.org; Sun, 29 Jul 2007 13:14:49 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6THEg2Y008773; Sun, 29 Jul 2007 13:14:42 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 29 Jul 2007 13:14:42 -0400 Received: from [192.168.0.140] ([172.17.28.146]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 13:14:41 -0400 Message-ID: <46ACCB00.5000905@panasas.com> Date: Sun, 29 Jul 2007 20:14:40 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: [nfsv4] Layout stateids References: <72967EA1-AC36-4C15-ADE5-06F05B55D3A4@Sun.COM> In-Reply-To: <72967EA1-AC36-4C15-ADE5-06F05B55D3A4@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2007 17:14:41.0559 (UTC) FILETIME=[F383E270:01C7D203] X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Spencer Shepler wrote: > > Working from Mike's stateids in layouts proposal, the ensuing thread > of discussion and then the continued discussion during Monday's WG > meeting, I offer the following proposal for stateids in layouts. > > The main purpose of this change is to ensure the client has a layout > that is correctly derived from a valid OPEN of the file and to tie the > layout to the lease held by the client. Of secondary concern is to > increase the potential for parallelism between LAYOUTGET and > LAYOUTRETURN, and to ease the data server's validation of layouts. > > Some assumptions/observations: > > Layouts are similar to byte range file locks; they are range based, > can merge, can be split. Thus, the ordering of LAYOUTGET and > LAYOUTRETURN matters greatly to the shared view the client and server > has for layout ranges. The addition of stateids for LAYOUTGET and > LAYOUTRETURN will allow for the ordering of execution at the server to > be communicated to the client via the stateid4.seqid field just like > the OPEN and LOCK sequencing is communciated. Note that the iomode > provide two distinct sets of layout ranges -- an upgrade path from the > READ iomode to the READ/WRITE iomode does NOT exist. > > Layouts are similar to delegations in that the stateid is valid beyond > the life of the OPEN stateid (file can be closed and the client can > continue holding a valid layout stateid). The other similarity with > delegations is that layout stateids are associated with the > filehandle/client pairing (NOT filehandle/"layout owner" like byte > range file locks). > > The presence of layout stateids does not remove the utility of > Sessions' slot referencing mechanism on CB_SEQUENCE. This was the > conclusion of the discussion during the NFSv4 WG meeting on Monday > (Brent Welch may send an email with a discussion of the general issues > of sequencing and race conditions). > > Proposal: > > LAYOUTGET will take a stateid and return one in the results. > > For the first LAYOUTGET, the client MUST use a valid stateid as > returned by OPEN, OPEN_DOWNGRADE, LOCK, LOCKU, WANT_DELEGATION (open, > lock, or delegation stateids). For subsequent LAYOUTGETs, the client > will provide a layout stateid. > > The client MUST hold a valid layout for I/O to any storage > device type. > > The use of special stateids for data server I/O is not allowed. > > Layout stateids follow the sequencing and use rules of all other > stateid types. > > Same stateid4.other value is returned for all layouts on the file > (e.g. multiple LAYOUTGETs and LAYOUTRETURNs to the same file). I'd restrict that per layout_type since the encapsulated layout state per layout_type is independent and LAYOUT{GET,COMMIT,RETURN} as well as CB_LAYOUTRECALL carry the layout_type (CB_RECALL_ANY doesn't but it will not a have layout stateid either). > > LAYOUTRETURN will take a layout stateid and return a stateid. If the > server has recalled a CB_LAYOUTRECALL and the client is returning a > layout as a result, the client will also provide the layout stateid > specified in the CB_LAYOUTRECALL. > > LAYOUTCOMMIT will take a layout stateid; it will not return a stateid. > > Layout stateids persist across CLOSE and DELEGRETURN. > > As noted above, for the NFSv4.1 layout type, READ and WRITE to a data > server will continue to require an open, lock, or delegation stateid. > The data server SHOULD be able to map these stateids to the granted > layout to make sure the client has a layout, but in any case the data > server MUST reject I/Os to files that do not have layouts. > > As with other state, layout stateids might become invalid > when the lease expires. > > Spencer Thanks for incorporating the feedback for Mike's proposal into this one. To get that into the spec I think we need to provide more details about the following use cases (to start with): When should the server increase the sequence part of the stated? How strict do we want to be in the spec about this? What layout stateid should the client use on subsequent LAYOUTGET and LAYOUTRETURN operations? Can the client send multiple such operations in parallel? If so, what values should it use for the stateid? Currently we don't allow the client to send LAYOUTGET(s) concurrently with LAYOUTRETURN(s) but we do allow the client to send multiple concurrent LAYOUTGETs or multiple concurrent LAYOUTRETURNs since the order of execution between these, respectively, should not matter. Sending LAYOUTGET(s) in parallel to LAYOUTRETURN(s) may require strict ordering between the two. Can the client imply the order using the sent layout stateid by incrementing the stateid4.seqid? What should the server do if it gets the operations out of order? Benny > > ------- > struct LAYOUTCOMMIT4args { > /* CURRENT_FH: file */ > offset4 loca_offset; > length4 loca_length; > bool loca_reclaim; > + stateid4 loca_stateid; > newoffset4 loca_last_write_offset; > newtime4 loca_time_modify; > newtime4 loca_time_access; > layoutupdate4 loca_layoutupdate; > }; > ... > struct LAYOUTGET4args { > /* CURRENT_FH: file */ > bool loga_signal_layout_avail; > layouttype4 loga_layout_type; > layoutiomode4 loga_iomode; > offset4 loga_offset; > length4 loga_length; > length4 loga_minlength; > + stateid4 loga_stateid; > count4 loga_maxcount; > }; > struct LAYOUTGET4resok { > bool logr_return_on_close; > + stateid4 logr_stateid; > layout4 logr_layout; > }; > union LAYOUTGET4res switch (nfsstat4 logr_status) { > case NFS4_OK: > LAYOUTGET4resok logr_resok4; > case NFS4ERR_LAYOUTTRYLATER: > bool logr_will_signal_layout_avail; > default: > void; > }; > +union layoutrecall_stateid switch (bool lrs_present) { > +case TRUE: > + stateid4 lrs_stateid; > +case FALSE: > + void; > +}; > + > struct LAYOUTRETURN4args { > /* CURRENT_FH: file */ > bool lora_reclaim; > + stateid4 lora_stateid; > + recall_stateid lora_recallstateid; warning: unresolved symbol :) the type above is defined as "layoutrecall_stateid" but referred here as "recall_stateid" > layouttype4 lora_layout_type; > layoutiomode4 lora_iomode; > layoutreturn4 lora_layoutreturn; > }; > struct LAYOUTRETURN4res { > nfsstat4 lorr_status; > + stateid4 lorr_stateid; > }; Hmm, the returned stateid should be valid only for lorr_status == NFS_OK, like this: union LAYOUTRETURN4res switch (nfsstat4 lorr_status) { case NFS4_OK: stateid4 lorr_stateid; default: void; }; > ... > enum layoutrecall_type4 { > LAYOUTRECALL4_FILE = 1, > LAYOUTRECALL4_FSID = 2, > LAYOUTRECALL4_ALL = 3 > }; > struct layoutrecall_file4 { > nfs_fh4 lor_fh; > offset4 lor_offset; > length4 lor_length; > + stateid4 lor_stateid; > }; > union layoutrecall4 switch(layoutrecall_type4 recalltype) { > case LAYOUTRECALL4_FILE: > layoutrecall_file4 lor_layout; > case LAYOUTRECALL4_FSID: > fsid4 lor_fsid; > case LAYOUTRECALL4_ALL: > void; > }; > struct CB_LAYOUTRECALL4args { > layouttype4 clora_type; > layoutiomode4 clora_iomode; > bool clora_changed; > layoutrecall4 clora_recall; > }; > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Jul 29 19:30:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFIDB-0000yo-MX; Sun, 29 Jul 2007 19:30:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFIDA-0000yi-2R for nfsv4@ietf.org; Sun, 29 Jul 2007 19:30:08 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFID8-0007zk-Nz for nfsv4@ietf.org; Sun, 29 Jul 2007 19:30:07 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6TNU6VK003272; Sun, 29 Jul 2007 19:30:06 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6TNU05x025488; Sun, 29 Jul 2007 19:30:01 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 19:30:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Layout stateids Date: Sun, 29 Jul 2007 19:29:58 -0400 Message-ID: In-Reply-To: <46ACCB00.5000905@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Layout stateids Thread-Index: AcfSBErRlq5ZgKIAQpqInn5cy57U4QALGVpQ References: <72967EA1-AC36-4C15-ADE5-06F05B55D3A4@Sun.COM> <46ACCB00.5000905@panasas.com> To: , X-OriginalArrivalTime: 29 Jul 2007 23:30:00.0121 (UTC) FILETIME=[619FC290:01C7D238] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: fca7d4b87f391aa4d413f865ce6efe79 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Spencer, > Thanks for incorporating the feedback for Mike's proposal=20 > into this one. Ditto. > > Same stateid4.other value is returned for all layouts on the file > > (e.g. multiple LAYOUTGETs and LAYOUTRETURNs to the same file). >=20 > I'd restrict that per layout_type since the encapsulated layout state > per layout_type is independent and LAYOUT{GET,COMMIT,RETURN} as well > as CB_LAYOUTRECALL carry the layout_type (CB_RECALL_ANY doesn't but > it will not a have layout stateid either). I agree with Benny, although I'd be tempted to make use of different layout types on the same file at the same time a "MUST NOT" on the grounds that the opportunity for confusion probably outweighs the benefits of this sort of cleverness. Moving on to Benny's questions: > To get that into the spec I think we need to provide more details about=20 > the following use cases (to start with): >=20 > When should the server increase the sequence part of the stated? > How strict do we want to be in the spec about this? We need to be very specific about this, in order to avoid client confusion about what's going to happen. EMC's pre-pNFS protocol [FMP] increments for every LAYOUTGET and LAYOUTRETURN operation (actually their FMP equivalents and every recall. The resulting strict sequencing makes it easy for the clients to figure out what has been processed vs. will be rejected when the callback shows up. In addition, it sorts out the LAYOUTGET/LAYOUTRETURN ordering. The alternate approach of only incrementing on callback may require the client to wait for results of outstanding ops on callback, which delays client processing of the callback. > What layout stateid should the client use on subsequent LAYOUTGET > and LAYOUTRETURN operations? With strict sequencing, it uses the value that came back from the last operation, but ... > Can the client send multiple such operations in parallel? Good question. At the very least, the ability to ship multiple operations in a COMPOUND ought to be supported. Multiple operations in parallel from a single client is dangerous, as one can construct scenarios in which the client and server get out of sync due to not having the same understanding of which one went first when overlapping ranges are involved. I would hope that most of the important situations that arise can be covered by loading up all the operations into a single COMPOUND. > If so, what values should it use for the stateid? > Currently we don't allow the client to send LAYOUTGET(s) > concurrently with LAYOUTRETURN(s) And we need to retain that as this is the situation in which the client and server can get out of sync on layout state if there's any overlap. Keep in mind that the server may create overlap when the client doesn't expect it by tracking layout ranges at coarser granularity than the client requests them - the server has to be the final authority on how it does this. > but we do allow the client to send multiple concurrent LAYOUTGETs > or multiple concurrent LAYOUTRETURNs since the order > of execution between these, respectively, should not > matter. =20 Ok. > Sending LAYOUTGET(s) in parallel to LAYOUTRETURN(s) > may require strict ordering between the two. I think it does require strict ordering - see above rationale. > Can the client > imply the order using the sent layout stateid by incrementing > the stateid4.seqid? What should the server do if it gets > the operations out of order? If the client increments the seqid for concurrent ops and the server increments the seqid on a recall, occurrence of a recall in the middle of a bunch of concurrent client pNFS ops becomes peculiar - I think the client may have to wait for the results of all of its outstanding pNFS ops on that layout, as it does not know which ops have executed or will execute (as the server may execute an op after the recall courtesy of the client's seqid increment [that seems wrong]). I'd prefer to get the "multiple ops in a COMPOUND" case (where the ops are clearly sequenced) working right before attacking the concurrent ops case. I'm concerned that concurrent client operations may need to carry two sequence numbers for two purposes: - One to indicate intended order of client operations. - One to indicate how many recalls the client saw before issuing this operation. If the client operations are strictly sequenced, these collapse into one sequence number. I'd prefer not to go to two sequence numbers, with the hope that the COMPOUND case covers the proverbial "80%" of what's needed in practice. At a high level, if we stick to one sequence number, the resulting design tradeoff appears to be between: - Concurrent sets of LAYOUTGET and LAYOUTRETURN ops (but not a mixture - client has to not allow a mixture). - Fast client processing of recalls when there are outstanding ops. Strict sequencing of client operations is the simpler approach, it gets us the latter (which is what's wanted if there's contention), and should enable clients to mitigate the downside via use of multiple ops in a COMPOUND. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com]=20 > Sent: Sunday, July 29, 2007 1:15 PM > To: Spencer Shepler > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] Layout stateids >=20 > Spencer Shepler wrote: > >=20 > > Working from Mike's stateids in layouts proposal, the ensuing thread > > of discussion and then the continued discussion during Monday's WG > > meeting, I offer the following proposal for stateids in layouts. > >=20 > > The main purpose of this change is to ensure the client has a layout > > that is correctly derived from a valid OPEN of the file and to tie the > > layout to the lease held by the client. Of secondary concern is to > > increase the potential for parallelism between LAYOUTGET and > > LAYOUTRETURN, and to ease the data server's validation of layouts. > >=20 > > Some assumptions/observations: > >=20 > > Layouts are similar to byte range file locks; they are range based, > > can merge, can be split. Thus, the ordering of LAYOUTGET and > > LAYOUTRETURN matters greatly to the shared view the client and server > > has for layout ranges. The addition of stateids for LAYOUTGET and > > LAYOUTRETURN will allow for the ordering of execution at the server to > > be communicated to the client via the stateid4.seqid field just like > > the OPEN and LOCK sequencing is communciated. Note that the iomode > > provide two distinct sets of layout ranges -- an upgrade path from the > > READ iomode to the READ/WRITE iomode does NOT exist. > >=20 > > Layouts are similar to delegations in that the stateid is valid beyond > > the life of the OPEN stateid (file can be closed and the client can > > continue holding a valid layout stateid). The other similarity with > > delegations is that layout stateids are associated with the > > filehandle/client pairing (NOT filehandle/"layout owner" like byte > > range file locks). > > =09 > > The presence of layout stateids does not remove the utility of > > Sessions' slot referencing mechanism on CB_SEQUENCE. This was the > > conclusion of the discussion during the NFSv4 WG meeting on Monday > > (Brent Welch may send an email with a discussion of the general issues > > of sequencing and race conditions). > >=20 > > Proposal: > >=20 > > LAYOUTGET will take a stateid and return one in the results. > >=20 > > For the first LAYOUTGET, the client MUST use a valid stateid as > > returned by OPEN, OPEN_DOWNGRADE, LOCK, LOCKU, WANT_DELEGATION (open, > > lock, or delegation stateids). For subsequent LAYOUTGETs, the client > > will provide a layout stateid. > >=20 > > The client MUST hold a valid layout for I/O to any storage device type. > >=20 > > The use of special stateids for data server I/O is not allowed. > >=20 > > Layout stateids follow the sequencing and use rules of all other > > stateid types. > >=20 > > Same stateid4.other value is returned for all layouts on the file > > (e.g. multiple LAYOUTGETs and LAYOUTRETURNs to the same file). >=20 > I'd restrict that per layout_type since the encapsulated layout state > per layout_type is independent and LAYOUT{GET,COMMIT,RETURN} as well > as CB_LAYOUTRECALL carry the layout_type (CB_RECALL_ANY doesn't but > it will not a have layout stateid either). >=20 > >=20 > > LAYOUTRETURN will take a layout stateid and return a stateid. If the > > server has recalled a CB_LAYOUTRECALL and the client is returning a > > layout as a result, the client will also provide the layout stateid > > specified in the CB_LAYOUTRECALL. > >=20 > > LAYOUTCOMMIT will take a layout stateid; it will not return a stateid. > >=20 > > Layout stateids persist across CLOSE and DELEGRETURN. > >=20 > > As noted above, for the NFSv4.1 layout type, READ and WRITE to a data > > server will continue to require an open, lock, or delegation stateid. > > The data server SHOULD be able to map these stateids to the granted > > layout to make sure the client has a layout, but in any case the data > > server MUST reject I/Os to files that do not have layouts. > >=20 > > As with other state, layout stateids might become invalid > > when the lease expires. > >=20 > > Spencer >=20 > Thanks for incorporating the feedback for Mike's proposal=20 > into this one. >=20 > To get that into the spec I think we need to provide more details about=20 > the following use cases (to start with): >=20 > When should the server increase the sequence part of the stated? > How strict do we want to be in the spec about this? >=20 > What layout stateid should the client use on subsequent LAYOUTGET > and LAYOUTRETURN operations? >=20 > Can the client send multiple such operations in parallel? > If so, what values should it use for the stateid? > Currently we don't allow the client to send LAYOUTGET(s) > concurrently with LAYOUTRETURN(s) but we do allow the > client to send multiple concurrent LAYOUTGETs or > multiple concurrent LAYOUTRETURNs since the order > of execution between these, respectively, should not > matter. Sending LAYOUTGET(s) in parallel to LAYOUTRETURN(s) > may require strict ordering between the two. Can the client > imply the order using the sent layout stateid by incrementing > the stateid4.seqid? What should the server do if it gets > the operations out of order? >=20 > Benny >=20 > >=20 > > ------- > > struct LAYOUTCOMMIT4args { > > /* CURRENT_FH: file */ > > offset4 loca_offset; > > length4 loca_length; > > bool loca_reclaim; > > + stateid4 loca_stateid; > > newoffset4 loca_last_write_offset; > > newtime4 loca_time_modify; > > newtime4 loca_time_access; > > layoutupdate4 loca_layoutupdate; > > }; > > ... > > struct LAYOUTGET4args { > > /* CURRENT_FH: file */ > > bool loga_signal_layout_avail; > > layouttype4 loga_layout_type; > > layoutiomode4 loga_iomode; > > offset4 loga_offset; > > length4 loga_length; > > length4 loga_minlength; > > + stateid4 loga_stateid; > > count4 loga_maxcount; > > }; > > struct LAYOUTGET4resok { > > bool logr_return_on_close; > > + stateid4 logr_stateid; > > layout4 logr_layout; > > }; > > union LAYOUTGET4res switch (nfsstat4 logr_status) { > > case NFS4_OK: > > LAYOUTGET4resok logr_resok4; > > case NFS4ERR_LAYOUTTRYLATER: > > bool logr_will_signal_layout_avail; > > default: > > void; > > }; > > +union layoutrecall_stateid switch (bool lrs_present) { > > +case TRUE: > > + stateid4 lrs_stateid; > > +case FALSE: > > + void; > > +}; > > + > > struct LAYOUTRETURN4args { > > /* CURRENT_FH: file */ > > bool lora_reclaim; > > + stateid4 lora_stateid; > > + recall_stateid lora_recallstateid; >=20 > warning: unresolved symbol :) > the type above is defined as "layoutrecall_stateid" > but referred here as "recall_stateid" >=20 > > layouttype4 lora_layout_type; > > layoutiomode4 lora_iomode; > > layoutreturn4 lora_layoutreturn; > > }; > > struct LAYOUTRETURN4res { > > nfsstat4 lorr_status; > > + stateid4 lorr_stateid; > > }; >=20 >=20 > Hmm, the returned stateid should be valid only for=20 > lorr_status =3D=3D NFS_OK, > like this: >=20 > union LAYOUTRETURN4res switch (nfsstat4 lorr_status) { > case NFS4_OK: > stateid4 lorr_stateid; > default: > void; > }; >=20 > > ... > > enum layoutrecall_type4 { > > LAYOUTRECALL4_FILE =3D 1, > > LAYOUTRECALL4_FSID =3D 2, > > LAYOUTRECALL4_ALL =3D 3 > > }; > > struct layoutrecall_file4 { > > nfs_fh4 lor_fh; > > offset4 lor_offset; > > length4 lor_length; > > + stateid4 lor_stateid; > > }; > > union layoutrecall4 switch(layoutrecall_type4 recalltype) { > > case LAYOUTRECALL4_FILE: > > layoutrecall_file4 lor_layout; > > case LAYOUTRECALL4_FSID: > > fsid4 lor_fsid; > > case LAYOUTRECALL4_ALL: > > void; > > }; > > struct CB_LAYOUTRECALL4args { > > layouttype4 clora_type; > > layoutiomode4 clora_iomode; > > bool clora_changed; > > layoutrecall4 clora_recall; > > }; > >=20 > >=20 > > _______________________________________________ > > nfsv4 mailing list > > nfsv4@ietf.org > > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Jul 29 20:03:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFIjQ-0008PS-D4; Sun, 29 Jul 2007 20:03:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFIjO-0008PM-DO for nfsv4@ietf.org; Sun, 29 Jul 2007 20:03:26 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFIjM-0000Iq-Mg for nfsv4@ietf.org; Sun, 29 Jul 2007 20:03:26 -0400 X-IronPort-AV: E=Sophos;i="4.19,196,1183359600"; d="scan'208";a="87270289" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 29 Jul 2007 17:03:09 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6U037FP023651; Sun, 29 Jul 2007 17:03:08 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 17:01:12 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 17:01:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Layout stateids Date: Sun, 29 Jul 2007 20:01:10 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Layout stateids Thread-Index: AcfSBErRlq5ZgKIAQpqInn5cy57U4QALGVpQAALkeSA= From: "Noveck, Dave" To: , , X-OriginalArrivalTime: 30 Jul 2007 00:01:12.0678 (UTC) FILETIME=[BDC14860:01C7D23C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9178bae9f85419fdc08e9f2c86e345d0 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org > I agree with Benny, although I'd be tempted to make use of different > layout types on the same file at the same time a "MUST NOT" on the=20 > grounds that the opportunity for confusion probably outweighs the=20 > benefits of this sort of cleverness.=20 If we are talking about for the same client at the same time, I would agree. I think there may in the future be reasonable use cases for the case where we have different layout type for the same for different clients. Suppose you have a layout type that is an improvement-extension of an existing one. You very well might want the ability to provide the new type to clients that support it while providng the old to those who don't. -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: Sunday, July 29, 2007 7:30 PM To: bhalevy@panasas.com; Spencer.Shepler@Sun.COM Cc: nfsv4@ietf.org Subject: RE: [nfsv4] Layout stateids Spencer, > Thanks for incorporating the feedback for Mike's proposal into this=20 > one. Ditto. > > Same stateid4.other value is returned for all layouts on the file=20 > > (e.g. multiple LAYOUTGETs and LAYOUTRETURNs to the same file). >=20 > I'd restrict that per layout_type since the encapsulated layout state=20 > per layout_type is independent and LAYOUT{GET,COMMIT,RETURN} as well=20 > as CB_LAYOUTRECALL carry the layout_type (CB_RECALL_ANY doesn't but it > will not a have layout stateid either). I agree with Benny, although I'd be tempted to make use of different layout types on the same file at the same time a "MUST NOT" on the grounds that the opportunity for confusion probably outweighs the benefits of this sort of cleverness. Moving on to Benny's questions: > To get that into the spec I think we need to provide more details about=20 > the following use cases (to start with): >=20 > When should the server increase the sequence part of the stated? > How strict do we want to be in the spec about this? We need to be very specific about this, in order to avoid client confusion about what's going to happen. EMC's pre-pNFS protocol [FMP] increments for every LAYOUTGET and LAYOUTRETURN operation (actually their FMP equivalents and every recall. The resulting strict sequencing makes it easy for the clients to figure out what has been processed vs. will be rejected when the callback shows up. In addition, it sorts out the LAYOUTGET/LAYOUTRETURN ordering. The alternate approach of only incrementing on callback may require the client to wait for results of outstanding ops on callback, which delays client processing of the callback. > What layout stateid should the client use on subsequent LAYOUTGET and=20 > LAYOUTRETURN operations? With strict sequencing, it uses the value that came back from the last operation, but ... > Can the client send multiple such operations in parallel? Good question. At the very least, the ability to ship multiple operations in a COMPOUND ought to be supported. Multiple operations in parallel from a single client is dangerous, as one can construct scenarios in which the client and server get out of sync due to not having the same understanding of which one went first when overlapping ranges are involved. I would hope that most of the important situations that arise can be covered by loading up all the operations into a single COMPOUND. > If so, what values should it use for the stateid? > Currently we don't allow the client to send LAYOUTGET(s) concurrently=20 > with LAYOUTRETURN(s) And we need to retain that as this is the situation in which the client and server can get out of sync on layout state if there's any overlap. Keep in mind that the server may create overlap when the client doesn't expect it by tracking layout ranges at coarser granularity than the client requests them - the server has to be the final authority on how it does this. > but we do allow the client to send multiple concurrent LAYOUTGETs or=20 > multiple concurrent LAYOUTRETURNs since the order of execution between > these, respectively, should not matter. Ok. > Sending LAYOUTGET(s) in parallel to LAYOUTRETURN(s) may require strict > ordering between the two. I think it does require strict ordering - see above rationale. > Can the client > imply the order using the sent layout stateid by incrementing the=20 > stateid4.seqid? What should the server do if it gets the operations=20 > out of order? If the client increments the seqid for concurrent ops and the server increments the seqid on a recall, occurrence of a recall in the middle of a bunch of concurrent client pNFS ops becomes peculiar - I think the client may have to wait for the results of all of its outstanding pNFS ops on that layout, as it does not know which ops have executed or will execute (as the server may execute an op after the recall courtesy of the client's seqid increment [that seems wrong]). I'd prefer to get the "multiple ops in a COMPOUND" case (where the ops are clearly sequenced) working right before attacking the concurrent ops case. I'm concerned that concurrent client operations may need to carry two sequence numbers for two purposes: - One to indicate intended order of client operations. - One to indicate how many recalls the client saw before issuing this operation. If the client operations are strictly sequenced, these collapse into one sequence number. I'd prefer not to go to two sequence numbers, with the hope that the COMPOUND case covers the proverbial "80%" of what's needed in practice. At a high level, if we stick to one sequence number, the resulting design tradeoff appears to be between: - Concurrent sets of LAYOUTGET and LAYOUTRETURN ops (but not a mixture - client has to not allow a mixture). - Fast client processing of recalls when there are outstanding ops. Strict sequencing of client operations is the simpler approach, it gets us the latter (which is what's wanted if there's contention), and should enable clients to mitigate the downside via use of multiple ops in a COMPOUND. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com] > Sent: Sunday, July 29, 2007 1:15 PM > To: Spencer Shepler > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] Layout stateids >=20 > Spencer Shepler wrote: > >=20 > > Working from Mike's stateids in layouts proposal, the ensuing thread > > of discussion and then the continued discussion during Monday's WG=20 > > meeting, I offer the following proposal for stateids in layouts. > >=20 > > The main purpose of this change is to ensure the client has a layout > > that is correctly derived from a valid OPEN of the file and to tie the > > layout to the lease held by the client. Of secondary concern is to=20 > > increase the potential for parallelism between LAYOUTGET and=20 > > LAYOUTRETURN, and to ease the data server's validation of layouts. > >=20 > > Some assumptions/observations: > >=20 > > Layouts are similar to byte range file locks; they are range based,=20 > > can merge, can be split. Thus, the ordering of LAYOUTGET and=20 > > LAYOUTRETURN matters greatly to the shared view the client and server > > has for layout ranges. The addition of stateids for LAYOUTGET and=20 > > LAYOUTRETURN will allow for the ordering of execution at the server to > > be communicated to the client via the stateid4.seqid field just like > > the OPEN and LOCK sequencing is communciated. Note that the iomode=20 > > provide two distinct sets of layout ranges -- an upgrade path from the > > READ iomode to the READ/WRITE iomode does NOT exist. > >=20 > > Layouts are similar to delegations in that the stateid is valid beyond > > the life of the OPEN stateid (file can be closed and the client can=20 > > continue holding a valid layout stateid). The other similarity with > > delegations is that layout stateids are associated with the=20 > > filehandle/client pairing (NOT filehandle/"layout owner" like byte=20 > > range file locks). > > =09 > > The presence of layout stateids does not remove the utility of=20 > > Sessions' slot referencing mechanism on CB_SEQUENCE. This was the=20 > > conclusion of the discussion during the NFSv4 WG meeting on Monday=20 > > (Brent Welch may send an email with a discussion of the general issues > > of sequencing and race conditions). > >=20 > > Proposal: > >=20 > > LAYOUTGET will take a stateid and return one in the results. > >=20 > > For the first LAYOUTGET, the client MUST use a valid stateid as=20 > > returned by OPEN, OPEN_DOWNGRADE, LOCK, LOCKU, WANT_DELEGATION (open, > > lock, or delegation stateids). For subsequent LAYOUTGETs, the client > > will provide a layout stateid. > >=20 > > The client MUST hold a valid layout for I/O to any storage device type. > >=20 > > The use of special stateids for data server I/O is not allowed. > >=20 > > Layout stateids follow the sequencing and use rules of all other=20 > > stateid types. > >=20 > > Same stateid4.other value is returned for all layouts on the file=20 > > (e.g. multiple LAYOUTGETs and LAYOUTRETURNs to the same file). >=20 > I'd restrict that per layout_type since the encapsulated layout state=20 > per layout_type is independent and LAYOUT{GET,COMMIT,RETURN} as well=20 > as CB_LAYOUTRECALL carry the layout_type (CB_RECALL_ANY doesn't but it > will not a have layout stateid either). >=20 > >=20 > > LAYOUTRETURN will take a layout stateid and return a stateid. If the > > server has recalled a CB_LAYOUTRECALL and the client is returning a=20 > > layout as a result, the client will also provide the layout stateid=20 > > specified in the CB_LAYOUTRECALL. > >=20 > > LAYOUTCOMMIT will take a layout stateid; it will not return a stateid. > >=20 > > Layout stateids persist across CLOSE and DELEGRETURN. > >=20 > > As noted above, for the NFSv4.1 layout type, READ and WRITE to a data > > server will continue to require an open, lock, or delegation stateid. > > The data server SHOULD be able to map these stateids to the granted=20 > > layout to make sure the client has a layout, but in any case the data > > server MUST reject I/Os to files that do not have layouts. > >=20 > > As with other state, layout stateids might become invalid when the=20 > > lease expires. > >=20 > > Spencer >=20 > Thanks for incorporating the feedback for Mike's proposal into this=20 > one. >=20 > To get that into the spec I think we need to provide more details about=20 > the following use cases (to start with): >=20 > When should the server increase the sequence part of the stated? > How strict do we want to be in the spec about this? >=20 > What layout stateid should the client use on subsequent LAYOUTGET and=20 > LAYOUTRETURN operations? >=20 > Can the client send multiple such operations in parallel? > If so, what values should it use for the stateid? > Currently we don't allow the client to send LAYOUTGET(s) concurrently=20 > with LAYOUTRETURN(s) but we do allow the client to send multiple=20 > concurrent LAYOUTGETs or multiple concurrent LAYOUTRETURNs since the=20 > order of execution between these, respectively, should not matter. =20 > Sending LAYOUTGET(s) in parallel to LAYOUTRETURN(s) may require strict > ordering between the two. Can the client imply the order using the=20 > sent layout stateid by incrementing the stateid4.seqid? What should=20 > the server do if it gets the operations out of order? >=20 > Benny >=20 > >=20 > > ------- > > struct LAYOUTCOMMIT4args { > > /* CURRENT_FH: file */ > > offset4 loca_offset; > > length4 loca_length; > > bool loca_reclaim; > > + stateid4 loca_stateid; > > newoffset4 loca_last_write_offset; > > newtime4 loca_time_modify; > > newtime4 loca_time_access; > > layoutupdate4 loca_layoutupdate; > > }; > > ... > > struct LAYOUTGET4args { > > /* CURRENT_FH: file */ > > bool loga_signal_layout_avail; > > layouttype4 loga_layout_type; > > layoutiomode4 loga_iomode; > > offset4 loga_offset; > > length4 loga_length; > > length4 loga_minlength; > > + stateid4 loga_stateid; > > count4 loga_maxcount; > > }; > > struct LAYOUTGET4resok { > > bool logr_return_on_close; > > + stateid4 logr_stateid; > > layout4 logr_layout; > > }; > > union LAYOUTGET4res switch (nfsstat4 logr_status) { case NFS4_OK: > > LAYOUTGET4resok logr_resok4; > > case NFS4ERR_LAYOUTTRYLATER: > > bool logr_will_signal_layout_avail; > > default: > > void; > > }; > > +union layoutrecall_stateid switch (bool lrs_present) { case TRUE: > > + stateid4 lrs_stateid; > > +case FALSE: > > + void; > > +}; > > + > > struct LAYOUTRETURN4args { > > /* CURRENT_FH: file */ > > bool lora_reclaim; > > + stateid4 lora_stateid; > > + recall_stateid lora_recallstateid; >=20 > warning: unresolved symbol :) > the type above is defined as "layoutrecall_stateid" > but referred here as "recall_stateid" >=20 > > layouttype4 lora_layout_type; > > layoutiomode4 lora_iomode; > > layoutreturn4 lora_layoutreturn; > > }; > > struct LAYOUTRETURN4res { > > nfsstat4 lorr_status; > > + stateid4 lorr_stateid; > > }; >=20 >=20 > Hmm, the returned stateid should be valid only for lorr_status =3D=3D=20 > NFS_OK, like this: >=20 > union LAYOUTRETURN4res switch (nfsstat4 lorr_status) { case NFS4_OK: > stateid4 lorr_stateid; > default: > void; > }; >=20 > > ... > > enum layoutrecall_type4 { > > LAYOUTRECALL4_FILE =3D 1, > > LAYOUTRECALL4_FSID =3D 2, > > LAYOUTRECALL4_ALL =3D 3 > > }; > > struct layoutrecall_file4 { > > nfs_fh4 lor_fh; > > offset4 lor_offset; > > length4 lor_length; > > + stateid4 lor_stateid; > > }; > > union layoutrecall4 switch(layoutrecall_type4 recalltype) { case=20 > > LAYOUTRECALL4_FILE: > > layoutrecall_file4 lor_layout; > > case LAYOUTRECALL4_FSID: > > fsid4 lor_fsid; > > case LAYOUTRECALL4_ALL: > > void; > > }; > > struct CB_LAYOUTRECALL4args { > > layouttype4 clora_type; > > layoutiomode4 clora_iomode; > > bool clora_changed; > > layoutrecall4 clora_recall; > > }; > >=20 > >=20 > > _______________________________________________ > > nfsv4 mailing list > > nfsv4@ietf.org > > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 >=20 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Jul 29 22:01:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFKZH-0007Ad-V9; Sun, 29 Jul 2007 22:01:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFKZG-0007AY-UP for nfsv4@ietf.org; Sun, 29 Jul 2007 22:01:06 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFKZD-0003Wp-Dr for nfsv4@ietf.org; Sun, 29 Jul 2007 22:01:03 -0400 Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6U211dI017118; Sun, 29 Jul 2007 22:01:01 -0400 (EDT) Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id l6U20nLx000939; Sun, 29 Jul 2007 22:00:59 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 22:00:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Layout stateids Date: Sun, 29 Jul 2007 22:00:42 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Layout stateids Thread-Index: AcfSBErRlq5ZgKIAQpqInn5cy57U4QALGVpQAALkeSAABC3wcA== References: To: X-OriginalArrivalTime: 30 Jul 2007 02:00:42.0987 (UTC) FILETIME=[6F979BB0:01C7D24D] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.6.21134 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Dave, > > I agree with Benny, although I'd be tempted to make use of different > > layout types on the same file at the same time a "MUST NOT" on the=20 > > grounds that the opportunity for confusion probably outweighs the=20 > > benefits of this sort of cleverness.=20 >=20 > If we are talking about for the same client at the same time, I would > agree. >=20 > I think there may in the future be reasonable use cases for the case > where we have different layout type for the same for different clients. > Suppose you have a layout type that is an improvement-extension of an > existing one. You very well might want the ability to provide the new > type to clients that support it while providing the old to those who > don't. We are talking about "for the same client at the same time" as layout stateids are necessarily per-client. Support of different layout types for different clients at the same time on the same file is up to the server - it has the discretion to "just say no" to a layout request which would create a combination that the server doesn't want to have to deal with. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 30 13:07:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYi3-00088x-I5; Mon, 30 Jul 2007 13:07:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYi2-00088s-BK for nfsv4@ietf.org; Mon, 30 Jul 2007 13:07:06 -0400 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFYi1-0001oA-R3 for nfsv4@ietf.org; Mon, 30 Jul 2007 13:07:06 -0400 Received: from bfields by fieldses.org with local (Exim 4.67) (envelope-from ) id 1IFYhy-0002iP-8s; Mon, 30 Jul 2007 13:07:02 -0400 Date: Mon, 30 Jul 2007 13:07:02 -0400 To: Garth Goodson Message-ID: <20070730170702.GA2386@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-11) From: "J. Bruce Fields" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: nfsv4@ietf.org, eveuh@umich.edu Subject: [nfsv4] 4.1 wireshark patches X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org At some point you sent out a wireshark patch that added some nfsv4.1 parsing, but looking around I couldn't find it. Would you mind resending? Also, are you keeping those up to date, or do you know anyone else that is? We've got a student looking into it, but it'll take her some time to get up to speed, and we don't want to duplicate work. --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 30 13:18:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYrw-00085X-9P; Mon, 30 Jul 2007 13:17:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYrr-0007su-0o for nfsv4@ietf.org; Mon, 30 Jul 2007 13:17:15 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFYrn-00031X-PO for nfsv4@ietf.org; Mon, 30 Jul 2007 13:17:14 -0400 X-IronPort-AV: E=Sophos;i="4.19,199,1183359600"; d="scan'208";a="87483629" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Jul 2007 10:16:55 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6UHGtCf025509; Mon, 30 Jul 2007 10:16:55 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 10:16:55 -0700 Received: from exsvl03.hq.netapp.com ([10.56.8.64]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 10:16:54 -0700 Received: from [10.34.24.132] ([10.34.24.132]) by exsvl03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 10:16:54 -0700 Message-ID: <46AE1D05.3060505@netapp.com> Date: Mon, 30 Jul 2007 10:16:53 -0700 From: Garth Goodson User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: [nfsv4] Device stateids References: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> In-Reply-To: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 17:16:54.0323 (UTC) FILETIME=[6D0FD030:01C7D2CD] X-Spam-Score: -4.0 (----) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: nfsv4@ietf.org, Marc Eshel X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Spencer Shepler wrote: > > We seem to have consensus on Mike's device stateid proposal > and I will work to integrate the changes into the next draft. > If there are any tweaks needed, please speak up. > > I have included the original text for reference. > > Spencer > I think one of the areas still under debate was about the ability to recall and return multiple devices at once and I want to make sure everyone is aware of the implication of this proposal. There was discussion about breaking the deviceID in two sections (major,minor) such that a recall could recall all IDs associated with a major num. I don't see this in the proposal below. So my question is, is it possible to recall all device IDs for a given FSID in a single call, and return in a single call (like it is in the current text)? If not, is everyone ok with this. -Garth > > > > Recallable Device ID to Device Address Mappings > ----------------------------------------------- > > Proposal: > > Make each MDS server's device ID to device adddress > mappings a single recallable object. > > Rationale: > > The specification is unclear as to when device ID to device > address mappings can change. There are attempts single > tie these to layouts and/or leases. They should be tied to > leases, but layouts are separate, albeit, related concept, > and besides which, the layout-type independent part of a > layout doesn't have a device ID. > > More Details of Proposal: > > I have previously observed that device mappings and > their semantics closely follow directories. The desire to > have recall of all of some mappings resembles directory > delegations and notifications represent a model that device > mappings could use. Thus it seems possible use directory > operations for manipulating device mappings. However doing > this would not save any operations because a "PUTDEVFH" > operation (with a layouttype argument) would have to > be added to allow READDIR to replace GETDEVICELIST > (and then we have to figure out how to have directory > entries represent device ID to device address mappingfs -- > presumably with attributes). And an operation to map a > device ID to an address would still be needed, unless we > make device IDs file handles (a 4 byte length followed by > a 4 byte handle). > > Regardless, the complexity of simulating a directory, > when there aren't POSIX APIs that want directory semantics > (e.g. per entry cookies) for device mappings might not be > worth it, nor is the timing great for doing this scale > of change. It also dubious if any of the READDIR code > would be shared for real directories and device maps. > > An alternative is proposed below. > > GETDEVICEINFO or GETDEVICELIST each return a device > stateid that represents a recallable, read-only hold on > the mappings. Recall of the device stateid will remove the > mappings. Lease expiration can remove the mappings. The > mappings stay in force until recall of the stateid or > lease expiration. GETDEVICEINFO and GETDEVICELIST change > the current file handle so the CB_RECALL can be used to > recall the device stateid. All layouts using the device IDs > remain in force, but the server MUST fence the client > from accessing the affected data servers until > the device IDs are re-mapped (via GETDEVICEINFO or > GETDEVICELIST). > > There is at most one device stateid per { client ID, > layout type } pair. > > CB_NOTIFY can modify, delete, or add mappings, > if GETDEVICEINFO and GETDEVICELIST request notifications and > if the server supports device notifications. > The notifications available are: > > NOTIFY4_DELETE_DEVICE_ID > Deletes all mappings using the specified device ID. > The server MUST stop using the device ID. Any > layouts remain in force, but aren't useful until > new mappings are available. The server fences the > client from the affected data server until all > layouts with the device ID are returned, or the > client obtains new mappings. The server provides > a hint as to whether new mappings will arrive and > if so how long. > > NOTIFY4_ADD_DEVICE_ID > Adds a device ID to address mapping. This is > for a device ID the that was not returned in a > previous series GETDEVICELIST calls (where the > series ended in gdlr_eof == TRUE). The client > calls GETDEVICEINFO or GETDEVICELIST to determine > the mappings for the new device ID. > > NOTIFY4_CHANGE_DEVICE_ID > The client call GETDEVICEINFO or GETDEVICELIST > to get updated device addresses for the device > ID. Layouts remain in force. The client is fenced > from any devices that were in the old address list, > but not the new address list. > > SEQUENCE will have a status flag added to indicate that > the device mappings have been partially deleted, fully > deleted (e.g. recall or lease expiry), changed, or added > to. The partially deleted flag stays on until the client > responds to any and all _DELETE notifications, or it does > a GETDEVICELIST. The fully deleted flag stays on until > DELEGRETURN returns the device stateid. The changed and > added flags stay on until a GETDEVICELIST or GETDEVICEINFO > gets the affected mappings. > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 30 13:20:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYuc-0003rM-B4; Mon, 30 Jul 2007 13:20:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYub-0003qe-Tj for nfsv4@ietf.org; Mon, 30 Jul 2007 13:20:05 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFYuQ-0003Vh-24 for nfsv4@ietf.org; Mon, 30 Jul 2007 13:20:05 -0400 X-IronPort-AV: E=Sophos;i="4.19,199,1183359600"; d="scan'208";a="87484507" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 30 Jul 2007 10:19:53 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6UHJreq019430; Mon, 30 Jul 2007 10:19:53 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 10:19:53 -0700 Received: from exsvl03.hq.netapp.com ([10.56.8.64]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 10:19:52 -0700 Received: from [10.34.24.132] ([10.34.24.132]) by exsvl03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 10:19:52 -0700 Message-ID: <46AE1DB7.60101@netapp.com> Date: Mon, 30 Jul 2007 10:19:51 -0700 From: Garth Goodson User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: "J. Bruce Fields" References: <20070730170702.GA2386@fieldses.org> In-Reply-To: <20070730170702.GA2386@fieldses.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2007 17:19:52.0591 (UTC) FILETIME=[D75159F0:01C7D2CD] X-Spam-Score: -4.0 (----) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Garth Goodson , nfsv4@ietf.org, eveuh@umich.edu Subject: [nfsv4] Re: 4.1 wireshark patches X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I believe the patches were uploaded to the address listed below by Benny. I'm no longer maintaining these patches. On Tue, Jun 05, 2007 at 07:00:48PM +0300, Benny Halevy wrote: > > Thanks! > > > > I've copied these files onto http://wiki.linux-nfs.org/wiki/index.php/Wireshark_Patches > > I didn't see how to upload the files as attachments onto the wiki... > > clue anyone? -Garth J. Bruce Fields wrote: > At some point you sent out a wireshark patch that added some nfsv4.1 > parsing, but looking around I couldn't find it. Would you mind > resending? > > Also, are you keeping those up to date, or do you know anyone else that > is? We've got a student looking into it, but it'll take her some time > to get up to speed, and we don't want to duplicate work. > > --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 30 17:12:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFcXi-0003zG-JT; Mon, 30 Jul 2007 17:12:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFcXh-0003wp-7y for nfsv4@ietf.org; Mon, 30 Jul 2007 17:12:41 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFcXf-0001AC-Sr for nfsv4@ietf.org; Mon, 30 Jul 2007 17:12:41 -0400 Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6ULCdWb006182 for ; Mon, 30 Jul 2007 21:12:39 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JM000201FF7VF00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 30 Jul 2007 15:12:39 -0600 (MDT) Received: from [70.14.251.62] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JM000MMPG8ZXE30@mail-amer.sun.com> for nfsv4@ietf.org; Mon, 30 Jul 2007 15:12:38 -0600 (MDT) Date: Mon, 30 Jul 2007 16:11:20 -0500 From: Spencer Shepler Subject: Re: [nfsv4] Layout stateids In-reply-to: <46ACCB00.5000905@panasas.com> To: nfsv4@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <72967EA1-AC36-4C15-ADE5-06F05B55D3A4@Sun.COM> <46ACCB00.5000905@panasas.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 29, 2007, at 12:14 PM, Benny Halevy wrote: > Spencer Shepler wrote: >> >> Working from Mike's stateids in layouts proposal, the ensuing thread >> of discussion and then the continued discussion during Monday's WG >> meeting, I offer the following proposal for stateids in layouts. >> >> The main purpose of this change is to ensure the client has a layout >> that is correctly derived from a valid OPEN of the file and to tie >> the >> layout to the lease held by the client. Of secondary concern is to >> increase the potential for parallelism between LAYOUTGET and >> LAYOUTRETURN, and to ease the data server's validation of layouts. >> >> Some assumptions/observations: >> >> Layouts are similar to byte range file locks; they are range based, >> can merge, can be split. Thus, the ordering of LAYOUTGET and >> LAYOUTRETURN matters greatly to the shared view the client and server >> has for layout ranges. The addition of stateids for LAYOUTGET and >> LAYOUTRETURN will allow for the ordering of execution at the >> server to >> be communicated to the client via the stateid4.seqid field just like >> the OPEN and LOCK sequencing is communciated. Note that the iomode >> provide two distinct sets of layout ranges -- an upgrade path from >> the >> READ iomode to the READ/WRITE iomode does NOT exist. >> >> Layouts are similar to delegations in that the stateid is valid >> beyond >> the life of the OPEN stateid (file can be closed and the client can >> continue holding a valid layout stateid). The other similarity with >> delegations is that layout stateids are associated with the >> filehandle/client pairing (NOT filehandle/"layout owner" like byte >> range file locks). >> >> The presence of layout stateids does not remove the utility of >> Sessions' slot referencing mechanism on CB_SEQUENCE. This was the >> conclusion of the discussion during the NFSv4 WG meeting on Monday >> (Brent Welch may send an email with a discussion of the general >> issues >> of sequencing and race conditions). >> >> Proposal: >> >> LAYOUTGET will take a stateid and return one in the results. >> >> For the first LAYOUTGET, the client MUST use a valid stateid as >> returned by OPEN, OPEN_DOWNGRADE, LOCK, LOCKU, WANT_DELEGATION (open, >> lock, or delegation stateids). For subsequent LAYOUTGETs, the client >> will provide a layout stateid. >> >> The client MUST hold a valid layout for I/O to any storage >> device type. >> >> The use of special stateids for data server I/O is not allowed. >> >> Layout stateids follow the sequencing and use rules of all other >> stateid types. >> >> Same stateid4.other value is returned for all layouts on the file >> (e.g. multiple LAYOUTGETs and LAYOUTRETURNs to the same file). > > I'd restrict that per layout_type since the encapsulated layout state > per layout_type is independent and LAYOUT{GET,COMMIT,RETURN} as well > as CB_LAYOUTRECALL carry the layout_type (CB_RECALL_ANY doesn't but > it will not a have layout stateid either). This is fine with me. Seems like we have consensus with the minor adaptation that Dave Noveck provided. >> >> LAYOUTRETURN will take a layout stateid and return a stateid. If the >> server has recalled a CB_LAYOUTRECALL and the client is returning a >> layout as a result, the client will also provide the layout stateid >> specified in the CB_LAYOUTRECALL. >> >> LAYOUTCOMMIT will take a layout stateid; it will not return a >> stateid. >> >> Layout stateids persist across CLOSE and DELEGRETURN. >> >> As noted above, for the NFSv4.1 layout type, READ and WRITE to a data >> server will continue to require an open, lock, or delegation stateid. >> The data server SHOULD be able to map these stateids to the granted >> layout to make sure the client has a layout, but in any case the data >> server MUST reject I/Os to files that do not have layouts. >> >> As with other state, layout stateids might become invalid >> when the lease expires. >> >> Spencer > > Thanks for incorporating the feedback for Mike's proposal into this > one. > > To get that into the spec I think we need to provide more details > about > the following use cases (to start with): > > When should the server increase the sequence part of the stated? > How strict do we want to be in the spec about this? > > What layout stateid should the client use on subsequent LAYOUTGET > and LAYOUTRETURN operations? > > Can the client send multiple such operations in parallel? > If so, what values should it use for the stateid? > Currently we don't allow the client to send LAYOUTGET(s) > concurrently with LAYOUTRETURN(s) but we do allow the > client to send multiple concurrent LAYOUTGETs or > multiple concurrent LAYOUTRETURNs since the order > of execution between these, respectively, should not > matter. Sending LAYOUTGET(s) in parallel to LAYOUTRETURN(s) > may require strict ordering between the two. Can the client > imply the order using the sent layout stateid by incrementing > the stateid4.seqid? What should the server do if it gets > the operations out of order? > So, the short statement I had in the above: >> Layout stateids follow the sequencing and use rules of all other >> stateid types. Was an reference to the way file locking and open processing is done at the server with respect to parallelism and sequencing choices by the client. We had a thread of discussion earlier this month about how the server was required to update the stateid4.seqid on each operation. In this case, LAYOUTGET and LAYOUTRETURN in that it signifies a change in the layout "state" and if the client is sending these operations in parallel it can use the stateid4.seqid as a method of sorting the execution at the server. We also came to the conclusion that if the client doesn't care about the sequence in which is sends the operations, it will set the stateid4.seqid value to 0(zero) and the server will ignore the value in essence (first come first served). If the client prefers to sequence the operations, then it will leave the stateid4.seqid value present in the request's stateid and the server will do the "old stateid" checking that is present in NFSv4.0. Again, modeling it after file locking (ranges and sequencing) we should have a model that is common enough between the two to be well understood. As for callback processing, I intended that the server provide the stateid4 (both seqid and other) at the time it did the callback. The client can then look at the stateid4.seqid to determine if the LAYOUTGET/LAYOUTRETURN was executed before or after the callback was instantiated by the server. The client is still obligated to do a LAYOUTRETURN with the callback stateid4 even if it raced with the server on a LAYOUTRETURN for the same range. This is done to be very clear that the client acknowledged and processed fully the callback request. If the server receives LAYOUTGETs for the range in callback, it can refuse to provide them and the client will eventually understand that the range has been under the callback request. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 30 17:22:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFchc-0001Zb-S5; Mon, 30 Jul 2007 17:22:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFchb-0001ZN-Ch for nfsv4@ietf.org; Mon, 30 Jul 2007 17:22:55 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFcha-0001xy-43 for nfsv4@ietf.org; Mon, 30 Jul 2007 17:22:55 -0400 X-IronPort-AV: E=Sophos;i="4.19,200,1183359600"; d="scan'208";a="87556622" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Jul 2007 14:22:40 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6ULMcaM006749; Mon, 30 Jul 2007 14:22:39 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 14:22:39 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 14:22:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] Layout stateids Date: Mon, 30 Jul 2007 17:22:37 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Layout stateids Thread-Index: AcfS7sFVD7Awz5w6Tt+Lfoa1hpuTnQAAGSwA From: "Noveck, Dave" To: "Spencer Shepler" , X-OriginalArrivalTime: 30 Jul 2007 21:22:38.0544 (UTC) FILETIME=[C14D6500:01C7D2EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org [specific details of model not copied] > Again, modeling it after file locking (ranges and sequencing) we > should have a model that is common enough between the two to > be well understood. In fact, with the new state manegement chapter, this is only=20 described once in that general chapter and it applies to all types of stateids. > As for callback processing, I intended that the server provide > the stateid4 (both seqid and other) at the time it did the callback. > The client can then look at the stateid4.seqid to determine if the > LAYOUTGET/LAYOUTRETURN was executed before or after the callback > was instantiated by the server. The client is still obligated to > do a LAYOUTRETURN with the callback stateid4 even if it raced > with the server on a LAYOUTRETURN for the same range. This is > done to be very clear that the client acknowledged and processed > fully the callback request. This currently isn't stated in the state management chapter. If=20 it is a general requirement for calbacks, as opposed to something layout-specific, it should be mentioned in the state management=20 chapter. -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Monday, July 30, 2007 5:11 PM To: nfsv4@ietf.org Subject: Re: [nfsv4] Layout stateids On Jul 29, 2007, at 12:14 PM, Benny Halevy wrote: > Spencer Shepler wrote: >> >> Working from Mike's stateids in layouts proposal, the ensuing thread >> of discussion and then the continued discussion during Monday's WG >> meeting, I offer the following proposal for stateids in layouts. >> >> The main purpose of this change is to ensure the client has a layout >> that is correctly derived from a valid OPEN of the file and to tie =20 >> the >> layout to the lease held by the client. Of secondary concern is to >> increase the potential for parallelism between LAYOUTGET and >> LAYOUTRETURN, and to ease the data server's validation of layouts. >> >> Some assumptions/observations: >> >> Layouts are similar to byte range file locks; they are range based, >> can merge, can be split. Thus, the ordering of LAYOUTGET and >> LAYOUTRETURN matters greatly to the shared view the client and server >> has for layout ranges. The addition of stateids for LAYOUTGET and >> LAYOUTRETURN will allow for the ordering of execution at the =20 >> server to >> be communicated to the client via the stateid4.seqid field just like >> the OPEN and LOCK sequencing is communciated. Note that the iomode >> provide two distinct sets of layout ranges -- an upgrade path from =20 >> the >> READ iomode to the READ/WRITE iomode does NOT exist. >> >> Layouts are similar to delegations in that the stateid is valid =20 >> beyond >> the life of the OPEN stateid (file can be closed and the client can >> continue holding a valid layout stateid). The other similarity with >> delegations is that layout stateids are associated with the >> filehandle/client pairing (NOT filehandle/"layout owner" like byte >> range file locks). >> =09 >> The presence of layout stateids does not remove the utility of >> Sessions' slot referencing mechanism on CB_SEQUENCE. This was the >> conclusion of the discussion during the NFSv4 WG meeting on Monday >> (Brent Welch may send an email with a discussion of the general =20 >> issues >> of sequencing and race conditions). >> >> Proposal: >> >> LAYOUTGET will take a stateid and return one in the results. >> >> For the first LAYOUTGET, the client MUST use a valid stateid as >> returned by OPEN, OPEN_DOWNGRADE, LOCK, LOCKU, WANT_DELEGATION (open, >> lock, or delegation stateids). For subsequent LAYOUTGETs, the client >> will provide a layout stateid. >> >> The client MUST hold a valid layout for I/O to any storage >> device type. >> >> The use of special stateids for data server I/O is not allowed. >> >> Layout stateids follow the sequencing and use rules of all other >> stateid types. >> >> Same stateid4.other value is returned for all layouts on the file >> (e.g. multiple LAYOUTGETs and LAYOUTRETURNs to the same file). > > I'd restrict that per layout_type since the encapsulated layout state > per layout_type is independent and LAYOUT{GET,COMMIT,RETURN} as well > as CB_LAYOUTRECALL carry the layout_type (CB_RECALL_ANY doesn't but > it will not a have layout stateid either). This is fine with me. Seems like we have consensus with the minor adaptation that Dave Noveck provided. >> >> LAYOUTRETURN will take a layout stateid and return a stateid. If the >> server has recalled a CB_LAYOUTRECALL and the client is returning a >> layout as a result, the client will also provide the layout stateid >> specified in the CB_LAYOUTRECALL. >> >> LAYOUTCOMMIT will take a layout stateid; it will not return a =20 >> stateid. >> >> Layout stateids persist across CLOSE and DELEGRETURN. >> >> As noted above, for the NFSv4.1 layout type, READ and WRITE to a data >> server will continue to require an open, lock, or delegation stateid. >> The data server SHOULD be able to map these stateids to the granted >> layout to make sure the client has a layout, but in any case the data >> server MUST reject I/Os to files that do not have layouts. >> >> As with other state, layout stateids might become invalid >> when the lease expires. >> >> Spencer > > Thanks for incorporating the feedback for Mike's proposal into this =20 > one. > > To get that into the spec I think we need to provide more details =20 > about > the following use cases (to start with): > > When should the server increase the sequence part of the stated? > How strict do we want to be in the spec about this? > > What layout stateid should the client use on subsequent LAYOUTGET > and LAYOUTRETURN operations? > > Can the client send multiple such operations in parallel? > If so, what values should it use for the stateid? > Currently we don't allow the client to send LAYOUTGET(s) > concurrently with LAYOUTRETURN(s) but we do allow the > client to send multiple concurrent LAYOUTGETs or > multiple concurrent LAYOUTRETURNs since the order > of execution between these, respectively, should not > matter. Sending LAYOUTGET(s) in parallel to LAYOUTRETURN(s) > may require strict ordering between the two. Can the client > imply the order using the sent layout stateid by incrementing > the stateid4.seqid? What should the server do if it gets > the operations out of order? > So, the short statement I had in the above: >> Layout stateids follow the sequencing and use rules of all other >> stateid types. Was an reference to the way file locking and open processing is done at the server with respect to parallelism and sequencing choices by the client. We had a thread of discussion earlier this month about how the server was required to update the stateid4.seqid on each operation. In this case, LAYOUTGET and LAYOUTRETURN in that it signifies a change in the layout "state" and if the client is sending these operations in parallel it can use the stateid4.seqid as a method of sorting the execution at the server. We also came to the conclusion that if the client doesn't care about the sequence in which is sends the operations, it will set the stateid4.seqid value to 0(zero) and the server will ignore the value in essence (first come first served). If the client prefers to sequence the operations, then it will leave the stateid4.seqid value present in the request's stateid and the server will do the "old stateid" checking that is present in NFSv4.0. Again, modeling it after file locking (ranges and sequencing) we should have a model that is common enough between the two to be well understood. As for callback processing, I intended that the server provide the stateid4 (both seqid and other) at the time it did the callback. The client can then look at the stateid4.seqid to determine if the LAYOUTGET/LAYOUTRETURN was executed before or after the callback was instantiated by the server. The client is still obligated to do a LAYOUTRETURN with the callback stateid4 even if it raced with the server on a LAYOUTRETURN for the same range. This is done to be very clear that the client acknowledged and processed fully the callback request. If the server receives LAYOUTGETs for the range in callback, it can refuse to provide them and the client will eventually understand that the range has been under the callback request. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 30 17:26:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFclI-0003Ad-4Q; Mon, 30 Jul 2007 17:26:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFclG-0003AX-Pi for nfsv4@ietf.org; Mon, 30 Jul 2007 17:26:42 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFclF-0001ja-Ee for nfsv4@ietf.org; Mon, 30 Jul 2007 17:26:42 -0400 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6ULQeNH013148 for ; Mon, 30 Jul 2007 21:26:41 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JM000M01GTXK500@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 30 Jul 2007 15:26:40 -0600 (MDT) Received: from [70.3.185.17] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JM000AS8GWD7H30@mail-amer.sun.com>; Mon, 30 Jul 2007 15:26:40 -0600 (MDT) Date: Mon, 30 Jul 2007 16:25:22 -0500 From: Spencer Shepler Subject: Re: [nfsv4] Layout stateids In-reply-to: To: "Noveck, Dave" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 30, 2007, at 4:22 PM, Noveck, Dave wrote: > [specific details of model not copied] > >> Again, modeling it after file locking (ranges and sequencing) we >> should have a model that is common enough between the two to >> be well understood. > > In fact, with the new state manegement chapter, this is only > described once in that general chapter and it applies to all > types of stateids. > >> As for callback processing, I intended that the server provide >> the stateid4 (both seqid and other) at the time it did the callback. >> The client can then look at the stateid4.seqid to determine if the >> LAYOUTGET/LAYOUTRETURN was executed before or after the callback >> was instantiated by the server. The client is still obligated to >> do a LAYOUTRETURN with the callback stateid4 even if it raced >> with the server on a LAYOUTRETURN for the same range. This is >> done to be very clear that the client acknowledged and processed >> fully the callback request. > > This currently isn't stated in the state management chapter. If > it is a general requirement for calbacks, as opposed to something > layout-specific, it should be mentioned in the state management > chapter. It is layout specific in my view. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Jul 30 18:40:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdug-0001Xa-Jx; Mon, 30 Jul 2007 18:40:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFduf-0001XV-Lw for nfsv4@ietf.org; Mon, 30 Jul 2007 18:40:29 -0400 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFduf-0004oE-Cc for nfsv4@ietf.org; Mon, 30 Jul 2007 18:40:29 -0400 Received: from bfields by fieldses.org with local (Exim 4.67) (envelope-from ) id 1IFdue-000818-7C; Mon, 30 Jul 2007 18:40:28 -0400 Date: Mon, 30 Jul 2007 18:40:28 -0400 To: Garth Goodson Message-ID: <20070730224028.GN2386@fieldses.org> References: <20070730170702.GA2386@fieldses.org> <46AE1DB7.60101@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46AE1DB7.60101@netapp.com> User-Agent: Mutt/1.5.16 (2007-06-11) From: "J. Bruce Fields" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Garth Goodson , nfsv4@ietf.org, eveuh@umich.edu Subject: [nfsv4] Re: 4.1 wireshark patches X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Mon, Jul 30, 2007 at 10:19:51AM -0700, Garth Goodson wrote: > I believe the patches were uploaded to the address listed below by Benny. > I'm no longer maintaining these patches. OK, thanks. (Anyone else out there touched them recently?) --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 02:00:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFkmd-0001Ev-7U; Tue, 31 Jul 2007 02:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFkmc-0001El-0x for nfsv4@ietf.org; Tue, 31 Jul 2007 02:00:38 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFkma-0001Ce-Jq for nfsv4@ietf.org; Tue, 31 Jul 2007 02:00:37 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6V60Stf032243; Tue, 31 Jul 2007 02:00:28 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 31 Jul 2007 02:00:28 -0400 Received: from [192.168.0.140] ([172.17.28.146]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 02:00:26 -0400 Message-ID: <46AECFF9.2030509@panasas.com> Date: Tue, 31 Jul 2007 09:00:25 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: "J. Bruce Fields" Subject: Re: [nfsv4] Re: 4.1 wireshark patches References: <20070730170702.GA2386@fieldses.org> <46AE1DB7.60101@netapp.com> <20070730224028.GN2386@fieldses.org> In-Reply-To: <20070730224028.GN2386@fieldses.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 06:00:27.0113 (UTC) FILETIME=[179CCD90:01C7D338] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Garth Goodson , Garth Goodson , nfsv4@ietf.org, eveuh@umich.edu X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I posted the latest stuff we had at the Austin bakeathon on http://wiki.linux-nfs.org/wiki/index.php/Wireshark_Patches Nobody really maintains these and like I proposed before, it would be great if someone (CITI? :) will host wireshark git tree in which we can track our development and ship it upstream when ready. Benny J. Bruce Fields wrote: > On Mon, Jul 30, 2007 at 10:19:51AM -0700, Garth Goodson wrote: >> I believe the patches were uploaded to the address listed below by Benny. >> I'm no longer maintaining these patches. > > OK, thanks. > > (Anyone else out there touched them recently?) > > --b. > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 02:46:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlUb-0000lH-Fa; Tue, 31 Jul 2007 02:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlUa-0000lB-8f for nfsv4@ietf.org; Tue, 31 Jul 2007 02:46:04 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFlUZ-0002MK-Qq for nfsv4@ietf.org; Tue, 31 Jul 2007 02:46:04 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6V6k2xj000661; Tue, 31 Jul 2007 02:46:02 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 31 Jul 2007 02:46:02 -0400 Received: from [192.168.0.140] ([172.17.28.146]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 02:46:02 -0400 Message-ID: <46AEDAA8.9030106@panasas.com> Date: Tue, 31 Jul 2007 09:46:00 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Black_David@emc.com Subject: Re: [nfsv4] Layout stateids References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 06:46:02.0306 (UTC) FILETIME=[75EA2220:01C7D33E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Dave.Noveck@netapp.com, nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Black_David@emc.com wrote: > Dave, > >>> I agree with Benny, although I'd be tempted to make use of different >>> layout types on the same file at the same time a "MUST NOT" on the >>> grounds that the opportunity for confusion probably outweighs the >>> benefits of this sort of cleverness. >> If we are talking about for the same client at the same time, I would >> agree. >> >> I think there may in the future be reasonable use cases for the case >> where we have different layout type for the same for different > clients. >> Suppose you have a layout type that is an improvement-extension of an >> existing one. You very well might want the ability to provide the new >> type to clients that support it while providing the old to those who >> don't. > > We are talking about "for the same client at the same time" as layout > stateids are necessarily per-client. Support of different layout types > for different clients at the same time on the same file is up to the > server - it has the discretion to "just say no" to a layout request > which would create a combination that the server doesn't want to have > to deal with. Well, the server can "just say no" to a client that has an outstanding layout of one type and is asking for another type, if the server wishes to do so. Regardless if we disallow this in the protocol or not, I think we better have a specific error to represent this condition. This error would tell the client it needs to completely return the layout it currently holds before asking for a new one with a different layout type. Something in the lines of NFS4ERR_LAYOUTTYPE_CONFLICT. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 03:10:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlri-0005mE-Cx; Tue, 31 Jul 2007 03:09:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlrh-0005m8-Ie for nfsv4@ietf.org; Tue, 31 Jul 2007 03:09:57 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFlrh-00041q-62 for nfsv4@ietf.org; Tue, 31 Jul 2007 03:09:57 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6V79ujl001135; Tue, 31 Jul 2007 03:09:56 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 31 Jul 2007 03:09:56 -0400 Received: from [192.168.0.140] ([172.17.28.146]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 03:09:56 -0400 Message-ID: <46AEE042.1040603@panasas.com> Date: Tue, 31 Jul 2007 10:09:54 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: [nfsv4] Layout stateids References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 07:09:56.0318 (UTC) FILETIME=[CCA6FFE0:01C7D341] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Noveck, Dave" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Spencer Shepler wrote: > On Jul 30, 2007, at 4:22 PM, Noveck, Dave wrote: > >> [specific details of model not copied] >> >>> Again, modeling it after file locking (ranges and sequencing) we >>> should have a model that is common enough between the two to >>> be well understood. >> In fact, with the new state manegement chapter, this is only >> described once in that general chapter and it applies to all >> types of stateids. Yup. This should work. >> >>> As for callback processing, I intended that the server provide >>> the stateid4 (both seqid and other) at the time it did the callback. >>> The client can then look at the stateid4.seqid to determine if the >>> LAYOUTGET/LAYOUTRETURN was executed before or after the callback >>> was instantiated by the server. The client is still obligated to >>> do a LAYOUTRETURN with the callback stateid4 even if it raced >>> with the server on a LAYOUTRETURN for the same range. This is >>> done to be very clear that the client acknowledged and processed >>> fully the callback request. I like that. One semantic nit though: alternatively, if a previous LAYOUTRETURN returned the whole recalled range and the client waits for it to complete before replying to the callback, it can (and should) return a NFS4ERR_NOMATCHING_LAYOUT error to the callback. >> This currently isn't stated in the state management chapter. If >> it is a general requirement for calbacks, as opposed to something >> layout-specific, it should be mentioned in the state management >> chapter. > > It is layout specific in my view. > > Spencer > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 04:55:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFnVP-0003P6-LP; Tue, 31 Jul 2007 04:55:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFnVN-0003Ow-LH for nfsv4@ietf.org; Tue, 31 Jul 2007 04:55:01 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFnVM-0007Xw-Uw for nfsv4@ietf.org; Tue, 31 Jul 2007 04:55:01 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6V8smBG003870; Tue, 31 Jul 2007 04:54:48 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 31 Jul 2007 04:54:48 -0400 Received: from [192.168.0.140] ([172.17.28.146]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 04:54:47 -0400 Message-ID: <46AEF8D6.5030602@panasas.com> Date: Tue, 31 Jul 2007 11:54:46 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Garth Goodson Subject: Re: [nfsv4] Device stateids References: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> <46AE1D05.3060505@netapp.com> In-Reply-To: <46AE1D05.3060505@netapp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 08:54:47.0829 (UTC) FILETIME=[72AF6450:01C7D350] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: Spencer Shepler , nfsv4@ietf.org, Marc Eshel X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Garth Goodson wrote: > > Spencer Shepler wrote: >> We seem to have consensus on Mike's device stateid proposal >> and I will work to integrate the changes into the next draft. >> If there are any tweaks needed, please speak up. >> >> I have included the original text for reference. >> >> Spencer >> > > I think one of the areas still under debate was about the ability to > recall and return multiple devices at once and I want to make sure > everyone is aware of the implication of this proposal. > > There was discussion about breaking the deviceID in two sections > (major,minor) such that a recall could recall all IDs associated with a > major num. I don't see this in the proposal below. > > So my question is, is it possible to recall all device IDs for a given > FSID in a single call, and return in a single call (like it is in the > current text)? If not, is everyone ok with this. For us it's sub-optimal but we can live with this restriction. > > -Garth > > >> >> >> Recallable Device ID to Device Address Mappings >> ----------------------------------------------- >> >> Proposal: >> >> Make each MDS server's device ID to device adddress >> mappings a single recallable object. >> >> Rationale: >> >> The specification is unclear as to when device ID to device >> address mappings can change. There are attempts single >> tie these to layouts and/or leases. They should be tied to >> leases, but layouts are separate, albeit, related concept, >> and besides which, the layout-type independent part of a >> layout doesn't have a device ID. >> >> More Details of Proposal: >> >> I have previously observed that device mappings and >> their semantics closely follow directories. The desire to >> have recall of all of some mappings resembles directory >> delegations and notifications represent a model that device >> mappings could use. Thus it seems possible use directory >> operations for manipulating device mappings. However doing >> this would not save any operations because a "PUTDEVFH" >> operation (with a layouttype argument) would have to >> be added to allow READDIR to replace GETDEVICELIST >> (and then we have to figure out how to have directory >> entries represent device ID to device address mappingfs -- >> presumably with attributes). And an operation to map a >> device ID to an address would still be needed, unless we >> make device IDs file handles (a 4 byte length followed by >> a 4 byte handle). >> >> Regardless, the complexity of simulating a directory, >> when there aren't POSIX APIs that want directory semantics >> (e.g. per entry cookies) for device mappings might not be >> worth it, nor is the timing great for doing this scale >> of change. It also dubious if any of the READDIR code >> would be shared for real directories and device maps. >> >> An alternative is proposed below. >> >> GETDEVICEINFO or GETDEVICELIST each return a device >> stateid that represents a recallable, read-only hold on >> the mappings. Recall of the device stateid will remove the >> mappings. Lease expiration can remove the mappings. The >> mappings stay in force until recall of the stateid or >> lease expiration. GETDEVICEINFO and GETDEVICELIST change >> the current file handle so the CB_RECALL can be used to >> recall the device stateid. All layouts using the device IDs >> remain in force, but the server MUST fence the client >> from accessing the affected data servers until >> the device IDs are re-mapped (via GETDEVICEINFO or >> GETDEVICELIST). >> >> There is at most one device stateid per { client ID, >> layout type } pair. >> >> CB_NOTIFY can modify, delete, or add mappings, >> if GETDEVICEINFO and GETDEVICELIST request notifications and >> if the server supports device notifications. >> The notifications available are: >> >> NOTIFY4_DELETE_DEVICE_ID >> Deletes all mappings using the specified device ID. >> The server MUST stop using the device ID. Any >> layouts remain in force, but aren't useful until >> new mappings are available. The server fences the >> client from the affected data server until all >> layouts with the device ID are returned, or the >> client obtains new mappings. The server provides >> a hint as to whether new mappings will arrive and >> if so how long. >> >> NOTIFY4_ADD_DEVICE_ID >> Adds a device ID to address mapping. This is >> for a device ID the that was not returned in a >> previous series GETDEVICELIST calls (where the >> series ended in gdlr_eof == TRUE). The client >> calls GETDEVICEINFO or GETDEVICELIST to determine >> the mappings for the new device ID. >> >> NOTIFY4_CHANGE_DEVICE_ID >> The client call GETDEVICEINFO or GETDEVICELIST >> to get updated device addresses for the device >> ID. Layouts remain in force. The client is fenced >> from any devices that were in the old address list, >> but not the new address list. >> >> SEQUENCE will have a status flag added to indicate that >> the device mappings have been partially deleted, fully >> deleted (e.g. recall or lease expiry), changed, or added >> to. The partially deleted flag stays on until the client >> responds to any and all _DELETE notifications, or it does >> a GETDEVICELIST. The fully deleted flag stays on until >> DELEGRETURN returns the device stateid. The changed and >> added flags stay on until a GETDEVICELIST or GETDEVICEINFO >> gets the affected mappings. >> >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 10:41:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFsuP-00088y-4w; Tue, 31 Jul 2007 10:41:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFsuM-00088l-BY for nfsv4@ietf.org; Tue, 31 Jul 2007 10:41:11 -0400 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFsuL-00042b-Sn for nfsv4@ietf.org; Tue, 31 Jul 2007 10:41:10 -0400 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6VEf6J6016970 for ; Tue, 31 Jul 2007 10:41:06 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6VEf6Oj540794 for ; Tue, 31 Jul 2007 10:41:06 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6VEf6Ta007270 for ; Tue, 31 Jul 2007 10:41:06 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6VEf63P007264; Tue, 31 Jul 2007 10:41:06 -0400 In-Reply-To: <46AEF8D6.5030602@panasas.com> To: Benny Halevy MIME-Version: 1.0 Subject: Re: [nfsv4] Device stateids X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Marc Eshel Date: Tue, 31 Jul 2007 07:40:58 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V80_M5_05202007|May 20, 2007) at 07/31/2007 10:41:08, Serialize complete at 07/31/2007 10:41:08 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Garth Goodson , Spencer Shepler , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Benny Halevy wrote on 07/31/2007 01:54:46 AM: > Garth Goodson wrote: > > > > Spencer Shepler wrote: > >> We seem to have consensus on Mike's device stateid proposal > >> and I will work to integrate the changes into the next draft. > >> If there are any tweaks needed, please speak up. > >> > >> I have included the original text for reference. > >> > >> Spencer > >> > > > > I think one of the areas still under debate was about the ability to > > recall and return multiple devices at once and I want to make sure > > everyone is aware of the implication of this proposal. > > > > There was discussion about breaking the deviceID in two sections > > (major,minor) such that a recall could recall all IDs associated with a > > major num. I don't see this in the proposal below. > > > > So my question is, is it possible to recall all device IDs for a given > > FSID in a single call, and return in a single call (like it is in the > > current text)? If not, is everyone ok with this. > > For us it's sub-optimal but we can live with this restriction. > I missed the answer to Garth question. Did you loose the ability to recall all device IDs for a given FSID? Marc. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 10:55:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFt8D-0007ee-MZ; Tue, 31 Jul 2007 10:55:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFt8B-0007eN-JD for nfsv4@ietf.org; Tue, 31 Jul 2007 10:55:27 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFt8A-0004Q6-QQ for nfsv4@ietf.org; Tue, 31 Jul 2007 10:55:27 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6VEtFvq016256; Tue, 31 Jul 2007 10:55:15 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 31 Jul 2007 10:55:15 -0400 Received: from [192.168.0.140] ([172.17.28.146]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:55:14 -0400 Message-ID: <46AF4D50.2000104@panasas.com> Date: Tue, 31 Jul 2007 17:55:12 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Garth Goodson , Spencer Shepler Subject: Re: [nfsv4] Device stateids References: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> <46AE1D05.3060505@netapp.com> In-Reply-To: <46AE1D05.3060505@netapp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 14:55:14.0341 (UTC) FILETIME=[CD173D50:01C7D382] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: nfsv4@ietf.org, Marc Eshel X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Apparently, one more thing the new proposal loses is the layout_type granularity. CB_NOTIFY will delete all device mappings for all layout types, even if the MDS is serving heterogeneous file systems exported over different sets of devices and layout types. The idea behind my proposal for composite device ID is to be able to group devices into "device sets" that you can recall and return. The server can then map the device sets according to its architecture and topology so one server can have a single device set for all devices, the other can have one device set per filesystem, and a third could map several filesystems onto one device set as they they may share the same devices. Benny Garth Goodson wrote: > > Spencer Shepler wrote: >> We seem to have consensus on Mike's device stateid proposal >> and I will work to integrate the changes into the next draft. >> If there are any tweaks needed, please speak up. >> >> I have included the original text for reference. >> >> Spencer >> > > I think one of the areas still under debate was about the ability to > recall and return multiple devices at once and I want to make sure > everyone is aware of the implication of this proposal. > > There was discussion about breaking the deviceID in two sections > (major,minor) such that a recall could recall all IDs associated with a > major num. I don't see this in the proposal below. > > So my question is, is it possible to recall all device IDs for a given > FSID in a single call, and return in a single call (like it is in the > current text)? If not, is everyone ok with this. > > -Garth > > >> >> >> Recallable Device ID to Device Address Mappings >> ----------------------------------------------- >> >> Proposal: >> >> Make each MDS server's device ID to device adddress >> mappings a single recallable object. >> >> Rationale: >> >> The specification is unclear as to when device ID to device >> address mappings can change. There are attempts single >> tie these to layouts and/or leases. They should be tied to >> leases, but layouts are separate, albeit, related concept, >> and besides which, the layout-type independent part of a >> layout doesn't have a device ID. >> >> More Details of Proposal: >> >> I have previously observed that device mappings and >> their semantics closely follow directories. The desire to >> have recall of all of some mappings resembles directory >> delegations and notifications represent a model that device >> mappings could use. Thus it seems possible use directory >> operations for manipulating device mappings. However doing >> this would not save any operations because a "PUTDEVFH" >> operation (with a layouttype argument) would have to >> be added to allow READDIR to replace GETDEVICELIST >> (and then we have to figure out how to have directory >> entries represent device ID to device address mappingfs -- >> presumably with attributes). And an operation to map a >> device ID to an address would still be needed, unless we >> make device IDs file handles (a 4 byte length followed by >> a 4 byte handle). >> >> Regardless, the complexity of simulating a directory, >> when there aren't POSIX APIs that want directory semantics >> (e.g. per entry cookies) for device mappings might not be >> worth it, nor is the timing great for doing this scale >> of change. It also dubious if any of the READDIR code >> would be shared for real directories and device maps. >> >> An alternative is proposed below. >> >> GETDEVICEINFO or GETDEVICELIST each return a device >> stateid that represents a recallable, read-only hold on >> the mappings. Recall of the device stateid will remove the >> mappings. Lease expiration can remove the mappings. The >> mappings stay in force until recall of the stateid or >> lease expiration. GETDEVICEINFO and GETDEVICELIST change >> the current file handle so the CB_RECALL can be used to >> recall the device stateid. All layouts using the device IDs >> remain in force, but the server MUST fence the client >> from accessing the affected data servers until >> the device IDs are re-mapped (via GETDEVICEINFO or >> GETDEVICELIST). >> >> There is at most one device stateid per { client ID, >> layout type } pair. >> >> CB_NOTIFY can modify, delete, or add mappings, >> if GETDEVICEINFO and GETDEVICELIST request notifications and >> if the server supports device notifications. >> The notifications available are: >> >> NOTIFY4_DELETE_DEVICE_ID >> Deletes all mappings using the specified device ID. >> The server MUST stop using the device ID. Any >> layouts remain in force, but aren't useful until >> new mappings are available. The server fences the >> client from the affected data server until all >> layouts with the device ID are returned, or the >> client obtains new mappings. The server provides >> a hint as to whether new mappings will arrive and >> if so how long. >> >> NOTIFY4_ADD_DEVICE_ID >> Adds a device ID to address mapping. This is >> for a device ID the that was not returned in a >> previous series GETDEVICELIST calls (where the >> series ended in gdlr_eof == TRUE). The client >> calls GETDEVICEINFO or GETDEVICELIST to determine >> the mappings for the new device ID. >> >> NOTIFY4_CHANGE_DEVICE_ID >> The client call GETDEVICEINFO or GETDEVICELIST >> to get updated device addresses for the device >> ID. Layouts remain in force. The client is fenced >> from any devices that were in the old address list, >> but not the new address list. >> >> SEQUENCE will have a status flag added to indicate that >> the device mappings have been partially deleted, fully >> deleted (e.g. recall or lease expiry), changed, or added >> to. The partially deleted flag stays on until the client >> responds to any and all _DELETE notifications, or it does >> a GETDEVICELIST. The fully deleted flag stays on until >> DELEGRETURN returns the device stateid. The changed and >> added flags stay on until a GETDEVICELIST or GETDEVICEINFO >> gets the affected mappings. >> >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 10:55:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFt8D-0007eZ-H3; Tue, 31 Jul 2007 10:55:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFt8B-0007eM-He for nfsv4@ietf.org; Tue, 31 Jul 2007 10:55:27 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFt8B-0004Q8-5m for nfsv4@ietf.org; Tue, 31 Jul 2007 10:55:27 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6VEo9Po016160; Tue, 31 Jul 2007 10:50:09 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 31 Jul 2007 10:50:09 -0400 Received: from [192.168.0.140] ([172.17.28.146]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:50:08 -0400 Message-ID: <46AF4C1D.9080503@panasas.com> Date: Tue, 31 Jul 2007 17:50:05 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Marc Eshel Subject: Re: [nfsv4] Device stateids References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 14:50:09.0132 (UTC) FILETIME=[172C0AC0:01C7D382] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Garth Goodson , Spencer Shepler , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Marc Eshel wrote: > Benny Halevy wrote on 07/31/2007 01:54:46 AM: > >> Garth Goodson wrote: >>> Spencer Shepler wrote: >>>> We seem to have consensus on Mike's device stateid proposal >>>> and I will work to integrate the changes into the next draft. >>>> If there are any tweaks needed, please speak up. >>>> >>>> I have included the original text for reference. >>>> >>>> Spencer >>>> >>> I think one of the areas still under debate was about the ability to >>> recall and return multiple devices at once and I want to make sure >>> everyone is aware of the implication of this proposal. >>> >>> There was discussion about breaking the deviceID in two sections >>> (major,minor) such that a recall could recall all IDs associated with > a >>> major num. I don't see this in the proposal below. >>> >>> So my question is, is it possible to recall all device IDs for a given > >>> FSID in a single call, and return in a single call (like it is in the >>> current text)? If not, is everyone ok with this. >> For us it's sub-optimal but we can live with this restriction. >> > I missed the answer to Garth question. Did you loose the ability to recall > all device IDs for a given FSID? It appears so in Spencer's most recent "device stateids" proposal. > Marc. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 10:55:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFt8D-0007ee-MZ; Tue, 31 Jul 2007 10:55:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFt8B-0007eN-JD for nfsv4@ietf.org; Tue, 31 Jul 2007 10:55:27 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFt8A-0004Q6-QQ for nfsv4@ietf.org; Tue, 31 Jul 2007 10:55:27 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6VEtFvq016256; Tue, 31 Jul 2007 10:55:15 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 31 Jul 2007 10:55:15 -0400 Received: from [192.168.0.140] ([172.17.28.146]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:55:14 -0400 Message-ID: <46AF4D50.2000104@panasas.com> Date: Tue, 31 Jul 2007 17:55:12 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Garth Goodson , Spencer Shepler Subject: Re: [nfsv4] Device stateids References: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> <46AE1D05.3060505@netapp.com> In-Reply-To: <46AE1D05.3060505@netapp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 14:55:14.0341 (UTC) FILETIME=[CD173D50:01C7D382] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: nfsv4@ietf.org, Marc Eshel X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Apparently, one more thing the new proposal loses is the layout_type granularity. CB_NOTIFY will delete all device mappings for all layout types, even if the MDS is serving heterogeneous file systems exported over different sets of devices and layout types. The idea behind my proposal for composite device ID is to be able to group devices into "device sets" that you can recall and return. The server can then map the device sets according to its architecture and topology so one server can have a single device set for all devices, the other can have one device set per filesystem, and a third could map several filesystems onto one device set as they they may share the same devices. Benny Garth Goodson wrote: > > Spencer Shepler wrote: >> We seem to have consensus on Mike's device stateid proposal >> and I will work to integrate the changes into the next draft. >> If there are any tweaks needed, please speak up. >> >> I have included the original text for reference. >> >> Spencer >> > > I think one of the areas still under debate was about the ability to > recall and return multiple devices at once and I want to make sure > everyone is aware of the implication of this proposal. > > There was discussion about breaking the deviceID in two sections > (major,minor) such that a recall could recall all IDs associated with a > major num. I don't see this in the proposal below. > > So my question is, is it possible to recall all device IDs for a given > FSID in a single call, and return in a single call (like it is in the > current text)? If not, is everyone ok with this. > > -Garth > > >> >> >> Recallable Device ID to Device Address Mappings >> ----------------------------------------------- >> >> Proposal: >> >> Make each MDS server's device ID to device adddress >> mappings a single recallable object. >> >> Rationale: >> >> The specification is unclear as to when device ID to device >> address mappings can change. There are attempts single >> tie these to layouts and/or leases. They should be tied to >> leases, but layouts are separate, albeit, related concept, >> and besides which, the layout-type independent part of a >> layout doesn't have a device ID. >> >> More Details of Proposal: >> >> I have previously observed that device mappings and >> their semantics closely follow directories. The desire to >> have recall of all of some mappings resembles directory >> delegations and notifications represent a model that device >> mappings could use. Thus it seems possible use directory >> operations for manipulating device mappings. However doing >> this would not save any operations because a "PUTDEVFH" >> operation (with a layouttype argument) would have to >> be added to allow READDIR to replace GETDEVICELIST >> (and then we have to figure out how to have directory >> entries represent device ID to device address mappingfs -- >> presumably with attributes). And an operation to map a >> device ID to an address would still be needed, unless we >> make device IDs file handles (a 4 byte length followed by >> a 4 byte handle). >> >> Regardless, the complexity of simulating a directory, >> when there aren't POSIX APIs that want directory semantics >> (e.g. per entry cookies) for device mappings might not be >> worth it, nor is the timing great for doing this scale >> of change. It also dubious if any of the READDIR code >> would be shared for real directories and device maps. >> >> An alternative is proposed below. >> >> GETDEVICEINFO or GETDEVICELIST each return a device >> stateid that represents a recallable, read-only hold on >> the mappings. Recall of the device stateid will remove the >> mappings. Lease expiration can remove the mappings. The >> mappings stay in force until recall of the stateid or >> lease expiration. GETDEVICEINFO and GETDEVICELIST change >> the current file handle so the CB_RECALL can be used to >> recall the device stateid. All layouts using the device IDs >> remain in force, but the server MUST fence the client >> from accessing the affected data servers until >> the device IDs are re-mapped (via GETDEVICEINFO or >> GETDEVICELIST). >> >> There is at most one device stateid per { client ID, >> layout type } pair. >> >> CB_NOTIFY can modify, delete, or add mappings, >> if GETDEVICEINFO and GETDEVICELIST request notifications and >> if the server supports device notifications. >> The notifications available are: >> >> NOTIFY4_DELETE_DEVICE_ID >> Deletes all mappings using the specified device ID. >> The server MUST stop using the device ID. Any >> layouts remain in force, but aren't useful until >> new mappings are available. The server fences the >> client from the affected data server until all >> layouts with the device ID are returned, or the >> client obtains new mappings. The server provides >> a hint as to whether new mappings will arrive and >> if so how long. >> >> NOTIFY4_ADD_DEVICE_ID >> Adds a device ID to address mapping. This is >> for a device ID the that was not returned in a >> previous series GETDEVICELIST calls (where the >> series ended in gdlr_eof == TRUE). The client >> calls GETDEVICEINFO or GETDEVICELIST to determine >> the mappings for the new device ID. >> >> NOTIFY4_CHANGE_DEVICE_ID >> The client call GETDEVICEINFO or GETDEVICELIST >> to get updated device addresses for the device >> ID. Layouts remain in force. The client is fenced >> from any devices that were in the old address list, >> but not the new address list. >> >> SEQUENCE will have a status flag added to indicate that >> the device mappings have been partially deleted, fully >> deleted (e.g. recall or lease expiry), changed, or added >> to. The partially deleted flag stays on until the client >> responds to any and all _DELETE notifications, or it does >> a GETDEVICELIST. The fully deleted flag stays on until >> DELEGRETURN returns the device stateid. The changed and >> added flags stay on until a GETDEVICELIST or GETDEVICEINFO >> gets the affected mappings. >> >> >> _______________________________________________ >> nfsv4 mailing list >> nfsv4@ietf.org >> https://www1.ietf.org/mailman/listinfo/nfsv4 > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 10:55:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFt8D-0007eZ-H3; Tue, 31 Jul 2007 10:55:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFt8B-0007eM-He for nfsv4@ietf.org; Tue, 31 Jul 2007 10:55:27 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFt8B-0004Q8-5m for nfsv4@ietf.org; Tue, 31 Jul 2007 10:55:27 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6VEo9Po016160; Tue, 31 Jul 2007 10:50:09 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 31 Jul 2007 10:50:09 -0400 Received: from [192.168.0.140] ([172.17.28.146]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:50:08 -0400 Message-ID: <46AF4C1D.9080503@panasas.com> Date: Tue, 31 Jul 2007 17:50:05 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Marc Eshel Subject: Re: [nfsv4] Device stateids References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 14:50:09.0132 (UTC) FILETIME=[172C0AC0:01C7D382] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Garth Goodson , Spencer Shepler , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Marc Eshel wrote: > Benny Halevy wrote on 07/31/2007 01:54:46 AM: > >> Garth Goodson wrote: >>> Spencer Shepler wrote: >>>> We seem to have consensus on Mike's device stateid proposal >>>> and I will work to integrate the changes into the next draft. >>>> If there are any tweaks needed, please speak up. >>>> >>>> I have included the original text for reference. >>>> >>>> Spencer >>>> >>> I think one of the areas still under debate was about the ability to >>> recall and return multiple devices at once and I want to make sure >>> everyone is aware of the implication of this proposal. >>> >>> There was discussion about breaking the deviceID in two sections >>> (major,minor) such that a recall could recall all IDs associated with > a >>> major num. I don't see this in the proposal below. >>> >>> So my question is, is it possible to recall all device IDs for a given > >>> FSID in a single call, and return in a single call (like it is in the >>> current text)? If not, is everyone ok with this. >> For us it's sub-optimal but we can live with this restriction. >> > I missed the answer to Garth question. Did you loose the ability to recall > all device IDs for a given FSID? It appears so in Spencer's most recent "device stateids" proposal. > Marc. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 11:10:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtML-00081u-DA; Tue, 31 Jul 2007 11:10:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtMJ-00080V-IE for nfsv4@ietf.org; Tue, 31 Jul 2007 11:10:04 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFtMI-0004ly-RD for nfsv4@ietf.org; Tue, 31 Jul 2007 11:10:03 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6VFBIYL021008 for ; Tue, 31 Jul 2007 11:11:18 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6VFA1r9374444 for ; Tue, 31 Jul 2007 11:10:02 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6VFA0lS027889 for ; Tue, 31 Jul 2007 11:10:00 -0400 Received: from d01ml604.pok.ibm.com (d01ml604.pok.ibm.com [9.56.227.90]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6VFA0RW027879; Tue, 31 Jul 2007 11:10:00 -0400 In-Reply-To: <46AF4C1D.9080503@panasas.com> To: Benny Halevy MIME-Version: 1.0 Subject: Re: [nfsv4] Device stateids X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Marc Eshel Date: Tue, 31 Jul 2007 08:09:53 -0700 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Build V80_M5_05202007|May 20, 2007) at 07/31/2007 11:10:02, Serialize complete at 07/31/2007 11:10:02 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Garth Goodson , Spencer Shepler , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Benny Halevy wrote on 07/31/2007 07:50:05 AM: > Marc Eshel wrote: > > Benny Halevy wrote on 07/31/2007 01:54:46 AM: > > > >> Garth Goodson wrote: > >>> Spencer Shepler wrote: > >>>> We seem to have consensus on Mike's device stateid proposal > >>>> and I will work to integrate the changes into the next draft. > >>>> If there are any tweaks needed, please speak up. > >>>> > >>>> I have included the original text for reference. > >>>> > >>>> Spencer > >>>> > >>> I think one of the areas still under debate was about the ability to > >>> recall and return multiple devices at once and I want to make sure > >>> everyone is aware of the implication of this proposal. > >>> > >>> There was discussion about breaking the deviceID in two sections > >>> (major,minor) such that a recall could recall all IDs associated with > > a > >>> major num. I don't see this in the proposal below. > >>> > >>> So my question is, is it possible to recall all device IDs for a given > > > >>> FSID in a single call, and return in a single call (like it is in the > >>> current text)? If not, is everyone ok with this. > >> For us it's sub-optimal but we can live with this restriction. > >> > > I missed the answer to Garth question. Did you loose the ability to recall > > all device IDs for a given FSID? > > It appears so in Spencer's most recent "device stateids" proposal. > Given that few of us would prefer to have this ability Is there a good reason why it is being dropped? I assume that recall all layouts for a given FSID is still there. Marc. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 11:59:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFu81-0005zb-2h; Tue, 31 Jul 2007 11:59:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFu7y-0005wi-Vw for nfsv4@ietf.org; Tue, 31 Jul 2007 11:59:19 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFu7y-0006yS-Go for nfsv4@ietf.org; Tue, 31 Jul 2007 11:59:18 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6VFwqwT018740; Tue, 31 Jul 2007 11:58:52 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 31 Jul 2007 11:58:52 -0400 Received: from [192.168.0.140] ([172.17.28.146]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 11:58:52 -0400 Message-ID: <46AF5C3A.4080408@panasas.com> Date: Tue, 31 Jul 2007 18:58:50 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Marc Eshel Subject: Re: [nfsv4] Device stateids References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 15:58:52.0321 (UTC) FILETIME=[B0C8C110:01C7D38B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Garth Goodson , Spencer Shepler , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Marc Eshel wrote: > Benny Halevy wrote on 07/31/2007 07:50:05 AM: > >> Marc Eshel wrote: >>> Benny Halevy wrote on 07/31/2007 01:54:46 AM: >>> >>>> Garth Goodson wrote: >>>>> Spencer Shepler wrote: >>>>>> We seem to have consensus on Mike's device stateid proposal >>>>>> and I will work to integrate the changes into the next draft. >>>>>> If there are any tweaks needed, please speak up. >>>>>> >>>>>> I have included the original text for reference. >>>>>> >>>>>> Spencer >>>>>> >>>>> I think one of the areas still under debate was about the ability to > >>>>> recall and return multiple devices at once and I want to make sure >>>>> everyone is aware of the implication of this proposal. >>>>> >>>>> There was discussion about breaking the deviceID in two sections >>>>> (major,minor) such that a recall could recall all IDs associated > with >>> a >>>>> major num. I don't see this in the proposal below. >>>>> >>>>> So my question is, is it possible to recall all device IDs for a > given >>>>> FSID in a single call, and return in a single call (like it is in > the >>>>> current text)? If not, is everyone ok with this. >>>> For us it's sub-optimal but we can live with this restriction. >>>> >>> I missed the answer to Garth question. Did you loose the ability to > recall >>> all device IDs for a given FSID? >> It appears so in Spencer's most recent "device stateids" proposal. >> > > Given that few of us would prefer to have this ability Is there a good > reason why it is being dropped? If I recall correctly, Mike Eisler's original reason was to simplify the client so it wouldn't have to track the device mappings per fsid. FWIW, this doesn't look too complicated to implement IMO... > I assume that recall all layouts for a given FSID is still there. Yes it's still there. > Marc. > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 12:09:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuHs-0004A0-Jz; Tue, 31 Jul 2007 12:09:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuHr-00049m-2V for nfsv4@ietf.org; Tue, 31 Jul 2007 12:09:31 -0400 Received: from mout.perfora.net ([74.208.4.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFuHq-0007GY-MV for nfsv4@ietf.org; Tue, 31 Jul 2007 12:09:30 -0400 Received: from [72.179.37.29] (helo=[10.0.1.6]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis), id 0MKpCa-1IFuHo2Vpj-0006VG; Tue, 31 Jul 2007 12:09:29 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <46AE1D05.3060505@netapp.com> References: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> <46AE1D05.3060505@netapp.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <40C6FCD9-6CBC-4540-B6BF-4DCB1A776CBD@openrbg.com> Content-Transfer-Encoding: 7bit From: Robert Gordon Subject: Re: [nfsv4] Device stateids Date: Tue, 31 Jul 2007 11:12:27 -0500 To: NFSv4 X-Mailer: Apple Mail (2.752.2) X-Provags-ID: V01U2FsdGVkX1/iC/3aC94CkVseIxnvbS8w3DiauOx708/cjxC 2/yngiv/fmp/6k/eSGdv8vHpfGkwIbtvpbKYrsrdNT4Wez/0Om hJdVWUS6oE1TUtBAxgZvw== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 30, 2007, at 12:16 PM, Garth Goodson wrote: > So my question is, is it possible to recall all device IDs for a > given FSID in a single call, and return in a single call (like it > is in the current text)? If not, is everyone ok with this. it is, and i think that the current proposal is good. Robert.. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 12:50:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuvs-0007E2-Pb; Tue, 31 Jul 2007 12:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuvr-0007CC-3x for nfsv4@ietf.org; Tue, 31 Jul 2007 12:50:51 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFuvp-0007Gf-Qq for nfsv4@ietf.org; Tue, 31 Jul 2007 12:50:51 -0400 X-IronPort-AV: E=Sophos;i="4.19,204,1183359600"; d="scan'208";a="87822020" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 31 Jul 2007 09:50:49 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6VGomMF027603; Tue, 31 Jul 2007 09:50:48 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 09:50:48 -0700 Received: from exsvl03.hq.netapp.com ([10.56.8.64]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 09:50:48 -0700 Received: from [10.34.24.132] ([10.34.24.132]) by exsvl03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 09:50:48 -0700 Message-ID: <46AF6867.3030503@netapp.com> Date: Tue, 31 Jul 2007 09:50:47 -0700 From: Garth Goodson User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Robert Gordon Subject: Re: [nfsv4] Device stateids References: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> <46AE1D05.3060505@netapp.com> <40C6FCD9-6CBC-4540-B6BF-4DCB1A776CBD@openrbg.com> In-Reply-To: <40C6FCD9-6CBC-4540-B6BF-4DCB1A776CBD@openrbg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 16:50:48.0274 (UTC) FILETIME=[F2097320:01C7D392] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Robert Gordon wrote: > > On Jul 30, 2007, at 12:16 PM, Garth Goodson wrote: > >> So my question is, is it possible to recall all device IDs for a given >> FSID in a single call, and return in a single call (like it is in the >> current text)? If not, is everyone ok with this. > > it is, and i think that the current proposal is good. > I guess there is still some confusion if you are claiming that it is still possible to recall all device IDs and return them all in a single call (how are all their stateids specified?). It seems a separate op is needed for each stateid. A few messages back Benny stated it was not possible and I tend to agree. -Garth > Robert.. > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 12:53:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuyN-00035u-DN; Tue, 31 Jul 2007 12:53:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuyM-00035p-Cx for nfsv4@ietf.org; Tue, 31 Jul 2007 12:53:26 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFuyL-0007M1-4c for nfsv4@ietf.org; Tue, 31 Jul 2007 12:53:26 -0400 X-IronPort-AV: E=Sophos;i="4.19,204,1183359600"; d="scan'208";a="87822757" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 31 Jul 2007 09:53:20 -0700 Received: from svlexrs02.hq.netapp.com (svlexrs02.corp.netapp.com [10.57.156.154]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6VGrKVs028205; Tue, 31 Jul 2007 09:53:20 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 09:53:19 -0700 Received: from exsvl03.hq.netapp.com ([10.56.8.64]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 09:53:19 -0700 Received: from [10.34.24.132] ([10.34.24.132]) by exsvl03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 09:53:19 -0700 Message-ID: <46AF68FF.10804@netapp.com> Date: Tue, 31 Jul 2007 09:53:19 -0700 From: Garth Goodson User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Benny Halevy Subject: Re: [nfsv4] Device stateids References: <46AF5C3A.4080408@panasas.com> In-Reply-To: <46AF5C3A.4080408@panasas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 16:53:19.0479 (UTC) FILETIME=[4C298070:01C7D393] X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Spencer Shepler , Marc Eshel , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Benny Halevy wrote: > Marc Eshel wrote: >> Benny Halevy wrote on 07/31/2007 07:50:05 AM: >> >>> Marc Eshel wrote: >>>> Benny Halevy wrote on 07/31/2007 01:54:46 AM: >>>> >>>>> Garth Goodson wrote: >>>>>> Spencer Shepler wrote: >>>>>>> We seem to have consensus on Mike's device stateid proposal >>>>>>> and I will work to integrate the changes into the next draft. >>>>>>> If there are any tweaks needed, please speak up. >>>>>>> >>>>>>> I have included the original text for reference. >>>>>>> >>>>>>> Spencer >>>>>>> >>>>>> I think one of the areas still under debate was about the ability to >>>>>> recall and return multiple devices at once and I want to make sure >>>>>> everyone is aware of the implication of this proposal. >>>>>> >>>>>> There was discussion about breaking the deviceID in two sections >>>>>> (major,minor) such that a recall could recall all IDs associated >> with >>>> a >>>>>> major num. I don't see this in the proposal below. >>>>>> >>>>>> So my question is, is it possible to recall all device IDs for a >> given >>>>>> FSID in a single call, and return in a single call (like it is in >> the >>>>>> current text)? If not, is everyone ok with this. >>>>> For us it's sub-optimal but we can live with this restriction. >>>>> >>>> I missed the answer to Garth question. Did you loose the ability to >> recall >>>> all device IDs for a given FSID? >>> It appears so in Spencer's most recent "device stateids" proposal. >>> >> Given that few of us would prefer to have this ability Is there a good >> reason why it is being dropped? > > If I recall correctly, Mike Eisler's original reason was to simplify > the client so it wouldn't have to track the device mappings per fsid. > FWIW, this doesn't look too complicated to implement IMO... > >> I assume that recall all layouts for a given FSID is still there. > > Yes it's still there. > But since LAYOUTRETURN now takes a stateid, it is not possible to return them all at once as was possible before. Correct? -Garth >> Marc. >> _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 13:29:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvX8-0001X7-8K; Tue, 31 Jul 2007 13:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvX6-0001RS-C8 for nfsv4@ietf.org; Tue, 31 Jul 2007 13:29:20 -0400 Received: from gw-colo-pa.panasas.com ([66.238.117.130] helo=cassoulet.panasas.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFvX4-0008Jl-1X for nfsv4@ietf.org; Tue, 31 Jul 2007 13:29:20 -0400 Received: from riverside.int.panasas.com (localhost.localdomain [127.0.0.1]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id l6VHMi6Z021482; Tue, 31 Jul 2007 13:22:44 -0400 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 31 Jul 2007 13:22:44 -0400 Received: from [192.168.0.140] ([172.17.28.146]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 13:22:43 -0400 Message-ID: <46AF6FE2.7000501@panasas.com> Date: Tue, 31 Jul 2007 20:22:42 +0300 From: Benny Halevy User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Garth Goodson Subject: Re: [nfsv4] Device stateids References: <46AF5C3A.4080408@panasas.com> <46AF68FF.10804@netapp.com> In-Reply-To: <46AF68FF.10804@netapp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 17:22:44.0027 (UTC) FILETIME=[67EA28B0:01C7D397] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Spencer Shepler , Marc Eshel , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Garth Goodson wrote: > > Benny Halevy wrote: >> Marc Eshel wrote: >>> Benny Halevy wrote on 07/31/2007 07:50:05 AM: >>> >>>> Marc Eshel wrote: >>>>> Benny Halevy wrote on 07/31/2007 01:54:46 AM: >>>>> >>>>>> Garth Goodson wrote: >>>>>>> Spencer Shepler wrote: >>>>>>>> We seem to have consensus on Mike's device stateid proposal >>>>>>>> and I will work to integrate the changes into the next draft. >>>>>>>> If there are any tweaks needed, please speak up. >>>>>>>> >>>>>>>> I have included the original text for reference. >>>>>>>> >>>>>>>> Spencer >>>>>>>> >>>>>>> I think one of the areas still under debate was about the ability to >>>>>>> recall and return multiple devices at once and I want to make sure >>>>>>> everyone is aware of the implication of this proposal. >>>>>>> >>>>>>> There was discussion about breaking the deviceID in two sections >>>>>>> (major,minor) such that a recall could recall all IDs associated >>> with >>>>> a >>>>>>> major num. I don't see this in the proposal below. >>>>>>> >>>>>>> So my question is, is it possible to recall all device IDs for a >>> given >>>>>>> FSID in a single call, and return in a single call (like it is in >>> the >>>>>>> current text)? If not, is everyone ok with this. >>>>>> For us it's sub-optimal but we can live with this restriction. >>>>>> >>>>> I missed the answer to Garth question. Did you loose the ability to >>> recall >>>>> all device IDs for a given FSID? >>>> It appears so in Spencer's most recent "device stateids" proposal. >>>> >>> Given that few of us would prefer to have this ability Is there a good >>> reason why it is being dropped? >> If I recall correctly, Mike Eisler's original reason was to simplify >> the client so it wouldn't have to track the device mappings per fsid. >> FWIW, this doesn't look too complicated to implement IMO... >> >>> I assume that recall all layouts for a given FSID is still there. >> Yes it's still there. >> > But since LAYOUTRETURN now takes a stateid, it is not possible to return > them all at once as was possible before. Correct? I assumed that you can return for FSID/ALL as before with a null lora_stateid and a non-null lora_recallstateid but I'm not sure what was the intent. Obviously that changes the layout state of each affected file, but on the other hand, the client doesn't really need the layout stateid per-file after returning the whole layout. On a subsequent LAYOUTGET it can send the same stateid it sent after opening the file and if the file is closed by now it must open it again anyway. > > -Garth > > >>> Marc. >>> _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 13:32:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvZg-0003bP-DU; Tue, 31 Jul 2007 13:32:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvZe-0003ak-Pu for nfsv4@ietf.org; Tue, 31 Jul 2007 13:31:58 -0400 Received: from mout.perfora.net ([74.208.4.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFvZe-0001m7-Aj for nfsv4@ietf.org; Tue, 31 Jul 2007 13:31:58 -0400 Received: from [72.179.37.29] (helo=[10.0.1.6]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1IFvZc2z7Q-0005pf; Tue, 31 Jul 2007 13:31:58 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <46AF6867.3030503@netapp.com> References: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> <46AE1D05.3060505@netapp.com> <40C6FCD9-6CBC-4540-B6BF-4DCB1A776CBD@openrbg.com> <46AF6867.3030503@netapp.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98B0EAED-549B-4093-B61C-7870D2522201@openrbg.com> Content-Transfer-Encoding: 7bit From: Robert Gordon Subject: Re: [nfsv4] Device stateids Date: Tue, 31 Jul 2007 12:34:56 -0500 To: NFSv4 X-Mailer: Apple Mail (2.752.2) X-Provags-ID: V01U2FsdGVkX1/fJaG2ERlW8dqUtSUFS0ne6VL86CtbjUzwOck abTw6Kdv1sEDCjEjUlXUT6yMgcR8IIhrebxOl9rOsn1YKJ8bGp FoF7nAfUgqdbn7KJpRx1A== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Jul 31, 2007, at 11:50 AM, Garth Goodson wrote: > > Robert Gordon wrote: >> On Jul 30, 2007, at 12:16 PM, Garth Goodson wrote: >>> So my question is, is it possible to recall all device IDs for a >>> given FSID in a single call, and return in a single call (like it >>> is in the current text)? If not, is everyone ok with this. >> it is, and i think that the current proposal is good. > > I guess there is still some confusion if you are claiming that it > is still possible to recall all device IDs and return them all in a > single call (how are all their stateids specified?). It seems a > separate op is needed for each stateid. > > A few messages back Benny stated it was not possible and I tend to > agree. > > -Garth Perhaps i misunderstood this: > SEQUENCE will have a status flag added to indicate that > the device mappings have been partially deleted, fully > deleted (e.g. recall or lease expiry), changed, or added > to. The partially deleted flag stays on until the client > responds to any and all _DELETE notifications, or it does > a GETDEVICELIST. The fully deleted flag stays on until > DELEGRETURN returns the device stateid. The changed and > added flags stay on until a GETDEVICELIST or GETDEVICEINFO > gets the affected mappings. I took it to mean: if in SEQUENCE the server has indicated that the deviceid mappings have been fully deleted ; then the client should dump its current device list and issue GETDEVICELIST. Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 13:39:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvh2-0008NQ-SC; Tue, 31 Jul 2007 13:39:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvh1-0008M3-7p for nfsv4@ietf.org; Tue, 31 Jul 2007 13:39:35 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFvh0-00021e-Q7 for nfsv4@ietf.org; Tue, 31 Jul 2007 13:39:35 -0400 X-IronPort-AV: E=Sophos;i="4.19,204,1183359600"; d="scan'208";a="87838599" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 31 Jul 2007 10:38:59 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6VHctsK027161; Tue, 31 Jul 2007 10:38:55 -0700 (PDT) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:38:55 -0700 Received: from exsvl03.hq.netapp.com ([10.56.8.64]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:38:55 -0700 Received: from [10.34.24.132] ([10.34.24.132]) by exsvl03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:38:55 -0700 Message-ID: <46AF73AE.2090402@netapp.com> Date: Tue, 31 Jul 2007 10:38:54 -0700 From: Garth Goodson User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Robert Gordon Subject: Re: [nfsv4] Device stateids References: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> <46AE1D05.3060505@netapp.com> <40C6FCD9-6CBC-4540-B6BF-4DCB1A776CBD@openrbg.com> <46AF6867.3030503@netapp.com> <98B0EAED-549B-4093-B61C-7870D2522201@openrbg.com> In-Reply-To: <98B0EAED-549B-4093-B61C-7870D2522201@openrbg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 17:38:55.0045 (UTC) FILETIME=[AAAFBF50:01C7D399] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Robert Gordon wrote: > > On Jul 31, 2007, at 11:50 AM, Garth Goodson wrote: >> >> Robert Gordon wrote: >>> On Jul 30, 2007, at 12:16 PM, Garth Goodson wrote: >>>> So my question is, is it possible to recall all device IDs for a >>>> given FSID in a single call, and return in a single call (like it is >>>> in the current text)? If not, is everyone ok with this. >>> it is, and i think that the current proposal is good. >> >> I guess there is still some confusion if you are claiming that it is >> still possible to recall all device IDs and return them all in a >> single call (how are all their stateids specified?). It seems a >> separate op is needed for each stateid. >> >> A few messages back Benny stated it was not possible and I tend to agree. >> >> -Garth > > Perhaps i misunderstood this: > >> SEQUENCE will have a status flag added to indicate that >> the device mappings have been partially deleted, fully >> deleted (e.g. recall or lease expiry), changed, or added >> to. The partially deleted flag stays on until the client >> responds to any and all _DELETE notifications, or it does >> a GETDEVICELIST. The fully deleted flag stays on until >> DELEGRETURN returns the device stateid. The changed and >> added flags stay on until a GETDEVICELIST or GETDEVICEINFO >> gets the affected mappings. > > I took it to mean: > > if in SEQUENCE the server has indicated that the deviceid > mappings have been fully deleted ; then the client should > dump its current device list and issue GETDEVICELIST. > > Robert. > The thing that has me hung up is the sentence: 'The fully deleted flag stays on until DELEGRETURN returns the device stateid.' Which seems to imply that each stateid needs to be returned. Spencer/Mike clarification? -Garth > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 13:40:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvi8-0000aQ-Lx; Tue, 31 Jul 2007 13:40:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvi7-0000aK-3j for nfsv4@ietf.org; Tue, 31 Jul 2007 13:40:43 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFvi6-00023I-Jo for nfsv4@ietf.org; Tue, 31 Jul 2007 13:40:43 -0400 X-IronPort-AV: E=Sophos;i="4.19,204,1183359600"; d="scan'208";a="87839115" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 31 Jul 2007 10:40:42 -0700 Received: from svlexrs01.hq.netapp.com (svlexrs01.corp.netapp.com [10.57.156.158]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id l6VHeBkL016283; Tue, 31 Jul 2007 10:40:38 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:40:32 -0700 Received: from exsvl03.hq.netapp.com ([10.56.8.64]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:40:31 -0700 Received: from [10.34.24.132] ([10.34.24.132]) by exsvl03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:40:31 -0700 Message-ID: <46AF740C.3090404@netapp.com> Date: Tue, 31 Jul 2007 10:40:28 -0700 From: Garth Goodson User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Benny Halevy Subject: Re: [nfsv4] Device stateids References: <46AF5C3A.4080408@panasas.com> <46AF68FF.10804@netapp.com> <46AF6FE2.7000501@panasas.com> In-Reply-To: <46AF6FE2.7000501@panasas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2007 17:40:31.0593 (UTC) FILETIME=[E43BCD90:01C7D399] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Spencer Shepler , Marc Eshel , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Benny Halevy wrote: > Garth Goodson wrote: >> Benny Halevy wrote: >>> Marc Eshel wrote: >>>> Benny Halevy wrote on 07/31/2007 07:50:05 AM: >>>> >>>>> Marc Eshel wrote: >>>>>> Benny Halevy wrote on 07/31/2007 01:54:46 AM: >>>>>> >>>>>>> Garth Goodson wrote: >>>>>>>> Spencer Shepler wrote: >>>>>>>>> We seem to have consensus on Mike's device stateid proposal >>>>>>>>> and I will work to integrate the changes into the next draft. >>>>>>>>> If there are any tweaks needed, please speak up. >>>>>>>>> >>>>>>>>> I have included the original text for reference. >>>>>>>>> >>>>>>>>> Spencer >>>>>>>>> >>>>>>>> I think one of the areas still under debate was about the ability to >>>>>>>> recall and return multiple devices at once and I want to make sure >>>>>>>> everyone is aware of the implication of this proposal. >>>>>>>> >>>>>>>> There was discussion about breaking the deviceID in two sections >>>>>>>> (major,minor) such that a recall could recall all IDs associated >>>> with >>>>>> a >>>>>>>> major num. I don't see this in the proposal below. >>>>>>>> >>>>>>>> So my question is, is it possible to recall all device IDs for a >>>> given >>>>>>>> FSID in a single call, and return in a single call (like it is in >>>> the >>>>>>>> current text)? If not, is everyone ok with this. >>>>>>> For us it's sub-optimal but we can live with this restriction. >>>>>>> >>>>>> I missed the answer to Garth question. Did you loose the ability to >>>> recall >>>>>> all device IDs for a given FSID? >>>>> It appears so in Spencer's most recent "device stateids" proposal. >>>>> >>>> Given that few of us would prefer to have this ability Is there a good >>>> reason why it is being dropped? >>> If I recall correctly, Mike Eisler's original reason was to simplify >>> the client so it wouldn't have to track the device mappings per fsid. >>> FWIW, this doesn't look too complicated to implement IMO... >>> >>>> I assume that recall all layouts for a given FSID is still there. >>> Yes it's still there. >>> >> But since LAYOUTRETURN now takes a stateid, it is not possible to return >> them all at once as was possible before. Correct? > > I assumed that you can return for FSID/ALL as before with a null lora_stateid > and a non-null lora_recallstateid but I'm not sure what was the intent. > Obviously that changes the layout state of each affected file, but on the > other hand, the client doesn't really need the layout stateid per-file > after returning the whole layout. On a subsequent LAYOUTGET it can > send the same stateid it sent after opening the file and if the file > is closed by now it must open it again anyway. > I have no problem with this (if this is what was intended). But again, it looks like there are details that are missing from the proposals that are causing us to make assumptions. -Garth >> -Garth >> >> >>>> Marc. >>>> _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Jul 31 13:56:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvwv-0002Z6-5m; Tue, 31 Jul 2007 13:56:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFvwt-0002YF-QG for nfsv4@ietf.org; Tue, 31 Jul 2007 13:55:59 -0400 Received: from mout.perfora.net ([74.208.4.194]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFvwt-0002R4-CL for nfsv4@ietf.org; Tue, 31 Jul 2007 13:55:59 -0400 Received: from [72.179.37.29] (helo=[10.0.1.6]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis), id 0MKp8S-1IFvwr1mjX-0005q2; Tue, 31 Jul 2007 13:55:58 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> References: <82F98EA2-898C-464F-9735-5B323ACA7CA9@sun.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <374951B8-4F07-4FCA-B1C4-E94D3ECE699F@openrbg.com> Content-Transfer-Encoding: 7bit From: Robert Gordon Subject: Re: [nfsv4] Device stateids Date: Tue, 31 Jul 2007 12:58:58 -0500 To: NFSv4 X-Mailer: Apple Mail (2.752.2) X-Provags-ID: V01U2FsdGVkX1/0UUW1p1ZvkIYMrVDQw6kB7j7I7dCd3tv1ydg iHMUuXpzqU+K4NmoGHL5XQAv0Tsysq9yKC9DEXJLj5f7HUXnfh SlAToOxuE6EobaPH+SylQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Ah.. On Jul 27, 2007, at 12:12 AM, Spencer Shepler wrote: > An alternative is proposed below. > > GETDEVICEINFO or GETDEVICELIST each return a device > stateid that represents a recallable, read-only hold on > the mappings. I was thinking that each device would have a stateid, and the entire list would also be represented by a state id, such that recalling the 'list' stateid would recall ALL the mapping.. .. Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4