From KrisztianBlowers@JDsGems.com Thu Nov 01 03:05:27 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InU7L-0004IM-PM for nfsv4-archive@lists.ietf.org; Thu, 01 Nov 2007 03:05:27 -0400 Received: from mnhm-590c0911.pool.einsundeins.de ([89.12.9.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InU7E-0001Bw-K5 for nfsv4-archive@lists.ietf.org; Thu, 01 Nov 2007 03:05:27 -0400 Received: from HomePC ([160.178.159.197] helo=HomePC) by mnhm-590c0911.pool.einsundeins.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1rfRzh-000FYW-uQ for nfsv4-archive@lists.ietf.org; Thu, 1 Nov 2007 08:07:43 +0100 Message-ID: <000501c81c55$d1c70c60$11090c59@HomePC> From: "Krisztian Blowers" To: Subject: nissanun Date: Thu, 1 Nov 2007 08:07:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C81C5E.338B7460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0004_01C81C5E.338B7460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable How do you do? nfsv4-archive yes you were born with a little dick but you can change it today http://www.ceetw.com/ Krisztian Blowers ------=_NextPart_000_0004_01C81C5E.338B7460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
How do you do? nfsv4-archive
yes you were born with a little dick but you = can change=20 it today
http://www.ceetw.com/
Krisztian Blowers
------=_NextPart_000_0004_01C81C5E.338B7460-- From BrianabantusLujan@krugle.com Thu Nov 01 09:09:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InZnV-0004Ht-SU; Thu, 01 Nov 2007 09:09:21 -0400 Received: from [84.76.240.223] (helo=ultraheroe.dummy.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1InZnQ-0000Kt-9A; Thu, 01 Nov 2007 09:09:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host95730589.krugle.com (8.13.1/8.13.1) with SMTP id 0xTUoxKe67.871224.SIL.IwJ.2962462192855 for ; Thu, 1 Nov 2007 14:10:00 -0100 Message-ID: <140b601c81c88$8c8a4120$0201a8c0@ultraheroe> From: "Mitzi Bergman" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_140B2_01C81C88.8C8A4120-- From nfsv4-bounces@ietf.org Thu Nov 01 15:10: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 1InfQL-0001o5-R3; Thu, 01 Nov 2007 15:09:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InfQH-0001Vw-Qy for nfsv4@ietf.org; Thu, 01 Nov 2007 15:09:45 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InfQ2-00034c-98 for nfsv4@ietf.org; Thu, 01 Nov 2007 15:09:30 -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 lA1J9TGw001514 for ; Thu, 1 Nov 2007 15:09:29 -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 lA1J905I018482 for ; Thu, 1 Nov 2007 15:09:26 -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, 1 Nov 2007 15:09:11 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Nov 2007 15:09:10 -0400 Message-ID: <39CF2A4B63947142A66EAA65B2FDF2F005BDD2D6@CORPUSMX40A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GETDEVICEINFO and GETDEVICELIST in the draft-15 spec Thread-Index: Acgcuq8GAo/FoI+wRfWqD4dau9RH4g== To: X-OriginalArrivalTime: 01 Nov 2007 19:09:11.0396 (UTC) FILETIME=[AF801240:01C81CBA] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=1%, Reason='EMC_FROM_0+ -3, HTML_70_90 0.1, NO_REAL_NAME 0, __CP_NOT_1 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_MSGID 0, __HTML_FONT_BLUE 0, __HTML_MSWORD 0, __IMS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: c07eeb7900970a16fe4056cc74ae9ce2 Subject: [nfsv4] GETDEVICEINFO and GETDEVICELIST in the draft-15 spec 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="===============1241360942==" Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. --===============1241360942== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81CBA.A1A39934" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81CBA.A1A39934 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have two minor issues with the draft-15 spec related to GETDEVICEINFO and GETDEVICELIST. The spec does not adequately specify the meaning of gdia_maxcount. The sentence describing its usage states: =20 "The client provides gdia_maxcount to limit the amount of device address information to be returned for the mapping. If the mapping can not be returned within the maximum specified, NFS4ERR_TOOSMALL is returned." =20 This sentence does not make clear if gdia_maxount limits the number of bytes in the GETDEVICEINFO4res data structure, within the "device_addr4" structure, or within the protocol specific opaque data "da_addr_body". I propose that the wording be changed to clarify that this refers to the number of bytes in the "device_addr4" portion of the response. =20 "The client provides gdia_maxcount to limit the amount of device address information to be returned for the mapping. If the device address can not be returned within the maximum specified, NFS4ERR_TOOSMALL is returned." =20 Furthermore, in the case of returning NFS4ERR_TOOSMALL, the server should provide some means for the client to figure out the right amount of storage to allocate so that the call can succeed. In draft-15 the client has no way of knowing how much storage to allocate when it retries the call. =20 union GETDEVICEINFO4res switch (nfsstat4 gdir_status) { case NFS4_OK: GETDEVICEINFO4resok gdir_resok4; default: void; }; =20 =20 union GETDEVICELIST4res switch (nfsstat4 gdlr_status) { case NFS4_OK: GETDEVICELIST4resok gdlr_resok4; default: void; }; =20 =20 I suggest that both the above result data structures be changed to allow the server to specify a minimum count required for the RPC to succeed. =20 union GETDEVICEINFO4res switch (nfsstat4 gdir_status) { case NFS4_OK: GETDEVICEINFO4resok gdir_resok4; case NFS4ERR_TOOSMALL: count4 gdir_mincount; =20 default: void; }; =20 union GETDEVICELIST4res switch (nfsstat4 gdlr_status) { case NFS4_OK: GETDEVICELIST4resok gdlr_resok4; case NFS4ERR_TOOSMALL: count4 gdlr_mincount default: void; }; =20 The accompanying text in section 18.40.4 should be changed from ---- If the device address can not be returned within the maximum specified, NFS4ERR_TOOSMALL is returned. ---- to --- If the device address can not be returned within the maximum specified, NFS4ERR_TOOSMALL is returned along with the minimum size necessary for the call to succeed. --- =20 Similarly, section 18.41.4 should change from -- If gdia_maxcount is smaller than the size of a single entry, the error NFS4ERR_TOOSMALL is returned. -- To -- If gdia_maxcount is smaller than the size of a single entry, the error NFS4ERR_TOOSMALL is returned along with the minimum size necessary to encode a single entry. -- ------_=_NextPart_001_01C81CBA.A1A39934 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have two minor issues with the draft-15 spec = related to GETDEVICEINFO and GETDEVICELIST.  The spec does not adequately = specify the meaning of gdia_maxcount.  The sentence describing its usage = states:

 

“The client provides gdia_maxcount to = limit the amount of device address information to be returned for the mapping. = If the mapping can not be returned within the maximum specified, = NFS4ERR_TOOSMALL is returned.”

 

This sentence does not make clear if gdia_maxount = limits the number of bytes in the GETDEVICEINFO4res data structure, within the = “device_addr4” structure, or within the protocol specific opaque data = “da_addr_body”.  I propose that the wording be changed to clarify that this refers to the = number of bytes in the “device_addr4” portion of the = response.

 

“The client provides gdia_maxcount to = limit the amount of device address information to be returned for the mapping. = If the device address can not be returned within the maximum specified, NFS4ERR_TOOSMALL is returned.”

 

Furthermore, in the case of returning = NFS4ERR_TOOSMALL, the server should provide some means for the client to figure out the right = amount of storage to allocate so that the call can succeed.  In draft-15 = the client has no way of knowing how much storage to allocate when it = retries the call.

 

union GETDEVICEINFO4res switch (nfsstat4 gdir_status) {

case NFS4_OK:

        GETDEVICEINFO4resok     = gdir_resok4;

default:

        = void;

};

 

 

union GETDEVICELIST4res switch (nfsstat4 gdlr_status) {

case NFS4_OK:

        GETDEVICELIST4resok     = gdlr_resok4;

default:

        = void;

};

 

 

I suggest that both the above result data structures = be changed to allow the server to specify a minimum count required for the = RPC to succeed.

 

union GETDEVICEINFO4res switch (nfsstat4 gdir_status) {

case NFS4_OK:

        GETDEVICEINFO4resok     = gdir_resok4;

case = NFS4ERR_TOOSMALL:

        = count4 gdir_mincount;  

default:

        = void;

};

 

union GETDEVICELIST4res switch (nfsstat4 gdlr_status) {

case NFS4_OK:

        GETDEVICELIST4resok     = gdlr_resok4;

case = NFS4ERR_TOOSMALL:

        = count4 gdlr_mincount

default:

        = void;

};

 

The accompanying text in section 18.40.4 should be = changed from

----

If the device address can not be returned within the = maximum specified, NFS4ERR_TOOSMALL is returned.

----

to

---

If the device address can not be returned within the = maximum specified, NFS4ERR_TOOSMALL is returned along with the minimum size = necessary for the call to succeed.

---

 

Similarly, section 18.41.4 should change = from

--

If gdia_maxcount is smaller than the size of a single = entry, the error NFS4ERR_TOOSMALL is returned.

--

To

--

If gdia_maxcount is smaller than the size of a single = entry, the error NFS4ERR_TOOSMALL is returned along with the minimum size = necessary to encode a single entry.

--

------_=_NextPart_001_01C81CBA.A1A39934-- --===============1241360942== 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 --===============1241360942==-- From nfsv4-bounces@ietf.org Thu Nov 01 17:23:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InhUv-0001Xt-3z; Thu, 01 Nov 2007 17:22:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InhUt-0001Xe-US for nfsv4@ietf.org; Thu, 01 Nov 2007 17:22:39 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InhUt-0007Ww-IQ for nfsv4@ietf.org; Thu, 01 Nov 2007 17:22:39 -0400 X-IronPort-AV: E=Sophos;i="4.21,359,1188802800"; d="scan'208";a="118736854" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 01 Nov 2007 14:22:00 -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 lA1LM0Iw005992; Thu, 1 Nov 2007 14:22:00 -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, 1 Nov 2007 14:22:00 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 14:22:00 -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] Boo: NFSv4.1 draft 15 is available Date: Thu, 1 Nov 2007 17:21:58 -0400 Message-ID: In-Reply-To: <20071031195457.GH4569@fieldses.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Boo: NFSv4.1 draft 15 is available Thread-Index: Acgb+N0PcYwlCDr0QbeIFs93XhWUTQA1Fpng From: "Noveck, Dave" To: "J. Bruce Fields" , "Spencer Shepler" X-OriginalArrivalTime: 01 Nov 2007 21:22:00.0115 (UTC) FILETIME=[3D3A1830:01C81CCD] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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'll fix this.=20 -----Original Message----- From: J. Bruce Fields [mailto:bfields@fieldses.org]=20 Sent: Wednesday, October 31, 2007 3:55 PM To: Spencer Shepler Cc: NFSv4 Subject: Re: [nfsv4] Boo: NFSv4.1 draft 15 is available And one remaining nit: only series with 3 or more elements get commas. (If someone is really dead set on a comma there, then you could change the "and associated session" to a nonrestrictive parenthetical thing, and adjust the number of the verb to match, like: "A client ID, with associated session, is required..." Seems more cumbersome to me, though.) --b. diff --git a/nfsv41_middle_core_infrastructure.xml b/nfsv41_middle_core_infrastructure.xml index d41f6fb..34ec875 100755 --- a/nfsv41_middle_core_infrastructure.xml +++ b/nfsv41_middle_core_infrastructure.xml @@ -1467,7 +1467,7 @@ struct server_owner4 {
Each client ID () can have - zero or more active sessions. A client ID, and associated + zero or more active sessions. A client ID and associated session are required to perform file access in=20 NFSv4.1. Each time a session is used (whether by a client sending a request to the server, or the client replying to a callback _______________________________________________ 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 SydneycauliflowerMayo@cips.ca Thu Nov 01 17:24:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InhWj-00033B-QM; Thu, 01 Nov 2007 17:24:34 -0400 Received: from pool-70-16-6-36.balt.east.verizon.net ([70.16.6.36] helo=melaniegoss.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1InhWe-0007Zd-5X; Thu, 01 Nov 2007 17:24:28 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host67076044.cips.ca (8.13.1/8.13.1) with SMTP id DHXSLpC820.828111.JNU.fRE.5597572002399 for ; Thu, 1 Nov 2007 17:23:59 +0500 Message-ID: <195ab01c81ccd$9bd3c6c0$2f01a8c0@MelanieGoss> From: "Aldo Sears" To: Subject: Your order Date: Thu, 1 Nov 2007 17:23:59 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_195A7_01C81CCD.9BD3C6C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_195A7_01C81CCD.9BD3C6C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_195A7_01C81CCD.9BD3C6C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_195A7_01C81CCD.9BD3C6C0-- From nfsv4-bounces@ietf.org Thu Nov 01 18:48: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 1Inip6-0002x1-Kf; Thu, 01 Nov 2007 18:47:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inip5-0002wo-47 for nfsv4@ietf.org; Thu, 01 Nov 2007 18:47:35 -0400 Received: from p01c11o143.mxlogic.net ([208.65.144.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Inip4-0001hK-Jy for nfsv4@ietf.org; Thu, 01 Nov 2007 18:47:35 -0400 Received: from unknown [63.110.244.103] by p01c11o143.mxlogic.net (mxl_mta-5.2.0-1) with SMTP id 6875a274.2535918512.34008.00-020.p01c11o143.mxlogic.net (envelope-from ); Thu, 01 Nov 2007 16:47:34 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 1 Nov 2007 15:38:03 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: File Layout Questions (Layouts of the same file and Packing) Thread-Index: Acgc190CeCvlHPxmSHC1Ur1FYjpv3A== From: "Anatoly Pinchuk" To: X-Spam: [F=0.0100000000; S=0.010(2007101601); SS=0.500] X-MAIL-FROM: X-SOURCE-IP: [63.110.244.103] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [nfsv4] File Layout Questions (Layouts of the same file and Packing) 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="===============1959200401==" Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. --===============1959200401== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81CD7.DD390B98" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81CD7.DD390B98 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the replies on the layout range subject. =20 There are two more topics I would like to clarify =20 1. Layouts of the same client file There seems to be an agreement that more than one layout is possible corresponding to a given client file. If so, it would be great to describe if there are dependencies between the layouts of the same file. One interesting question is if the stripe unit size can be different in such layouts. =20 2. Sparse or dense packing Currently packing is stored in a layout which makes it impossible to bring two data servers with different packing implementations under the same layout. Also, it is unlikely that a data server implements both sparse and dense packing. Would it be more flexible then to have packing defined per equivalent data server group or even per data server? =20 Regards, Anatoly =20 ------_=_NextPart_001_01C81CD7.DD390B98 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the replies on the layout range = subject.

 

There are two more topics I would like to = clarify

 

1. Layouts of the same client = file

There seems to be an agreement that more than = one layout is possible corresponding to a given client = file. If so, it would be great to describe if there are dependencies between the = layouts of the same file. One interesting question is if the stripe unit size = can be different in such layouts.

 

2. Sparse or dense = packing

Currently packing is stored in a layout which makes = it impossible to bring two data servers with different packing = implementations under the same layout. Also, it is unlikely that a data server = implements both sparse and dense packing. Would it be more flexible then to have = packing defined per equivalent data server group or even per data = server?

 

Regards,

Anatoly

 

------_=_NextPart_001_01C81CD7.DD390B98-- --===============1959200401== 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 --===============1959200401==-- From nfsv4-bounces@ietf.org Thu Nov 01 21:52: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 1InlgK-0007Ba-V2; Thu, 01 Nov 2007 21:50:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InlgJ-00073X-MQ for nfsv4@ietf.org; Thu, 01 Nov 2007 21:50:43 -0400 Received: from web38113.mail.mud.yahoo.com ([209.191.124.140]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Inlfx-0002xM-Dm for nfsv4@ietf.org; Thu, 01 Nov 2007 21:50:27 -0400 Received: (qmail 47557 invoked by uid 60001); 2 Nov 2007 01:49:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=nXs5LhbFT/zJa8CLsM93UsWeZ0D4KygQXe38RQI+FYd6GU7wqH9rkh/6dp2obDG1bFB6GPIpCSvQhy16L5HsWdWiDIHaA3clvrn43ieMV6QHKQ5AE/BYP/+ItHO4KdaUIQ1NoFGBkHcEaRqyNxJruCTUvE6REnYWvDZJ1NpbiK8=; X-YMail-OSG: YY47z8QVM1lNAMHhiURJVu1s4Uv1mE3hm8ClSKz97QoyorI1MtNPXYEE0vk98jB8.wdZcbyi_A-- Received: from [198.95.226.230] by web38113.mail.mud.yahoo.com via HTTP; Thu, 01 Nov 2007 18:49:50 PDT Date: Thu, 1 Nov 2007 18:49:50 -0700 (PDT) From: Mike Eisler Subject: Re: [nfsv4] File Layout Questions (Layouts of the same file and Packing) To: Anatoly Pinchuk , nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <875645.47299.qm@web38113.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org > 1. Layouts of the same client file > > There seems to be an agreement that more than one layout is possible > corresponding to a given client file. If so, it would be great to > describe if there are dependencies between the layouts of the same > file. > One interesting question is if the stripe unit size can be different > in > such layouts. The spec doesn't disallow this. If you want to suggest some test to make this clear, that would be welcome. > 2. Sparse or dense packing > > Currently packing is stored in a layout which makes it impossible to > bring two data servers with different packing implementations under > the > same layout. Also, it is unlikely that a data server implements both > sparse and dense packing. Would it be more flexible then to have > packing > defined per equivalent data server group or even per data server? I thought the packing and stripe unit size should be in the device address, and asked this question of WG several on June 12, 2007. The consensus was to define it in the layout. So that's where we are. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 01 22:13:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inm1n-0004qv-VD; Thu, 01 Nov 2007 22:12:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inm1l-0004ps-Vt for nfsv4@ietf.org; Thu, 01 Nov 2007 22:12:54 -0400 Received: from web38104.mail.mud.yahoo.com ([209.191.124.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Inm1k-00073v-Nv for nfsv4@ietf.org; Thu, 01 Nov 2007 22:12:53 -0400 Received: (qmail 27823 invoked by uid 60001); 2 Nov 2007 02:12:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=PXVm4ETYm25mnzJkxNaCqBf7V1L4lYNlu6cub1LNKIdWg3A311H7uQK6aTDFWlQS9pY9PBtunRXeHyLMcmxlJxAxZO6I7FnXBXh18vakf1gxPVFV1JU6XVkuyFw3p8wjhmmiLhwo2QSyZgxDlMgyV1rZ7preoyUDD14hDKGkn6c=; X-YMail-OSG: PQuWA.UVM1moqZfKgpsnSkr5PnM3q18cBTyUji7sEdFirHT1gK1Y999sPkBWw7ZZen17KJCjQVoibNK0lT.gzHRrio60vSeF65xZHqGr3jNhnUpa0Ow- Received: from [198.95.226.230] by web38104.mail.mud.yahoo.com via HTTP; Thu, 01 Nov 2007 19:12:51 PDT Date: Thu, 1 Nov 2007 19:12:51 -0700 (PDT) From: Mike Eisler Subject: Re: [nfsv4] Request for an additional recommended attribute To: nfsv4@ietf.org In-Reply-To: <39CF2A4B63947142A66EAA65B2FDF2F005612D59@CORPUSMX40A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <208235.27820.qm@web38104.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Dave Noveck has tried to explain to me many times why Jason's proposal says: > If the client's maximum I/O time is > greater than the server's default, then the client MUST use SETATTR > to > inform the server of its maximum_I/O time. And I'm not getting it. To me, if the server has a guarantee of 30 seconds to either definitively fail to do, or succeed to do the I/O, then if client wants 60 seconds, a 30 second guarantee is semantically the same (stop the I/O after 30 seconds if not done; suspend for 30 more seconds, return FAIL). I'll apparently have to accept that this yet another mystery of how blocks work. :-) Since it is specific to blocks, I instead propose that maximum I/O time concept be part of the blocks layout specific part of the layout hint attribute. The layout hint attribute is write-only today and would remain write-only under this proposal. The client can issue SETATTR for layout hint. The client can read back what the server will actually do via the blocks layout type specific content in the results of LAYOUTGET. So no changes to NFSv4.1 needed. Some might argue that given that blocks server MUST respect the maximum I/O time in the layout hint attribute that the name "hint" is a misnomer and the attribute should be rename to say "info". I'd rather not; too much editing work for me. The pNFS blocks draft can mandate that some components of the hint be obeyed by the server. Still I'm worried that a directive by the client to server to change a 30 second SLA to 60 seconds is something not all servers are going to be able to do; I understand that many of these storage devices are relatively simple devices. So I think the pNFS blocks draft should offer fencing as an alternative to accommodate such devices. --- Glasgow_Jason@emc.com wrote: > In describing how the pNFS block client will implement fencing, it > became necessary to define the maximum time that an I/O can be > outstanding. The client needs to communicate its value to the pNFS > server. The most appropriate means of doing so seems to be to > provide a > per server R/W recommended attribute, which clients can write. > > > > I propose updating section 5.6 "Recommended Attributes - Definitions" > with the following > > > > maximum_io_time 74 uint32 R/W The default maximum time that a > client > > I/O to a data server can be > active. > > Clients may update this value. > > > > > > > > This parameter is defined in the next version of the pNFS block > layout > spec as follows: > > > > -- > > "maximum_io_time" is the maximum time it can take for a client I/O to > the storage system to either complete or fail; this value is often 30 > seconds or 60 seconds, but may be longer in some environments. . If > the > maximum client I/O time cannot be bounded, this timed lease mechanism > MUST NOT be used. The client can use GETATTR to query the server's > default setting of "maximum_io_time". The server must respond with > the > maximum I/O time in seconds. If the client's maximum I/O time is > greater than the server's default, then the client MUST use SETATTR > to > inform the server of its maximum_I/O time. > > -- > > > > Are there comments on introducing this new attribute into the NFSv4 > minor version 1 spec? Is this a valid means of communicating a > client > specific value to the server? > > > > -Jason Glasgow > > > > > > > _______________________________________________ > 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 Milly@chewinski.net Fri Nov 02 00:16:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Innx6-0005NE-QH for nfsv4-archive@lists.ietf.org; Fri, 02 Nov 2007 00:16:12 -0400 Received: from [201.244.42.251] (helo=adsl190-025074146.dyn.etb.net.co) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Innx6-0001VA-5m for nfsv4-archive@lists.ietf.org; Fri, 02 Nov 2007 00:16:12 -0400 Received: from c1as4rgao32o3tc ([140.100.141.131]:8994 "EHLO c1as4rgao32o3tc" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by adsl190-025074146.dyn.etb.net.co with ESMTP id S22NKGWCTFNOTQWZ (ORCPT ); Thu, 1 Nov 2007 23:16:25 -0500 Message-ID: <000701c81d07$19a7c0e0$924a19be@c1as4rgao32o3tc> From: "Milly Kostinsky" To: Subject: ogyzomoh Date: Thu, 1 Nov 2007 23:16:11 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C81CDD.30D1B8E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.6 (+++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0006_01C81CDD.30D1B8E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable wot up nfsv4-archive its the same size cock every year and you still haven't enlarged it http://docounty.com/ Milly Kostinsky ------=_NextPart_000_0006_01C81CDD.30D1B8E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
wot up nfsv4-archive
its the same size cock every year and you = still haven't=20 enlarged it
http://docounty.com/
Milly Kostinsky
------=_NextPart_000_0006_01C81CDD.30D1B8E0-- From AileenyonkersGranger@boston.com Fri Nov 02 00:22:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ino2x-00012a-0L; Fri, 02 Nov 2007 00:22:15 -0400 Received: from areims-157-1-85-128.w90-7.abo.wanadoo.fr ([90.7.76.128] helo=plaisanthvb4va) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ino2w-0001bq-Jc; Fri, 02 Nov 2007 00:22:14 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host02410094.boston.com (8.13.1/8.13.1) with SMTP id cVSFysqS89.346625.WVn.XxA.1321422368298 for ; Fri, 2 Nov 2007 05:21:48 -0100 Message-ID: <13ab1a01c81d07$f00057b0$0a01a8c0@plaisanthvb4va> From: "Ladonna Lanier" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_13AB16_01C81D07.F00057B0-- From nfsv4-bounces@ietf.org Fri Nov 02 07:13: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 1InuQt-00005k-Eh; Fri, 02 Nov 2007 07:11:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InuQr-000051-HW for nfsv4@ietf.org; Fri, 02 Nov 2007 07:11:21 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InuQr-0003CN-62 for nfsv4@ietf.org; Fri, 02 Nov 2007 07:11:21 -0400 X-IronPort-AV: E=Sophos;i="4.21,362,1188802800"; d="scan'208";a="118867253" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 02 Nov 2007 04:11:20 -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 lA2BBKg5011627; Fri, 2 Nov 2007 04:11:20 -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, 2 Nov 2007 04:11:20 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Nov 2007 04:11:19 -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] Boo: NFSv4.1 draft 15 is available Date: Fri, 2 Nov 2007 07:11:17 -0400 Message-ID: In-Reply-To: <20071031192950.GG4569@fieldses.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Boo: NFSv4.1 draft 15 is available Thread-Index: Acgb9awfvjtKGLXHTtyV4eSdgjVQbABS2Oaw From: "Noveck, Dave" To: "J. Bruce Fields" , "Spencer Shepler" X-OriginalArrivalTime: 02 Nov 2007 11:11:19.0627 (UTC) FILETIME=[183511B0:01C81D41] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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'll fix this.=20 -----Original Message----- From: J. Bruce Fields [mailto:bfields@fieldses.org]=20 Sent: Wednesday, October 31, 2007 3:30 PM To: Spencer Shepler Cc: NFSv4 Subject: Re: [nfsv4] Boo: NFSv4.1 draft 15 is available It looks like there was some sort of minor merge problem in the introduction; part of a sentence is duplicated here. --b. diff --git a/nfsv41_middle_introduction.xml b/nfsv41_middle_introduction.xml index 2b0781e..cd3b447 100755 --- a/nfsv41_middle_introduction.xml +++ b/nfsv41_middle_introduction.xml @@ -351,8 +351,7 @@ resources. The client may be an application which contains the logic to access the NFS server directly. The client may also be the traditional operating system client that - provides remote file system services for a set of applications. - file system services for a set of applications. + provides remote file system services for a set of applications. A client is uniquely identified by a Client Owner. _______________________________________________ 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 Padpb@cubrunbuilders.com Fri Nov 02 12:16:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InzBl-00055S-6R for nfsv4-archive@lists.ietf.org; Fri, 02 Nov 2007 12:16:05 -0400 Received: from bzq-79-177-136-191.red.bezeqint.net ([79.177.136.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InzBk-00046T-AX for nfsv4-archive@lists.ietf.org; Fri, 02 Nov 2007 12:16:05 -0400 Received: from user by cubrunbuilders.com with ASMTP id FAE540AB for ; Fri, 2 Nov 2007 18:16:36 +0200 Received: from user ([136.123.6.120]) by cubrunbuilders.com with ESMTP id 97CDA4B44687 for ; Fri, 2 Nov 2007 18:16:36 +0200 Message-ID: Date: Fri, 2 Nov 2007 18:16:02 +0200 From: "Palle P" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: nfsv4-archive@lists.ietf.org Subject: masujiro Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 3.9 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hey poppi nfsv4-archive with an extra 3 inches added, you will fill the whole condom for real http://felexinc.com/ Palle P From AllisonmeteoriteHurt@discoveryeducation.com Fri Nov 02 13:16:25 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io089-0007Kj-7p; Fri, 02 Nov 2007 13:16:25 -0400 Received: from [89.128.149.149] (helo=desktop) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Io083-00069G-6W; Fri, 02 Nov 2007 13:16:20 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host27220928.discoveryeducation.com (8.13.1/8.13.1) with SMTP id ImOLaG7d44.785632.8R1.Wo6.9241513233197 for ; Fri, 2 Nov 2007 18:15:44 -0100 Message-ID: <8d2a501c81d74$13b26790$0202a8c0@desktop> From: "Lillie Byrne" To: Subject: Your health Date: Fri, 2 Nov 2007 18:15:44 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_8D2A1_01C81D74.13B26790" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_8D2A1_01C81D74.13B26790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_8D2A1_01C81D74.13B26790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_8D2A1_01C81D74.13B26790-- From nfsv4-bounces@ietf.org Fri Nov 02 14:51:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io1ap-00059C-IC; Fri, 02 Nov 2007 14:50:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io1an-000582-Af for nfsv4@ietf.org; Fri, 02 Nov 2007 14:50:05 -0400 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io1ag-0001Vm-Ml for nfsv4@ietf.org; Fri, 02 Nov 2007 14:50:05 -0400 X-IronPort-AV: E=Sophos;i="4.21,363,1188802800"; d="scan'208";a="118981928" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 02 Nov 2007 11:49:32 -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 lA2InWeo016974 for ; Fri, 2 Nov 2007 11:49:32 -0700 (PDT) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Nov 2007 11:49:31 -0700 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Nov 2007 11:49: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 Date: Fri, 2 Nov 2007 14:49:29 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed resolutions for some pnfs-related [[Comment]] sections Thread-Index: AcgdgRm0/kF9oIJNS+iYBx5LbaH3ig== From: "Noveck, Dave" To: X-OriginalArrivalTime: 02 Nov 2007 18:49:31.0781 (UTC) FILETIME=[1ACEDB50:01C81D81] X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Subject: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections 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 trying to get rid of many [[Comment]] sections and there are a=20 few discussed below that I'd like to run by people. Let me know right away if you have an issue with any of the proposed resolutions. The first concerns the possibility which might exist for a file=20 layout type to have a COMPOUND that contains some ops addressing the server as a metadata server and others as a data server. I think we should disallow this. Here's what is in nfsv41_middle_file_layout.xml right now. Clients MUST use the filehandle described within the layout when accessing data on NFSv4.1 data servers. When using the layout's filehandle, the client MUST only issue the NULL procedure and the COMPOUND procedure's BACKCHANNEL_CTL, BIND_CONN_TO_SESSION, CREATE_SESSION, COMMIT, DESTROY_CLIENTID, DESTROY_SESSION, EXCHANGE_ID, READ, WRITE, PUTFH, SECINFO_NO_NAME, SET_SSV, and SEQUENCE operations to the NFSv4.1 data server associated with that data server filehandle. If a client issues an operation to the data server other than those specified above, using the filehandle and data server listed in the file's layout, that data server MUST return NFS4ERR_NOTSUPP to the client, unless the server's EXCHANGE_ID results returned (EXCHGID4_FLAG_USE_PNFS_DS | EXCHGID4_FLAG_USE_PNFS_MDS) or (EXCHGID4_FLAG_USE_PNFS_DS | EXCHGID4_FLAG_USE_NON_PNFS), see As described in , a client MUST NOT issue an I/O to a data server for which it does not hold a valid layout; the data server MUST reject such an I/O. We should discuss mixing of MDS and DS operations in the same compound, but need to find other places where this is discussed and move that discussion here. I don't see those other places and I'd like to replace the paragraphs above with:=09 Clients accessing data on an NFSv4.1 data server MUST issue only the NULL procedure and COMPOUND procedures whose operations are taken only from two restricted subsets of the operations defined as valid NFSv4.1=20 operations. Clients MUST use the filehandle contained=20 within the layout when accessing data on NFSv4.1 data=20 servers.=20 The first of these operation subsets consist of session management operations where the current filehandle is not relevant. This subset consists=20 of the BACKCHANNEL_CTL, BIND_CONN_TO_SESSION, CREATE_SESSION, DESTROY_CLIENTID, DESTROY_SESSION, EXCHANGE_ID, SECINFO_NO_NAME, SET_SSV, and SEQUENCE operations. The client may use these operations in order to set up and maintain the appropriate client IDs and sessions involved in communication with the data server. The second subset consists of COMMIT, READ, WRITE, PUTFH,=20 and SECINFO_NO_NAME. These operations must be used with a current filehandle taken from the=20 layout. In the case of PUTFH, the new current filehandle must be one taken from the layout. As described in , a client MUST NOT issue an I/O to a data server for which it does not hold a valid layout; the data server MUST reject such an I/O. Unless the server has a concurrent non-data-server personality, i.e. EXCHANGE_ID results returned=20 (EXCHGID4_FLAG_USE_PNFS_DS | EXCHGID4_FLAG_USE_PNFS_MDS)=20 or (EXCHGID4_FLAG_USE_PNFS_DS | EXCHGID4_FLAG_USE_NON_PNFS),=20 see , any use of operations other than those specified in the two=20 subsets above MUST return NFS4ERR_NOTSUPP to the client. When the server has concurrent data server and=20 non-data-server personalities, each COMPOUND operation is one of: A COMPOUND devoted to session/client housekeeping, which applies without distinction to both personalities. A COMPOUND which is referable to the data server personality. A COMPOUND which is referable to the non-data-server personality. It is not allowed for a single COMPOUND to contain operations acting on both individual personalities, although an COMPOUND pertaining to a single individual personality may contain housekeeping operation which affect both personalities. When a COMPOUND first executes an operation which is not part of one of the two sets above, or when it executes a PUTFH containing a filehandle not derived from a layout, it acts as a normal COMPOUND on any other server and the=20 data server personality ceases to be relevant.=20 There are no special restrictions on the=20 operations in the COMPOUND to limit then to those for a data server. When a PUTFH is done, filehandles derived from the layout are not valid. If their format is not normally acceptable, then NFS4ERR_BADHANDLE MUST result. Similarly, current filehandles for other operations do not accept filehandles derived from layouts and these will result in NFS4ERR_STALE.=20 When a COMPOUND first executes a PUTFH where the filehandle is one from a layout, the COMPOUND henceforth is interpreted with respect to the data server personality. In particular, operations outside the two classes discussed above MUST result in NFS4ERR_NOTSUPP and filehandles are validated using the rules of the data server, resulting in NFS4ERR_BADHANDLE and/or NFS4ERR_STALE even when they would not normally do so when addressed to the non-data-server personality. =09 The next item relates to stateids and IO mode validations:
Open and deny mode validation MUST be performed against the open and deny mode(s) held by the data servers. When access is reduced or a deny mode made more restrictive (because of CLOSE or DOWNGRADE) the data server MUST prevent any I/Os that would be denied if performed on the metadata server. Conversely, when access is expanded, the data server MUST NOT reject a request because of open or deny issues without making sure that the open mode upgrade or deny mode relaxation is not in progress. It seems like the recent (June/July 2007) stateid.seqid discussion might modify this; a client might send a new state.seqid, that tells the data server it's seqid is out of date; the data server might return NFS4ERR_DELAY.
=09 In addition to the cref section there seems to me to be confusion in the other parts of this and adjoining sections. The big issue is that there is discussion of getting stateid seqids right but that seems to me pointless complexity for the data server. Given parallel open the general pattern will be to use seqid=3D0 and only use non-zero seqid for a few special operation like OPEN_DOWNGRADE and CLOSE, none of which is going to be sent to the data server. So I'm proposing that the stateids for the data server always have seqid as zero and you get BAD_STATEID if not. Another thing that is wrong about this section is the discussion of deny modes. Deny modes have their effect at open time, and, unless we have IO's with special stateids (which I believe are not allowed)=20 do not affect IO's. Also, "without making sure that the open mode upgrade or deny mode=20 relaxation is not in progress" seems flat-out wrong. You can never=20 be assured that it is not in progress when you actually do the rejection. If you check that it is not an a given instant and the proceed to do the rejection, it might be in progress when you actually do the rejection. All you should check is that it hasn't previously been made allowable. We have the following issue with access time in LAYOUTCOMMIT: The loca_time_modify and loca_time_access If LAYOUTCOMMIT is only for writes, then why update access time? fields allow the client to suggest times it would like the metadata server to set. The metadata server may use these time values or it may use the time of the LAYOUTCOMMIT operation to set these time values. If the metadata server uses the client provided times, it should ensure time does not flow backwards. If the client wants to force the metadata server to set an exact time, the client should use a SETATTR operation in a compound right after LAYOUTCOMMIT. See for more details. If the new client desires the resultant mtime or atime, it should construct the COMPOUND so that a GETATTR follows the LAYOUTCOMMIT. The issue of loca_access_time was discussed at the pnfs review but as I understand things, there was no resolution that got universal approval. The simplest thing, which I'm going to propose, if nobody has a better idea, is simply to get of rid loca_access_time. Also we have the following inconsistent paragraphs: When lr_returntype is LAYOUTRETURN4_FILE, the layout being returned may be a subdivision of a layout previously obtained with LAYOUTGET. The layout being returned may also be a subset or superset of a layout specified by CB_LAYOUTRECALL. However, if it is a subset, the recall is not complete until the full recalled scope has been returned. Recalled scope refers to the octet range in the case of LAYOUTRETURN4_FILE, use of LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. It is also permissible, and no error should result, for a client to return a octet range covering a layout it does not hold. If the lrf_length is all 1s, the layout covers the range from lrf_offset to EOF. And, If the layout identified in the arguments does not exist, the error NFS4ERR_BADLAYOUT is returned. If a layout exists, but the iomode does not match, NFS4ERR_BADIOMODE is returned.=20 =20 This error return description does not align with the statement above that the client should not receive an error when it returns a layout that it does not hold.=20 =09 It appears to me that the intent of the first paragraph cited was to=20 simplify the job of the client, particularly in those cases (like the file layout type) where layouts are simple so that it can avoid detailed logic to keep precise track of the octet ranges for which it has a layout. =20 On the other hand, having the server be unable to report cases in which=20 a the client has lost its mind is troublesome. Here's my suggested=20 resolution. When lr_returntype is LAYOUTRETURN4_FILE, the layout being returned may be a subdivision of a layout previously obtained with LAYOUTGET. The layout being returned may also be a subset or superset of a layout specified by CB_LAYOUTRECALL. However, if it is a subset, the recall is not complete until the full recalled scope has been returned. Recalled scope refers to the octet range in the case of LAYOUTRETURN4_FILE, use of LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. It is also permissible, and no error should result, for a client to return an octet range covering a layout it does not currently hold, as long as it, at some time held a layout for some octet range of file in question. If the lrf_length is all 1s, the layout covers=20 the range from lrf_offset to the last octet for which the client=20 actually holds a layout. And, If it determinable that layout identified in the argument is such that the client could never have possessed a layout for that file (of any octet range) NFS4ERR_BADLAYOUT should be returned. If a=20 layout exists, but the iomode does not match, NFS4ERR_BADIOMODE=20 is returned.=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From RochellepreachyCornett@3fatchicks.com Fri Nov 02 15:06:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io1qR-0005AD-KY; Fri, 02 Nov 2007 15:06:15 -0400 Received: from 157.pool85-60-108.dynamic.orange.es ([85.60.108.157] helo=suduca.lan) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Io1qL-0002En-OV; Fri, 02 Nov 2007 15:06:10 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host42666788.3fatchicks.com (8.13.1/8.13.1) with SMTP id Cw3gJH3u93.030324.T5f.zWy.3970654701757 for ; Fri, 2 Nov 2007 20:05:46 -0100 Message-ID: From: "Laverne Cano" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_AFE64_01C81D83.6ABF43A0-- From nfsv4-bounces@ietf.org Fri Nov 02 17:46:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io4KG-0000P7-Hk; Fri, 02 Nov 2007 17:45:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io4KF-0000OY-Nn for nfsv4@ietf.org; Fri, 02 Nov 2007 17:45:11 -0400 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io4KA-0001a7-6k for nfsv4@ietf.org; Fri, 02 Nov 2007 17:45:11 -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 lA2Limms007987; Fri, 2 Nov 2007 17:44:48 -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 lA2LiMpj024132; Fri, 2 Nov 2007 17:44:47 -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); Fri, 2 Nov 2007 17:44:41 -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] Request for an additional recommended attribute Date: Fri, 2 Nov 2007 17:44:40 -0400 Message-ID: <39CF2A4B63947142A66EAA65B2FDF2F005C372C3@CORPUSMX40A.corp.emc.com> In-Reply-To: <208235.27820.qm@web38104.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Request for an additional recommended attribute Thread-Index: Acgc90sRQjryKnbLSc+uFrTLBXzV+AAgCgzg References: <39CF2A4B63947142A66EAA65B2FDF2F005612D59@CORPUSMX40A.corp.emc.com> <208235.27820.qm@web38104.mail.mud.yahoo.com> To: , X-OriginalArrivalTime: 02 Nov 2007 21:44:41.0753 (UTC) FILETIME=[933D5090:01C81D99] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=1%, Reason='EMC_FROM_0+ -3, NO_REAL_NAME 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: -4.0 (----) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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 Mike, I am happy to use the layout hint to communicate to the server. I will update the block spec accordingly. I agree that "hint" is now a misnomer, but I can live with that. As to changing the SLA from 30 to 60 seconds, the block spec will be updated to allow for two behaviors. I'm working on the exact wording, but it will be something like: A server which implements fencing can accept any maximum timeout value from a client, and then fence the storage immediately if the lease expires. A server which does not implement fencing and does not wish to change the SLA, can return an error to the SETATTR operation. When a client receives the error NFS4ERR_INVAL in response to the SETATTR operation for layout hints, the client MUST NOT use the LAYOUTGET operation. After responding with NFS4ERR_INVAL to the SETATTR for layout hint, the server MUST return an error to all subsequent LAYOUTGET operations from that client. I think this should address your concerns. -Jason -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Thursday, November 01, 2007 10:13 PM To: nfsv4@ietf.org Subject: Re: [nfsv4] Request for an additional recommended attribute Dave Noveck has tried to explain to me many times why Jason's proposal says: > If the client's maximum I/O time is > greater than the server's default, then the client MUST use SETATTR > to > inform the server of its maximum_I/O time. And I'm not getting it. To me, if the server has a guarantee of 30 seconds to either definitively fail to do, or succeed to do the I/O, then if client wants 60 seconds, a 30 second guarantee is semantically the same (stop the I/O after 30 seconds if not done; suspend for 30 more seconds, return FAIL). I'll apparently have to accept that this yet another mystery of how blocks work. :-) Since it is specific to blocks, I instead propose=20 that maximum I/O time concept be part of the blocks layout specific part of the layout hint attribute. The layout hint attribute is write-only today and would remain write-only under this proposal. The client can issue SETATTR for layout hint. The client can read back what the server will actually do via the blocks layout type specific content in the results of LAYOUTGET.=20 So no changes to NFSv4.1 needed. Some might argue that given that blocks server MUST respect the maximum I/O time in the layout hint attribute that the=20 name "hint" is a misnomer and the attribute should be rename to say "info". I'd rather not; too much editing work for me.=20 The pNFS blocks draft can mandate that some components=20 of the hint be obeyed by the server. Still I'm worried that a directive by the client to server to change a 30 second SLA to 60 seconds is something not all servers are going to be able to do; I understand that many of these storage devices are relatively simple devices. So I think the pNFS blocks draft should offer fencing as an alternative to accommodate such devices. --- Glasgow_Jason@emc.com wrote: > In describing how the pNFS block client will implement fencing, it > became necessary to define the maximum time that an I/O can be > outstanding. The client needs to communicate its value to the pNFS > server. The most appropriate means of doing so seems to be to > provide a > per server R/W recommended attribute, which clients can write. >=20 > =20 >=20 > I propose updating section 5.6 "Recommended Attributes - Definitions" > with the following >=20 > =20 >=20 > maximum_io_time 74 uint32 R/W The default maximum time that a > client >=20 > I/O to a data server can be > active. >=20 > Clients may update this value. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > This parameter is defined in the next version of the pNFS block > layout > spec as follows: >=20 > =20 >=20 > -- >=20 > "maximum_io_time" is the maximum time it can take for a client I/O to > the storage system to either complete or fail; this value is often 30 > seconds or 60 seconds, but may be longer in some environments. . If > the > maximum client I/O time cannot be bounded, this timed lease mechanism > MUST NOT be used. The client can use GETATTR to query the server's > default setting of "maximum_io_time". The server must respond with > the > maximum I/O time in seconds. If the client's maximum I/O time is > greater than the server's default, then the client MUST use SETATTR > to > inform the server of its maximum_I/O time. >=20 > -- >=20 > =20 >=20 > Are there comments on introducing this new attribute into the NFSv4 > minor version 1 spec? Is this a valid means of communicating a > client > specific value to the server? >=20 > -Jason Glasgow >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From KerritriangulumCope@wikipedia.org Fri Nov 02 19:35:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io63C-0001qi-0O; Fri, 02 Nov 2007 19:35:42 -0400 Received: from pool-70-19-164-88.bos.east.verizon.net ([70.19.164.88] helo=dell3000.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Io630-0007qc-4o; Fri, 02 Nov 2007 19:35:31 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host51979348.wikipedia.org (8.13.1/8.13.1) with SMTP id 2PoAyPWn04.468083.ITO.gt4.9394247530043 for ; Fri, 2 Nov 2007 19:28:19 +0500 Message-ID: <1bdeb01c81db0$7daa9500$6402a8c0@dell3000> From: "Kerri Marcum" To: Subject: Confirmation link Date: Fri, 2 Nov 2007 19:28:19 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1BDE7_01C81DB0.7DAA9500" 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: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_1BDE7_01C81DB0.7DAA9500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_1BDE7_01C81DB0.7DAA9500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1BDE7_01C81DB0.7DAA9500-- From MalcolmgerminalVega@frenchquarter.com Fri Nov 02 22:34:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io8qg-0001An-Vi; Fri, 02 Nov 2007 22:34:59 -0400 Received: from chello084113135147.1.13.vie.surfer.at ([84.113.135.147] helo=mirko3275dd0d1.chello.at) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Io8qb-0005jX-FH; Fri, 02 Nov 2007 22:34:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host56541753.frenchquarter.com (8.13.1/8.13.1) with SMTP id qLSFDnwI15.977480.dJS.Ybw.8680629119284 for ; Sat, 3 Nov 2007 03:34:05 -0100 Message-ID: <8d61001c81dc2$0c7fc460$93877154@mirko3275dd0d1> From: "Horace Reeves" To: Subject: Confirmation link Date: Sat, 3 Nov 2007 03:34:05 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_8D60C_01C81DC2.0C7FC460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_8D60C_01C81DC2.0C7FC460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_8D60C_01C81DC2.0C7FC460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_8D60C_01C81DC2.0C7FC460-- From MaynardstaminaJuarez@aacap.org Sat Nov 03 01:10:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoBHM-0004Ai-34; Sat, 03 Nov 2007 01:10:40 -0400 Received: from [189.152.40.2] (helo=lupita) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IoBHB-0002Tu-4b; Sat, 03 Nov 2007 01:10:29 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host19724639.aacap.org (8.13.1/8.13.1) with SMTP id tjZD5NUv72.868398.HPB.VoT.5327609986438 for ; Fri, 2 Nov 2007 23:09:51 +0600 Message-ID: <1722e601c81dcf$70d19bc0$373ea8c0@LUPITA> From: "Vince Kent" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1722E2_01C81DCF.70D19BC0-- From TracyskullduggeryFlanagan@universalis.com Sat Nov 03 04:56:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoEnT-0001mQ-IU; Sat, 03 Nov 2007 04:56:03 -0400 Received: from [125.93.161.33] (helo=youra4702795f4) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IoEnS-0000Wx-JH; Sat, 03 Nov 2007 04:56:03 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host57519077.universalis.com (8.13.1/8.13.1) with SMTP id KSuTWdgt82.125613.UKr.Rad.0627961872602 for ; Sat, 3 Nov 2007 16:55:12 -0800 Message-ID: <22a3a01c81df7$57575d10$4900a8c0@youra4702795f4> From: "Rita Escobar" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_22A36_01C81DF7.57575D10-- From Gyorky@avocats.ca Sat Nov 03 08:22:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoI1i-0005f6-7F for nfsv4-archive@lists.ietf.org; Sat, 03 Nov 2007 08:22:58 -0400 Received: from host157-114-dynamic.5-87-r.retail.telecomitalia.it ([87.5.114.157] helo=host152-116-dynamic.0-87-r.retail.telecomitalia.it) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IoI1h-00078W-EB for nfsv4-archive@lists.ietf.org; Sat, 03 Nov 2007 08:22:58 -0400 Received: from angelo ([144.196.159.180] helo=angelo) by host152-116-dynamic.0-87-r.retail.telecomitalia.it ( sendmail 8.13.3/8.13.1) with esmtpa id 1WlvUL-000HZT-iA for nfsv4-archive@lists.ietf.org; Sat, 3 Nov 2007 13:23:36 +0100 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 3 Nov 2007 13:23:11 +0100 To: nfsv4-archive@lists.ietf.org From: "Lynnley Gyorky" Subject: hitachik Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.8 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea hello pal nfsv4-archive you may be compatible with her but what does she think of your dick size? http://ezeyjob.com/ Lynnley Gyorky From LowelllengthYates@oracle.com Sat Nov 03 15:31:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoOic-0002rB-1P; Sat, 03 Nov 2007 15:31:42 -0400 Received: from [189.132.168.223] (helo=compaq2) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IoOib-00053D-4l; Sat, 03 Nov 2007 15:31:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host07307841.oracle.com (8.13.1/8.13.1) with SMTP id TsxmGabg52.328012.Qns.lMM.8905488811097 for ; Sat, 3 Nov 2007 13:30:53 +0600 Message-ID: <1dfa201c81e50$1a23f440$0101a8c0@compaq2> From: "Roosevelt Patton" To: Subject: Your life Date: Sat, 3 Nov 2007 13:30:53 +0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1DF9E_01C81E50.1A23F440" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_1DF9E_01C81E50.1A23F440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_1DF9E_01C81E50.1A23F440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1DF9E_01C81E50.1A23F440-- From UlyssesfiduciaryAyers@washingtonpost.com Sat Nov 03 17:51:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoQuC-0005Gy-Jy; Sat, 03 Nov 2007 17:51:48 -0400 Received: from [77.224.29.179] (helo=home11b5acb8cd) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IoQuC-0002DT-6K; Sat, 03 Nov 2007 17:51:48 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host29811785.washingtonpost.com (8.13.1/8.13.1) with SMTP id FjewDgFr73.239794.pkx.7Aq.3545555661629 for ; Sat, 3 Nov 2007 22:51:36 -0100 Message-ID: <1f10d01c81e63$bf503740$3901a8c0@home11b5acb8cd> From: "Jefferson Gentry" To: Subject: Confirmation link Date: Sat, 3 Nov 2007 22:51:36 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1F109_01C81E63.BF503740" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_1F109_01C81E63.BF503740 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_1F109_01C81E63.BF503740 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1F109_01C81E63.BF503740-- From JeanettegibbsDelarosa@clintonchamber.com Sat Nov 03 22:14:03 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoUzz-0000SZ-TO; Sat, 03 Nov 2007 22:14:03 -0400 Received: from [87.109.201.19] (helo=yasch18ebd40db) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IoUzu-0004CS-TH; Sat, 03 Nov 2007 22:14:03 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by host61018813.clintonchamber.com (8.13.1/8.13.1) with SMTP id usxgKdsg38.634505.dMe.uIm.3917591722066 for ; Sun, 4 Nov 2007 05:28:25 -0300 Message-ID: <2daad01c81e8a$7959d670$0400000a@yasch18ebd40db> From: "Laurie Mata" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_2DAA9_01C81E8A.7959D670-- From nfsv4-bounces@ietf.org Sun Nov 04 01:59:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoZSX-0005i0-Bo; Sun, 04 Nov 2007 01:59:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoZSW-0005hB-4D for nfsv4@ietf.org; Sun, 04 Nov 2007 01:59:48 -0500 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 1IoZSV-0001Gv-1R for nfsv4@ietf.org; Sun, 04 Nov 2007 01:59:47 -0500 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 lA4726Vs022061; Sun, 4 Nov 2007 02:02:07 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 4 Nov 2007 02:02:06 -0500 Received: from bh-buildlin1.bhalevy.com ([172.17.28.148]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Nov 2007 01:59:03 -0500 Message-ID: <472D6DE0.7090505@panasas.com> Date: Sun, 04 Nov 2007 08:59:44 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Noveck, Dave" Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Nov 2007 06:59:03.0370 (UTC) FILETIME=[2F1F0AA0:01C81EB0] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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 Nov. 02, 2007, 20:49 +0200, "Noveck, Dave" wrote: > I'm trying to get rid of many [[Comment]] sections and there are a > few discussed below that I'd like to run by people. Let me know > right away if you have an issue with any of the proposed resolutions. > > The first concerns the possibility which might exist for a file > layout type to have a COMPOUND that contains some ops addressing > the server as a metadata server and others as a data server. I > think we should disallow this. > > > It is not allowed for a single COMPOUND to contain operations > acting on both individual personalities, although an COMPOUND > pertaining to a single individual personality may contain > housekeeping operation which affect both personalities. > This makes sense to me. > > The next item relates to stateids and IO mode validations: > >
> > Open and deny mode validation MUST be performed against > the open and deny mode(s) held by the data servers. When > access is reduced or a deny mode made more restrictive > (because of CLOSE or DOWNGRADE) the data server MUST > prevent any I/Os that would be denied if performed on the > metadata server. Conversely, when access is expanded, > the data server MUST NOT reject a request because of > open or deny issues without making sure that the open > mode upgrade or deny mode relaxation is not in progress. > > It seems like the recent (June/July 2007) > stateid.seqid discussion might modify this; > a client might send a new state.seqid, that tells the data server > it's seqid is out of date; the data server might return > NFS4ERR_DELAY. > > > >
> > In addition to the cref section there seems to me to be confusion > in the other parts of this and adjoining sections. The big issue > is that there is discussion of getting stateid seqids right but > that seems to me pointless complexity for the data server. Given > parallel open the general pattern will be to use seqid=0 and only > use non-zero seqid for a few special operation like OPEN_DOWNGRADE > and CLOSE, none of which is going to be sent to the data server. > > So I'm proposing that the stateids for the data server always have > seqid as zero and you get BAD_STATEID if not. I thought that the client should just use the most recent stateid returned to it by the MDS, as per 14.10.1: "When the client issues I/O to a data server, the stateid used must be one previously returned by the metadata server. Permitted stateids include an open stateid (the stateid field of data type OPEN4resok as returned by OPEN), a delegation stateid (the stateid field of data types open_read_delegation4 and open_write_delegation4 as returned by OPEN or WANT_DELEGATION, or as sent by CB_PUSH_DELEG), or a stateid returned by the LOCK or LOCKU operations." > > Another thing that is wrong about this section is the discussion of > deny modes. Deny modes have their effect at open time, and, unless > we have IO's with special stateids (which I believe are not allowed) > do not affect IO's. Right > > Also, "without making sure that the open mode upgrade or deny mode > relaxation is not in progress" seems flat-out wrong. You can never > be assured that it is not in progress when you actually do the > rejection. > If you check that it is not an a given instant and the proceed to > do the rejection, it might be in progress when you actually do the > rejection. All you should check is that it hasn't previously been > made allowable. > > We have the following issue with access time in LAYOUTCOMMIT: > > > The loca_time_modify and loca_time_access If LAYOUTCOMMIT > is only for writes, then why update access time? fields > allow the client to suggest times it would like the metadata > server to set. The metadata server may use these time values or > it may use the time of the LAYOUTCOMMIT operation to set these > time values. If the metadata server uses the client provided > times, it should ensure time does not flow backwards. If the > client wants to force the metadata server to set an exact time, > the client should use a SETATTR operation in a compound right > after LAYOUTCOMMIT. See for > more details. If the new client desires the resultant mtime or > atime, it should construct the COMPOUND so that a GETATTR > follows the LAYOUTCOMMIT. > > > The issue of loca_access_time was discussed at the pnfs review but as > I understand things, there was no resolution that got universal > approval. The simplest thing, which I'm going to propose, if nobody > has a better idea, is simply to get of rid loca_access_time. I object to doing that. Since the MDS does intercept the I/Os going to the DSs loca_access_time will be useful to the MD server, otherwise, if it supports atime (and is configured to track it), it will be forced to get the atime from all the file's DSs which can have a significant hit on performance. Note that unlike an explicit SETATTR this value is basically a hint and the server does not have to respect it. Also, I would like the spec to be clear about allowing LAYOUTCOMMIT for reads as this is still needed for the objects layout type for reporting read errors. > > Also we have the following inconsistent paragraphs: > > > When lr_returntype is LAYOUTRETURN4_FILE, the layout being > returned may be a subdivision of a layout previously obtained > with LAYOUTGET. The layout being returned may also be a subset > or superset of a layout specified by CB_LAYOUTRECALL. However, > if it is a subset, the recall is not complete until the full > recalled scope has been returned. Recalled scope refers to the > octet range in the case of LAYOUTRETURN4_FILE, use of > LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. It > is also permissible, and no error should result, for a client to > return a octet range covering a layout it does not hold. If the > lrf_length is all 1s, the layout covers the range from > lrf_offset to EOF. > > > And, > > > If the layout identified in the arguments does not exist, the > error > NFS4ERR_BADLAYOUT is returned. If a layout exists, but the iomode > does not match, NFS4ERR_BADIOMODE is returned. > > This error > return description does not align with the statement above that > the client should not receive an error when it returns a layout > that it does not hold. > > > > It appears to me that the intent of the first paragraph cited was to > simplify the job of the client, particularly in those cases (like the > file layout type) where layouts are simple so that it can avoid detailed > logic to keep precise track of the octet ranges for which it has a > layout. > On the other hand, having the server be unable to report cases in which > a the client has lost its mind is troublesome. Here's my suggested > resolution. > > > When lr_returntype is LAYOUTRETURN4_FILE, the layout being > returned may be a subdivision of a layout previously obtained > with LAYOUTGET. The layout being returned may also be a subset > or superset of a layout specified by CB_LAYOUTRECALL. However, > if it is a subset, the recall is not complete until the full > recalled scope has been returned. Recalled scope refers to the > octet range in the case of LAYOUTRETURN4_FILE, use of > LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. It > is also permissible, and no error should result, for a client to > return an octet range covering a layout it does not currently > hold, > as long as it, at some time held a layout for some octet range of > file in question. If the lrf_length is all 1s, the layout covers > the range from lrf_offset to the last octet for which the client > actually holds a layout. > > > And, > > > If it determinable that layout identified in the argument is such > that the client could never have possessed a layout for that file > (of any octet range) NFS4ERR_BADLAYOUT should be returned. If a > layout exists, but the iomode does not match, NFS4ERR_BADIOMODE > is returned. > I'm OK with that. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From JacklyngenoaSchulz@metacafe.com Sun Nov 04 03:26:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ioaoj-0005f1-WD; Sun, 04 Nov 2007 03:26:50 -0500 Received: from [189.154.11.34] (helo=personalc0e49a.gateway.2wire.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ioaoi-0004WX-WD; Sun, 04 Nov 2007 03:26:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host22356297.metacafe.com (8.13.1/8.13.1) with SMTP id 8OZ5AoSj36.357012.L86.zat.0558748330306 for ; Sun, 4 Nov 2007 01:25:32 +0800 Message-ID: <52b9201c81ebc$6a0e0dd0$be01a8c0@personalc0e49a> From: "Madeleine Skaggs" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_52B8E_01C81EBC.6A0E0DD0-- From TylererdaFranklin@mathpower.com Sun Nov 04 05:37:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iocre-0006wC-5P; Sun, 04 Nov 2007 05:37:58 -0500 Received: from 71-33-17-208.bois.qwest.net ([71.33.17.208] helo=valuedvprmatrix.domain.actdsltmp) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iocrd-0006Wg-Hr; Sun, 04 Nov 2007 05:37:57 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host17372067.mathpower.com (8.13.1/8.13.1) with SMTP id ErnqY3Jj41.198317.EJH.VUR.2117141729537 for ; Sun, 4 Nov 2007 03:38:18 +0700 Message-ID: <6037a01c81ece$daa5e2e0$0400a8c0@ValuedVPRMatrix> From: "Herman Fox" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_60376_01C81ECE.DAA5E2E0-- From EdmondstowawayMckenzie@intellicast.com Sun Nov 04 08:06:58 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IofBq-0001SH-Gu; Sun, 04 Nov 2007 08:06:58 -0500 Received: from [201.254.178.93] (helo=mdac515dd48884) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IofBp-0004XU-Sw; Sun, 04 Nov 2007 08:06:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host27097691.intellicast.com (8.13.1/8.13.1) with SMTP id cnZ2QYD672.608114.qjV.tyc.4524274982011 for ; Sun, 4 Nov 2007 10:06:32 +0300 Message-ID: From: "Emmett Collier" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_EFDAD_01C81EE3.91B13B60-- From nfsv4-bounces@ietf.org Sun Nov 04 11:48: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 1IoieG-0008Ai-Qe; Sun, 04 Nov 2007 11:48:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoieF-00089u-Jw for nfsv4@ietf.org; Sun, 04 Nov 2007 11:48:31 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IoieE-0005EI-T6 for nfsv4@ietf.org; Sun, 04 Nov 2007 11:48:31 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA4GmU1l024691 for ; Sun, 4 Nov 2007 16:48:30 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQZ00101QHG5P00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Sun, 04 Nov 2007 09:48:30 -0700 (MST) Received: from [10.0.1.195] ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQZ00BQYQOTMO50@mail-amer.sun.com>; Sun, 04 Nov 2007 09:48:30 -0700 (MST) Date: Sun, 04 Nov 2007 10:48:28 -0600 From: Robert Gordon Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections In-reply-to: To: "Noveck, Dave" Message-id: <2BA59712-49B1-41E2-BD90-26DCC7A06ED7@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 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Nov 2, 2007, at 1:49 PM, Noveck, Dave wrote: > > Clients accessing data on an NFSv4.1 data server MUST issue > only the NULL procedure and COMPOUND procedures whose > operations are taken only from two restricted > subsets of the operations defined as valid NFSv4.1 > operations. Clients MUST use the filehandle contained > within the layout when accessing data on NFSv4.1 data > servers. > strictly speaking the last sentence is not true; since the filehandle may be the MDS filehandle, and that is not conveyed in the layout. Perhaps: "Clients MUST use the correct filehandle defined by the layout when accessing data on NFSv4.1 data servers. " Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From DorothycriedMayfield@counterterrorismblog.org Sun Nov 04 12:19:32 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ioj8G-0003kn-K2; Sun, 04 Nov 2007 12:19:32 -0500 Received: from [190.67.113.21] (helo=daniel) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ioj8F-0004Ah-9H; Sun, 04 Nov 2007 12:19:32 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host29418107.counterterrorismblog.org (8.13.1/8.13.1) with SMTP id QKN3mI4i36.044386.3BS.PHU.8081908794207 for ; Sun, 4 Nov 2007 12:20:16 +0500 Message-ID: <355f01c81f07$073cb3f0$1401a8c0@daniel> From: "Lisa Rankin" To: Subject: Your life Date: Sun, 4 Nov 2007 12:20:16 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_355B_01C81F07.073CB3F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 3.6 (+++) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_355B_01C81F07.073CB3F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_355B_01C81F07.073CB3F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_355B_01C81F07.073CB3F0-- From nfsv4-bounces@ietf.org Sun Nov 04 12:19:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ioj8f-00042B-0p; Sun, 04 Nov 2007 12:19:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ioj8e-00041g-Ec for nfsv4@ietf.org; Sun, 04 Nov 2007 12:19:56 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ioj8c-0004BZ-BB for nfsv4@ietf.org; Sun, 04 Nov 2007 12:19:56 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA4HJrC8027392 for ; Sun, 4 Nov 2007 17:19:53 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQZ00A01S0HLK00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Sun, 04 Nov 2007 10:19:53 -0700 (MST) Received: from [10.0.1.195] ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQZ00BAYS55MO90@mail-amer.sun.com>; Sun, 04 Nov 2007 10:19:53 -0700 (MST) Date: Sun, 04 Nov 2007 11:19:52 -0600 From: Robert Gordon Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections In-reply-to: To: "Noveck, Dave" Message-id: <21557211-0C05-47B4-9966-3E769FE5CE26@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 References: X-Spam-Score: -1.0 (-) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Nov 2, 2007, at 1:49 PM, Noveck, Dave wrote: > > It is not allowed for a single COMPOUND to contain operations > acting on both individual personalities, although an COMPOUND > pertaining to a single individual personality may contain > housekeeping operation which affect both personalities. > > > When a COMPOUND first executes an operation which is not > part of one of the two sets above, or when it executes a > PUTFH containing a filehandle not derived from a layout, > it acts as a normal COMPOUND on any other server and the > data server personality ceases to be relevant. > There are no special restrictions on the > operations in the COMPOUND to limit then to those for > a data server. When a PUTFH is done, filehandles > derived from the layout are not valid. If their format > is not normally acceptable, then NFS4ERR_BADHANDLE MUST > result. Similarly, current filehandles for other operations > do not accept filehandles derived from layouts and these > will result in NFS4ERR_STALE. > > > When a COMPOUND first executes a PUTFH where the filehandle > is one from a layout, the COMPOUND henceforth is interpreted > with respect to the data server personality. In > particular, operations outside the two classes discussed > above MUST result in NFS4ERR_NOTSUPP and filehandles > are validated using the rules of the data server, > resulting in NFS4ERR_BADHANDLE and/or NFS4ERR_STALE > even when they would not normally do so when addressed > to the non-data-server personality. > "It is not allowed" -- should that be a SHOULD NOT or MUST NOT ? Since the filehandle could be the MDS filehandle; I'm not sure that the server can distinguish which personality the PUTFH pertains to.. But maybe that is your point ? -- if it is then we need to be clearer :) -- Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Nov 04 13:25: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 1IokAG-0002UB-PK; Sun, 04 Nov 2007 13:25:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IokAF-0002T7-HX for nfsv4@ietf.org; Sun, 04 Nov 2007 13:25:39 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IokAE-0000qI-C5 for nfsv4@ietf.org; Sun, 04 Nov 2007 13:25:39 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA4IPb4w017876 for ; Sun, 4 Nov 2007 18:25:37 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JQZ00401V2R6P00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Sun, 04 Nov 2007 11:25:37 -0700 (MST) Received: from [10.0.1.195] ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JQZ00B0NV6OMOG0@mail-amer.sun.com>; Sun, 04 Nov 2007 11:25:37 -0700 (MST) Date: Sun, 04 Nov 2007 12:25:35 -0600 From: Robert Gordon Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections In-reply-to: <472D6DE0.7090505@panasas.com> To: Benny Halevy , Dave Noveck 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: <472D6DE0.7090505@panasas.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Nov 4, 2007, at 1:59 AM, Benny Halevy wrote: >> In addition to the cref section there seems to me to be confusion >> in the other parts of this and adjoining sections. The big issue >> is that there is discussion of getting stateid seqids right but >> that seems to me pointless complexity for the data server. Given >> parallel open the general pattern will be to use seqid=0 and only >> use non-zero seqid for a few special operation like OPEN_DOWNGRADE >> and CLOSE, none of which is going to be sent to the data server. >> >> So I'm proposing that the stateids for the data server always have >> seqid as zero and you get BAD_STATEID if not. > > I thought that the client should just use the most recent stateid > returned > to it by the MDS, as per 14.10.1: > "When the client issues I/O to a data server, the stateid used must > be one > previously returned by the metadata server. Permitted stateids > include an > open stateid (the stateid field of data type OPEN4resok as returned > by OPEN), > a delegation stateid (the stateid field of data types > open_read_delegation4 > and open_write_delegation4 as returned by OPEN or WANT_DELEGATION, > or as > sent by CB_PUSH_DELEG), or a stateid returned by the LOCK or LOCKU > operations." I think that Dave is going to update that text.. or in the process of.. I think using zero in the stateid sequence field is okay. We also need to say that the client should use either the OPEN or DELEGATION stateid, and may use the lock stateid (with the most recent sequence id) if mandatory locking is implemented. Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From LulaawkwardQuintana@foxnews.com Sun Nov 04 15:13:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iolqp-0001tq-17; Sun, 04 Nov 2007 15:13:43 -0500 Received: from pool-68-239-57-213.bos.east.verizon.net ([68.239.57.213] helo=familyroom) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iolqo-0005Gq-EW; Sun, 04 Nov 2007 15:13:42 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host85658298.foxnews.com (8.13.1/8.13.1) with SMTP id c5pmmevL48.193144.smt.L0g.9501590345112 for ; Sun, 4 Nov 2007 15:13:33 +0500 Message-ID: <27cb201c81f1f$36915300$6401a8c0@familyroom> From: "Kristine Murdock" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_27CAE_01C81F1F.36915300-- From nfsv4-bounces@ietf.org Sun Nov 04 19:11:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IopYP-0002WZ-5S; Sun, 04 Nov 2007 19:10:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IopYO-0002V9-2X for nfsv4@ietf.org; Sun, 04 Nov 2007 19:10:56 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IopYN-0005WM-MZ for nfsv4@ietf.org; Sun, 04 Nov 2007 19:10:55 -0500 X-IronPort-AV: E=Sophos;i="4.21,369,1188802800"; d="scan'208";a="119519528" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 04 Nov 2007 16:10:47 -0800 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 lA50AkkK006435; Sun, 4 Nov 2007 16:10:46 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Nov 2007 16:10:46 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Nov 2007 16:10:46 -0800 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] Proposed resolutions for some pnfs-related [[Comment]]sections Date: Sun, 4 Nov 2007 19:10:43 -0500 Message-ID: In-Reply-To: <2BA59712-49B1-41E2-BD90-26DCC7A06ED7@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]]sections Thread-Index: AcgfApUqtRVLWj59Rg2Mupt0bVXkuwAPNW5A From: "Noveck, Dave" To: "Robert Gordon" X-OriginalArrivalTime: 05 Nov 2007 00:10:46.0175 (UTC) FILETIME=[50117AF0:01C81F40] 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 > strictly speaking the last sentence is not true;=20 Why not? > since the filehandle may be the MDS filehandle,=20 Where does the current spec say that? > and that is not conveyed in the layout. Probably not. In draft-15, the first sentence of section 14.7 is: Clients MUST use the filehandle described within the layout when accessing data on NFSv4.1 data servers.=20 That doesn't sound to me the like the filehandle may be the MDS filehandle. My intention was not change the spec in this regard. Is there some other text that allows this? -----Original Message----- From: Robert Gordon [mailto:Robert.Gordon@Sun.COM]=20 Sent: Sunday, November 04, 2007 11:48 AM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]]sections On Nov 2, 2007, at 1:49 PM, Noveck, Dave wrote: > > Clients accessing data on an NFSv4.1 data server MUST issue > only the NULL procedure and COMPOUND procedures whose > operations are taken only from two restricted > subsets of the operations defined as valid NFSv4.1 > operations. Clients MUST use the filehandle contained > within the layout when accessing data on NFSv4.1 data > servers. > strictly speaking the last sentence is not true; since the filehandle may be the MDS filehandle, and that is not conveyed in the layout. Perhaps: "Clients MUST use the correct filehandle defined by the layout when accessing data on NFSv4.1 data servers. " Robert.=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Nov 04 20:16: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 1IoqZh-0003E0-HK; Sun, 04 Nov 2007 20:16:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoqZf-0003CE-VO for nfsv4@ietf.org; Sun, 04 Nov 2007 20:16:20 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IoqZf-0006wj-Ef for nfsv4@ietf.org; Sun, 04 Nov 2007 20:16:19 -0500 X-IronPort-AV: E=Sophos;i="4.21,369,1188802800"; d="scan'208";a="119521104" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 04 Nov 2007 16:22:13 -0800 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 lA50MCo0003452; Sun, 4 Nov 2007 16:22:12 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Nov 2007 16:22:12 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Nov 2007 16:22:12 -0800 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] Proposed resolutions for some pnfs-related [[Comment]]sections Date: Sun, 4 Nov 2007 19:22:09 -0500 Message-ID: In-Reply-To: <21557211-0C05-47B4-9966-3E769FE5CE26@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]]sections Thread-Index: AcgfBv3hZ7klnjzhS16CY4382L4JxwAObnHw From: "Noveck, Dave" To: "Robert Gordon" X-OriginalArrivalTime: 05 Nov 2007 00:22:12.0184 (UTC) FILETIME=[E8F62580:01C81F41] X-Spam-Score: -4.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 > > It is not allowed for a single COMPOUND to contain operations acting > > on both individual personalities, although an COMPOUND pertaining to a=20 > > single individual personality may contain housekeeping operation which=20 > > affect both personalities. > "It is not allowed" -- should that be a SHOULD NOT or MUST NOT ? It is mandatory but simply putting the words "MUST NOT" in there doesn't result in a correct statement. The issue is that the clinet can create any fool COMPOUND he wants but the server is obliged not to give the client what he wants. His MDS operations after the DS operation in the same COMPOUND will get NOTSUPP (the server MUST give him that). Similarly with DS operations after MDS operations. The server will not recognize DS filehandles specially. How about? A server MUST NOT execute operations within a single COMPOUND acting on behalf of both individual personalities, although the execution of a COMPOUND pertaining to a single individual personality may contain houskeeping operations affecting both personalities. -----Original Message----- From: Robert Gordon [mailto:Robert.Gordon@Sun.COM]=20 Sent: Sunday, November 04, 2007 12:20 PM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]]sections On Nov 2, 2007, at 1:49 PM, Noveck, Dave wrote: > > It is not allowed for a single COMPOUND to contain operations acting=20 > on both individual personalities, although an COMPOUND pertaining to a > single individual personality may contain housekeeping operation which > affect both personalities. > > > When a COMPOUND first executes an operation which is not part of one=20 > of the two sets above, or when it executes a PUTFH containing a=20 > filehandle not derived from a layout, it acts as a normal COMPOUND on=20 > any other server and the data server personality ceases to be=20 > relevant. > There are no special restrictions on the operations in the COMPOUND to > limit then to those for a data server. When a PUTFH is done,=20 > filehandles derived from the layout are not valid. If their format is > not normally acceptable, then NFS4ERR_BADHANDLE MUST result. =20 > Similarly, current filehandles for other operations do not accept=20 > filehandles derived from layouts and these will result in=20 > NFS4ERR_STALE. > > > When a COMPOUND first executes a PUTFH where the filehandle is one=20 > from a layout, the COMPOUND henceforth is interpreted with respect to=20 > the data server personality. In particular, operations outside the=20 > two classes discussed above MUST result in NFS4ERR_NOTSUPP and=20 > filehandles are validated using the rules of the data server,=20 > resulting in NFS4ERR_BADHANDLE and/or NFS4ERR_STALE even when they=20 > would not normally do so when addressed to the non-data-server=20 > personality. > =09 "It is not allowed" -- should that be a SHOULD NOT or MUST NOT ? Since the filehandle could be the MDS filehandle; I'm not sure that the server can distinguish which personality the PUTFH pertains to.. But maybe that is your point ? -- if it is then we need to be clearer :) --=20 Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Nov 04 23:32: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 1Iotd0-0007Xr-M4; Sun, 04 Nov 2007 23:31:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iotcz-0007WH-EV for nfsv4@ietf.org; Sun, 04 Nov 2007 23:31:57 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iotcy-0002Ve-Ok for nfsv4@ietf.org; Sun, 04 Nov 2007 23:31:57 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA54VuGw000661 for ; Mon, 5 Nov 2007 04:31:56 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR000I01N34XJ00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Sun, 04 Nov 2007 21:31:56 -0700 (MST) Received: from [10.0.1.192] ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR000FOPN960EA0@mail-amer.sun.com>; Sun, 04 Nov 2007 21:31:55 -0700 (MST) Date: Sun, 04 Nov 2007 22:31:53 -0600 From: Robert Gordon Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]]sections 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: -1.0 (-) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Nov 4, 2007, at 6:10 PM, Noveck, Dave wrote: >> strictly speaking the last sentence is not true; > > Why not? > >> since the filehandle may be the MDS filehandle, > > Where does the current spec say that? > >> and that is not conveyed in the layout. > > Probably not. > > In draft-15, the first sentence of section 14.7 is: > > Clients MUST use the filehandle described within the layout when > accessing data on NFSv4.1 data servers. > > That doesn't sound to me the like the filehandle may be the MDS > filehandle. > > My intention was not change the spec in this regard. Is there some > other text that allows this? 14.3 File Layout Data Types. [snip] 4. nfl_fh_list. An array of data server filehandles for each list of data servers in each element of the nflda_multipath_ds_list array. The number of elements in nfl_fh_list depends on whether sparse or dense packing is being used. If sparse packing is being used, the number of elements in nfl_fh_list MUST be of three values: Zero. This means that filehandles used for each data server are the same as the filehandle returned by the OPEN operation from the metadata server. [snip] Robert.. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 05 00:16: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 1IouJc-00035a-Sk; Mon, 05 Nov 2007 00:16:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IouJb-00032Q-9a for nfsv4@ietf.org; Mon, 05 Nov 2007 00:15:59 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IouJa-0003Ok-Ug for nfsv4@ietf.org; Mon, 05 Nov 2007 00:15:59 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA55Ffmg028564 for ; Mon, 5 Nov 2007 05:15:41 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR000701P2ETP00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Sun, 04 Nov 2007 22:15:41 -0700 (MST) Received: from [10.0.1.192] ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR000FXYPA40EF0@mail-amer.sun.com>; Sun, 04 Nov 2007 22:15:41 -0700 (MST) Date: Sun, 04 Nov 2007 23:15:39 -0600 From: Robert Gordon Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]]sections In-reply-to: To: "Noveck, Dave" Message-id: <751896E5-C2B7-4798-82DF-D18BD3FB413C@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: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Nov 4, 2007, at 6:22 PM, Noveck, Dave wrote: > How about? > > A server MUST NOT execute operations within a single COMPOUND > acting on > behalf of both individual personalities, although the execution of a > COMPOUND pertaining to a single individual personality may contain > housekeeping operations affecting both personalities. > I think that is fine, however an MDS may be claiming both personalities and also handing out layouts such that the client has to use the FH returned by OPEN.. as silly as that may seem. :) Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 05 05:53: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 1IozaK-0004ER-Op; Mon, 05 Nov 2007 05:53:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IozaJ-0004DI-Gm for nfsv4@ietf.org; Mon, 05 Nov 2007 05:53:35 -0500 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 1IozaI-0003cR-1c for nfsv4@ietf.org; Mon, 05 Nov 2007 05:53:35 -0500 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 lA5AlCkh009861; Mon, 5 Nov 2007 05:47:13 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 5 Nov 2007 05:47:12 -0500 Received: from bh-buildlin1.bhalevy.com ([172.17.28.134]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 05:46:29 -0500 Message-ID: <472EF4AD.10107@panasas.com> Date: Mon, 05 Nov 2007 12:47:09 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Noveck, Dave" , Marc Eshel , Robert Gordon Subject: Re: [nfsv4] Device stateids (v3) References: <4728C290.40705@panasas.com> In-Reply-To: <4728C290.40705@panasas.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2007 10:46:29.0212 (UTC) FILETIME=[1F1709C0:01C81F99] X-Spam-Score: 0.0 (/) X-Scan-Signature: fd911903d9eb33179d1ec28b0417afe8 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 updated and hopefully simplified the proposal based on Dave's comments. - device ID major/minor is used instead of devsetid. - CB_DEVICERECALL merged into CB_DEVICENOTIFY (now used for deletions, changes, and additions) - removed DEVICERETURN - defined new SEQ4_STATUS_DEVICE_STATE_REVOKED sequence flag. Benny -- 1. Introduction The NFS client maintains a mapping of device IDs contained in a layout to the corresponding storage device addresses. Device IDs are comprised of { di_major, di_minor } allowing the server to partition the device ID namespace along its file systems architecture boundaries (e.g., each di_major can be associated with a filesystem). The state of the mapping is represented by a recallable device stateid (devstateid). There is at most one devstateid per { client ID, layout type } nexus. GETDEVICELIST and GETDEVICEINFO are used to retrieve the device ID mapping information. CB_DEVICENOTIFY is a callback used to notify the client of changes to the device ID mapping. SEQ4_STATUS_DEVICE_STATE_REVOKED is new sequence flag used to notify the client the its device ID mapping state has been revoked if the server failed to notify the client of changes to the device ID mapping via CB_DEVICENOTIFY. 2. Data structures struct deviceid4 { uint64_t di_major; uint64_t di_minor; }; 3. Getting device ID mapping information GETDEVICEINFO SYNOPSIS: devstateid, layout_type, deviceid, maxcount -> devstateid, device_addr GETDEVICEINFO returns device mapping information for a fully specified deviceid. The server should return NFS4ERR_INVAL if deviceid.di_minor is set to zero. The current filehandle is not used. GETDEVICELIST struct gdl_devmajor4 { bool gdldm_valid; uint64_t gdldm_major; }; SYNOPSIS: devstateid, layout_type, devmajor, maxcount, cookie, cookieverf -> devstateid, cookie, cookieverf, device info list<> GETDEVICELIST returns a list of device ID mapping information. When devmajor.gdldm_valid is false it lists all device IDs for the specified layout_type, otherwise, GETDEVICELIST lists all the device IDs for the specified layout_type where deviceid.di_major equals the devmajor.gdldm_major. The latter method will typically be used following a respective CB_DEVICENOTIFY for The current filehandle is not used. GETDEVICEINFO and GETDEVICELIST each take the a devstateid and the layout type and return a non-zero devstateid. In case the client holds a valid devstateid it MUST use it for subsequent GETDEVICEINFO and GETDEVICELIST that update the device ID mapping. The devstateid argument MUST be set to zero whenever the client has no valid devstateid. Note that LAYOUTGET and GETDEVICELIST MUST NOT return any deviceid where deviceid.di_minor equals zero. 4. Notifying the client of changes to the device ID mapping CB_DEVICENOTIFY enum devicenotify_type4 { DEVICENOTIFY_DELETED = 1, DEVICENOTIFY_CHANGED = 2, DEVICENOTIFY_ADDED = 3, }; SYNOPSIS: devstateid, layout_type, notify_type, deviceid<> -> CB_DEVICENOTIFY takes a devstateid, the layout_type, a notification type, and an array of device IDs to notify the client of deletions, updates, or additions to the device ID mapping. When replying to CB_DEVICENOTIFY, the client should invalidate the specified device IDs such that any futher use of them will require the use of GETDEVICEINFO or GETDEVICELIST to retrieve the updated mapping. Note, however, that some I/O operations to the affected storage devices may still be outstanding. The server MAY fence the client off from the changed device IDs until the client updates the mapping yet it is not required to do so. If the server needs to synchronize with the client with that respect, it SHOULD recall all layouts referring to the affected device IDs and wait for the client to return the layouts. For each deviceid, a zero value for deviceid.di_minor represents all device IDs matching deviceid.di_major. Typically, in this case the client will use GETDEVICELIST for deviceid = to update all the affected device mappings. Deleted device IDs will not be reused by the server and all outstanding layouts referring to it are expected to be recalled via CB_LAYOUTRECALL; Attempting to use GETDEVICEINFO for the deleted deviceids is allowed but rather useless as the server MUST reject it with NFS4ERR_INVAL. The server can inform the client of additional deviceids that were not previously returned in a previous series of GETDEVICELIST calls (where the series ended in gdlr_eof == TRUE). The purpose of this operation is to reduce the latency for getting new device mappings. Rather than waiting until the client accesses a file that uses the new device ID, issue a LAYOUTGET, and then a GETDEVICEINFO for the new device, the server can notify the client of any new device ID in advance and have the client get the device address mapping by calling GETDEVICEINFO or GETDEVICELIST at its convenience. For each added deviceid, a deviceid.di_minor set to zero is an indication that a new set of devices sharing the specified di_major were added and the client SHOULD use GETDEVICELIST to get the all mappings in a batch operation, otherwise the client MAY use GETDEVICEINFO for each specified deviceid. If the client has already issued a GETDEVICEINFO for the added device IDs, it MAY just ignore the device id notification. CB_DEVICENOTIFY does not change the devstateid. 5. The SEQ4_STATUS_DEVICE_STATE_REVOKED SEQUENCE flag In addition to informing the client of mapping changes via CB_DEVICENOTIFY, the server MUST use the (newly introduced) SEQ4_STATUS_DEVICE_STATE_REVOKED SEQUENCE flag to indicate that all device ID mappings have been revoked without expiration of the lease period due to the server failure to notify the client of changes in the mapping via CB_DEVICENOTIFY. This status bit remains set on all SEQUENCE replies until the loss of the device mapping state has been acknowledged by use of either GETDEVICEINFO or GETDEVICELIST using the zero devstateid. On Oct. 31, 2007, 19:59 +0200, Benny Halevy wrote: > Dave, thanks for the comments! > My answers inline below. > > Benny > > On Oct. 31, 2007, 2:24 +0200, "Noveck, Dave" wrote: >>> Plus, I simplified the proposal by not requiring any new sequence >>> flags as the server should use the proposed callback operation to >>> recall device mappings and use the >> SEQ4_STATUS_RECALLABLE_STATE_REVOKED >>> and SEQ4_STATUS_CB_PATH_DOWN sequence flags as appropriate the >>> same it may use them for other recallable state objects (locks and >>> layouts). >> As far as I can see you don't you them the same and that is an issue. > > OK. we can define SEQ4_STATUS_DEVID_DELETED* in the spirit of the > last proposal [that I see is now part of draft-15 which seems to > introduce inconsistencies with the side effects of LAYOUTRETURN > for RETURN_{FSID,ALL} that return the respective device mappings > but do not change the device stateid] > >>> The state of the mapping is represented by a recallable device >>> stateid (devstateid). There is at most one devstateid per { client ID, >>> layout type, devsetid } nexus. >>> A recommended filesystem attribute - devsetid is introduced. >> Notice that this arrangement means that fsid A and fsid B share a >> devsetid or layout type X iff they share it for layout type Y. >> It seems that layout type is the one that should have the flexibility >> to figure out how it arranges its devices. >> >> I think a better model is to divide device id into major and minor >> fields and then all devices sharing a major device value become a device >> set. I think this would give you a lot more flexibility. > > Yeah, I see your point. Good idea. > >>> DEVICERETURN returns a device ID mapping. When called, this client >>> MUST guarantee not to make further use of that device ID mapping. >> Do you really mean that? Isn't this like a CLOSE if which if you used >> the stateid for the open file, you would get an error. Do you really >> mean that he server can depend on you not using this? > > same as LAYOUTRETURN. the server is not required to fence off the client after > LAYOUTRETURN. > >>> If the deviceid argument is set to zero, all device ID mappings in the >>> referred devset are returned. The server updates the devstateid and >>> returns the updated value. >> If the deviceid were zero, the returned value of devstateid would be >> zero. >> Correct? > > I'm not sure. What does the server return on CLOSE? > >>> GETDEVICEINFO >>> SYNOPSIS: devstateid, devsetid, deviceid, layout_type, maxcount, >> notify_ask -> >>> devstateid, notify_ack, device_addr >>> GETDEVICELIST >>> SYNOPSIS: devstateid, devsetid, layout_type, maxcount, cookie, >> cookieverf, notify_ask ->> >>> devstateid, notify_ack, cookie, cookieverf, device info list<> >>> GETDEVICEINFO and GETDEVICELIST each take the a devstateid, a >> devsetid, >>> and the layout type, and return a non-zero devstateid. >> This looks inconsistent to me. >> >> If I do a GETDEVICEINFO(a), I get a non-zero stateid. >> >> If I then do a DEVICERETURN(a), I get a zero stateid. >> >> OK, now I start with a zero stateid again and do a GETDEVICELIST and >> get a non-zero stateid. >> >> If I do a GETDEVICELIST, I get another non-zero stateid. >> >> If I then do a DEVICERETURN(a), I get ... a non-zero stateid because >> the GETDEVICELIST has some effect. Is that true. > > if you didn't return all device IDs using deviceid==0 then you > shouldn't get a zero devstateid. > >> It seems the DEVICERETURN is the inverse GETDEVICEINFO but that >> GETDEVICELIST has no inverse. At the very least we need more clarity >> about this stuff. > > The way I see it DEVICERETURN w/ deviceid==0 is sort of the inverse > of GETDEVICELIST as it "resets" (or reinitializes the device state. > >> >>> GETDEVICEINFO and GETDEVICELIST also take a boolean flag optionally >>> asking for device notifications and return a corresponding flag >>> confirming the notification. >> Isn't this new function? Is it really needed? > > It was in the previous proposal. > It is not strictly needed as the new device ID can always be introduced > at LAYOUTGET time and be resolved using GETDEVICEINFO. > The motivation is to optimize this case and reduce the latency by > allowing the client to get the device info in advance (it could do > so opportunistically, only if it's idle). > >>> Device stateids follow the sequencing and use rules of all other >> stateid >>> types. >> I assume that that means I use the normal "other" value with a seqid of >> zero as a wildcard. >> >>> The devstateid is invalidated when all devices associated with >>> it are returned via DEVICERETURN. The client can then "forget" about >> that >>> devstateid and use a value of zero for the devstateid for any >> subsequent >>> operation that takes a devstateid argument and allows the >> uninitialized >>> value. >> I suppose but the server can return that devstateid as zero. Then the >> client can either remember that zero and use it in which case he is >> using >> the correct thing or he can specially note it is zero and this allows >> him >> to forget it (but then he has to specially note that he has forgotten it >> and should use zero in its stead). Seems like the code would be simpler >> if it just remembered the last thing it got back (if the client did >> parallel once it would have to compare state seqids and treat zero >> specially >> as later than all normal ones. > > Agreed. That makes a lot of sense. > >>> 5. Recalling device IDs >>> CB_DEVICERECALL >>> SYNOPSIS: devstateid, devsetid, deviceid, deleted -> >>> >>> CB_DEVICERECALL takes a devstateid, devsetid, and a deviceid to notify >>> the client it needs to return the specified deviceid (when non-zero) >> or >>> all device IDs in the devsetid when the deviceid is set to zero, by >>> using a respective DEVICERETURN. CB_DEVICERECALL does not change the >>> device stateid. >> A couple things are unclear. It says it needs to return the specified >> device id, but is that true when 'deleted' is false? Also, what happens >> when the device id is zero and 'deleted' is false. What is supposed to >> happen? > > I meant that the client should send a DEVICERETURN in both cases, > although it doesn't seem harmful if it issues a GETDEVICEINFO to > refresh the data when "deleted" is set to false. But the server will > need to detect that case. > >>> All layouts using the affected device IDs remain in force, but the >>> server SHOULD fence the client from accessing the affected devices >>> until the client has returned the recalled device IDs. >> And after it has returned it? Should the server not fence the client >> form a device it has returned. > > I don't think so. We have access control mechanism to limit what > the client can do on the device but fencing the client off may hurt > performance needlessly. > >>> When the "deleted" boolean flag is set to false the client MAY use >>> GETDEVICEINFO or GETDEVICELIST to get the updated device mapping if >>> it has valid layouts the refer to the changed deviceid. >> After or instead of doing the return? > > See answer above. This needs to be clarified and I think I'll go > with the permissive approach of allowing to get the info without > and explicit DEVICERETURN. > >>> If the "deleted" flag is set to true the specified deviceid will not >> be >>> reused by the server and all outstanding layouts referring to it are >>> expected to be recalled via CB_LAYOUTRECALL; hence the client SHOULD >>> NOT attempt to call GETDEVICEINFO or GETDEVICELIST for the specified >>> deviceid. However, if it does do so the server MUST return a >> NFS4ERR_INVAL >>> error. >>> 6. Device notification >>> CB_DEVICENOTIFY >>> SYNOPSIS: devstateid, devsetid, deviceid -> >>> If the server supports CB_DEVICENOTIFY for devices and the client has >>> requested device id notifications via GETDEVICEINFO or GETDEVICELIST >>> the server can inform the client of additional deviceids that were >>> not previously returned by GETDEVICELIST. >> Again, what is the need here? The client will see the device id's >> when he gets a layout. > > Agreed. This is an optimization we can live without of. > see above... > >>> 7. SEQUENCE flags >>> In addition to informing the client of mapping changes via >>> CB_DEVICERECALL and CB_DEVICENOTIFY, the server MUST use the >>> SEQ4_STATUS_RECALLABLE_STATE_REVOKED SEQUENCE flag to indicate >>> that one or more device IDs have been revoked without expiration >>> of the lease period, due to the client's failure to return them >>> when recalled. >> First of all, in the case of CB_DEVICENOTIFY, nothing has been >> recalled or is supposed to be returned, as far as I can see. > > right. > >> Then it speaks of devices being "revoked". Devices do not have >> stateids and are not, in that sense, locking objects. If the >> current protocol, when a stateid has multiple locks (.e.g. byte-range >> locks), it is carefully stateid that when one is revoked, all are as >> a unit and that is tied to the associated stateid being made invalid. >> >> When SEQ4_STATUS_RECALLABLE_STATE_REVOKED is set in the current >> protocol, the client is supposed to use TEST_STATEID to determine >> what state has been lost and acknowledge that loss using FREE_STATEID. >> >> I think it would be much better if revocation continued to follow >> that model. If a devstateid is revoked, then, at least for that, >> you start from scratch. > > OK > >>> This status bit remains set on all SEQUENCE replies until the >>> loss of all such device ID mappings has been acknowledged by use >>> of DEVICERETURN. >> I think it should stay until all revoked stateids are freed via >> FREE_STATEID, just as it is today. > > OK > >> >> -----Original Message----- >> From: Benny Halevy [mailto:bhalevy@panasas.com] >> Sent: Monday, October 29, 2007 11:45 AM >> To: Robert Gordon; Marc Eshel >> Cc: NFSv4 >> Subject: Re: [nfsv4] Device stateids >> >> During the most recent bakeathon concern has been raised about the >> global device ID namespace and Marc Eshel from IBM requested that we >> retain the ability to recall devices per-fsid. To satisfy this >> requirement as well as the requirement for a simple global device ID >> namespace the updated proposal below introduces a device-set identifier >> (devsetid) that qualifies the device ID. >> >> This provides for a more flexible deviceid namespace topology that can >> cover either a global deviceid namespace, per-fsid namespace, or >> anything in between (e.g. when several filesystems reside on (and are >> confined to) a set of devices, like in EMC or Panasas' cases). >> >> The proposal also introduces new operations to manage device mapping >> state rather than unnecessarily overloading existing operations. >> >> Plus, I simplified the proposal by not requiring any new sequence flags >> as the server should use the proposed callback operation to recall >> device mappings and use the SEQ4_STATUS_RECALLABLE_STATE_REVOKED and >> SEQ4_STATUS_CB_PATH_DOWN sequence flags as appropriate the same it may >> use them for other recallable state objects (locks and layouts). >> >> One last change is providing for a "wildcard" value (0) for device ID >> that specifies all the device IDs in a devset. This means that the >> server MUST NOT return a zero device ID in GETDEVICELIST or in any >> layout and it must reject it as invalid in GETDEVICEINFO.GETDEVICEINFO >> and GETDEVICELIST also take a boolean flag optionally asking for device >> notifications and return a corresponding flag confirming the >> notification. >> I guess that this won't be an issue for anyone; otherwise, please >> holler. >> >> Benny >> >> -- >> 1. Introduction >> >> The NFS client maintains a mapping of device IDs contained in a layout >> to the corresponding storage device address. >> Device IDs and filesystem IDs are associated with device set IDs such >> that each fsid is associated with a single devsetid as indicated by a >> new, recommended filesystem attribute, and each deviceid is associated >> with a single devsetid. >> >> The state of the mapping is represented by a recallable device stateid >> (devstateid). There is at most one devstateid per { client ID, layout >> type, devsetid } nexus. >> >> A recommended filesystem attribute - devsetid is introduced. >> All deviceids associated with any file in the filesystem are associated >> with this devsetid. >> If the server does not support device sets, it can omit this attribute, >> making the deviceid namespace global and implicitly associating all >> deviceids with the default devset (having the implicit devsetid ID of 0) >> >> 2. Getting device information >> >> GETDEVICEINFO >> SYNOPSIS: devstateid, devsetid, deviceid, layout_type, maxcount, >> notify_ask -> >> devstateid, notify_ack, device_addr >> >> GETDEVICELIST >> SYNOPSIS: devstateid, devsetid, layout_type, maxcount, cookie, >> cookieverf, notify_ask -> >> devstateid, notify_ack, cookie, cookieverf, device info list<> >> >> GETDEVICEINFO and GETDEVICELIST each take the a devstateid, a devsetid, >> and the layout type, and return a non-zero devstateid. >> In case the client holds a valid devstateid it MUST use it for >> subsequent GETDEVICEINFO and GETDEVICELIST that update the device ID >> mappings. The devstateid argument must be set to zero whenever the >> client has no valid devstateid (e.g. after reboot or after the >> devstateid was previously returned via DEVICERETURN). >> >> GETDEVICEINFO and GETDEVICELIST also take a boolean flag optionally >> asking for device notifications and return a corresponding flag >> confirming the notification. >> >> 3. Returning device IDs >> >> DEVICERETURN >> SYNOPSIS: devstateid, devsetid, deviceid -> devstateid >> >> DEVICERETURN returns a device ID mapping. When called, this client MUST >> guarantee not to make further use of that device ID mapping. >> If the deviceid argument is set to zero, all device ID mappings in the >> referred devset are returned. The server updates the devstateid and >> returns the updated value. >> >> 4. Sequencing rules >> >> Device stateids follow the sequencing and use rules of all other stateid >> types. The devstateid is invalidated when all devices associated with >> it are returned via DEVICERETURN. The client can then "forget" about >> that devstateid and use a value of zero for the devstateid for any >> subsequent operation that takes a devstateid argument and allows the >> uninitialized value. >> >> 5. Recalling device IDs >> >> CB_DEVICERECALL >> SYNOPSIS: devstateid, devsetid, deviceid, deleted -> >> >> CB_DEVICERECALL takes a devstateid, devsetid, and a deviceid to notify >> the client it needs to return the specified deviceid (when non-zero) or >> all device IDs in the devsetid when the deviceid is set to zero, by >> using a respective DEVICERETURN. CB_DEVICERECALL does not change the >> device stateid. >> >> All layouts using the affected device IDs remain in force, but the >> server SHOULD fence the client from accessing the affected devices until >> the client has returned the recalled device IDs. >> >> When the "deleted" boolean flag is set to false the client MAY use >> GETDEVICEINFO or GETDEVICELIST to get the updated device mapping if it >> has valid layouts the refer to the changed deviceid. If the "deleted" >> flag is set to true the specified deviceid will not be reused by the >> server and all outstanding layouts referring to it are expected to be >> recalled via CB_LAYOUTRECALL; hence the client SHOULD NOT attempt to >> call GETDEVICEINFO or GETDEVICELIST for the specified deviceid. However, >> if it does do so the server MUST return a NFS4ERR_INVAL error. >> >> 6. Device notification >> >> CB_DEVICENOTIFY >> SYNOPSIS: devstateid, devsetid, deviceid -> >> >> If the server supports CB_DEVICENOTIFY for devices and the client has >> requested device id notifications via GETDEVICEINFO or GETDEVICELIST the >> server can inform the client of additional deviceids that were not >> previously returned by GETDEVICELIST. >> >> The purpose of this operation is to reduce the latency for getting new >> device mappings. Rather than waiting until the client accesses a file >> that uses the new device ID, issue a LAYOUTGET, and then a GETDEVICEINFO >> on the new device, the server can notify the client of any new device ID >> in advance and have the client get the device address mapping by calling >> GETDEVICEINFO at its convenience. >> >> CB_DEVICENOTIFY takes a device stateid, a device set ID and a device ID >> in the device set for a device ID 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. >> CB_DEVICENOTIFY does not change the device stateid. >> >> If the client has already issued a GETDEVICEINFO for the specified >> deviceid then it SHOULD just ignore the device id notification. >> Updating an existing device ID mapping should be done using a sequence >> of CB_DEVICERECALL, DEVICERETURN, and GETDEVICEINFO (or GETDEVICELIST). >> >> 7. SEQUENCE flags >> >> In addition to informing the client of mapping changes via >> CB_DEVICERECALL and CB_DEVICENOTIFY, the server MUST use the >> SEQ4_STATUS_RECALLABLE_STATE_REVOKED SEQUENCE flag to indicate that one >> or more device IDs have been revoked without expiration of the lease >> period, due to the client's failure to return them when recalled. This >> status bit remains set on all SEQUENCE replies until the loss of all >> such device ID mappings has been acknowledged by use of DEVICERETURN. >> >> On Aug. 09, 2007, 10:22 +0300, Benny Halevy wrote: >>> Robert Gordon wrote: >>>> In general i think this is good. >>>> >>>> I've started to think that the SEQUENCE status flags could just be >>>> two bits. >>>> >>>> SEQ4_STATUS_DEVID_DELETED_ALL >>>> This flag stays on until the client issues a DELEGRETURN >>>> using the devstateid. >>>> >>>> SEQ_STATUS_DEVID_CHANGED >>>> This flag stay on until a GETDEVICELIST or GETDEVICEINFO >>>> (if using CB_NOTIFY) gets the affected mappings. >>> The DEVID_DELETED cases should be covered by CHANGED as the client >>> will have to revalidate all the device mappings anyway to see what >>> actually changed and should either not see the deleted deviceid >>> returned by GETDEVICELIST or get an error from GETDEVICEINFO for that >> deviceid. >>> The DEVID_ADDED case is covered if the client is doing GETDEVICELIST >>> and the server supports it. If the server does not support >>> GETDEVICELIST is must not set SEQ_STATUS_DEVID_CHANGED for added >>> devices as the client has no way to get the new device ID. These will >>> be discovered only when the client will get new layouts referring to >>> the new devices (which is perfectly fine) >>> >>>> Robert. >>>> >>>> On Aug 8, 2007, at 10:58 AM, Benny Halevy wrote: >>>> >>>>> The NFS client maintains a mapping of device ids contained in a >>>>> layout, to the corresponding storage device address. >>>>> The state of the mapping is represented by a single recallable >>>>> device stateid (devstateid). There is at most one devstateid per { >>>>> client ID, layout type } pair. >>>>> >>>>> GETDEVICEINFO and GETDEVICELIST each take the layout type and an >>>>> optional devstateid and return the devstateid. In case the client >>>>> holds a valid devstateid it MUST use it for subsequent GETDEVICEINFO >>>>> and GETDEVICELIST that update the device ID mappings. The >>>>> devstateid argument is invalid whenever the client has no valid >>>>> devstateid (e.g. after reboot or after the devstateid was previously >>>>> returned via DELEGRETURN). >>>>> GETDEVICEINFO or GETDEVICELIST that operate on a device stateid that >>>>> was already recalled via CB_RECALL MUST be rejected by the server >>>>> with NFS4ERR_BADSTATEID. >>>>> >>>>> GETDEVICEINFO and GETDEVICELIST also take a boolean flag optionally >>>>> asking for device notifications and return a corresponding flag >>>>> confirming the notification. >>>>> >>>>> Device stateids follow the sequencing and use rules of all other >>>>> stateid types. The mappings are invalidated when the devstateid is >>>>> returned via CB_DELEGRETURN or explicitly deleted via CB_NOTIFY. >>>>> >>>>> All layouts using the device IDs remain in force, but the server >>>>> MUST fence the client from accessing the affected devices until the >>>>> client has obtained the re-mapped device IDs via GETDEVICEINFO or >>>>> GETDEVICELIST. >>>>> >>>>> CB_RECALL takes a devstateid to notify the client it needs to return >>>>> all device IDs identified by the devstateid. The filehandle >>>>> argument has no use in this case. It does not change the device >>>>> stateid. >>>>> >>>>> DELEGRETURN takes a devstateid to return all device IDs associated >>>>> with the devstateid. The current filehandle has no use in this case. >>>>> >>>>> If the server supports CB_NOTIFY for devices and the Client has >>>>> requested device id notifications via GETDEVICEINFO or >>>>> GETDEVICELIST; The server can inform the client of a delete, add, or >>>>> change mapping. >>>>> >>>>> CB_NOTIFY takes a device stateid qualifying a device ID for the >>>>> following device notifications: >>>>> >>>>> 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. >>>>> >>>>> CB_NOTIFY does not change the device stateid. >>>>> >>>>> In addition to informing the client of mapping changes via CB_NOTIFY >>>>> and CB_RECALL, SEQUENCE carries status flags to indicate that device >>>>> mappings have changed. >>>>> >>>>> The flags are :- >>>>> >>>>> SEQ4_STATUS_DEVID_DELETED >>>>> Mapping has been partially deleted. If the client is >>>>> using CB_NOTIFY it may issue a GETDEVICEINFO for each >>>>> notified deletion or GETDEVICELIST to refresh the entire >>>>> map. This flag stays on until the client responds to >>>>> any and all _DELETE notifications, or it has issued a >>>>> GETDEVICELIST. >>>>> >>>>> SEQ4_STATUS_DEVID_DELETED_ALL >>>>> This flag stays on until the client issues a DELEGRETURN >>>>> using the devstateid. >>>>> >>>>> SEQ4_STATUS_DEVID_CHANGED >>>>> SEQ4_STATUS_DEVID_ADDED >>>>> These flags stay on until a GETDEVICELIST or GETDEVICEINFO >>>>> (if using CB_NOTIFY) 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 > > > _______________________________________________ > 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 LakeishahaplologyBonds@platformfestival.com Mon Nov 05 12:14:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip5Wk-0002XL-PN; Mon, 05 Nov 2007 12:14:18 -0500 Received: from cpe-71-74-124-53.neo.res.rr.com ([71.74.124.53] helo=lem3956) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ip5Wk-00044R-Ff; Mon, 05 Nov 2007 12:14:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host65497284.platformfestival.com (8.13.1/8.13.1) with SMTP id ZsOw6KmT44.898731.qzv.vR2.3279385331072 for ; Mon, 5 Nov 2007 12:14:37 +0500 Message-ID: <1d713101c81fcf$612c3e80$0202a8c0@lem3956> From: "Georgette Marion" To: Subject: Your order approved Date: Mon, 5 Nov 2007 12:14:37 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1D712D_01C81FCF.612C3E80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_1D712D_01C81FCF.612C3E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_1D712D_01C81FCF.612C3E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1D712D_01C81FCF.612C3E80-- From nfsv4-bounces@ietf.org Mon Nov 05 12:16:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip5YV-0004zO-9C; Mon, 05 Nov 2007 12:16:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip5YU-0004wZ-AZ for nfsv4@ietf.org; Mon, 05 Nov 2007 12:16:06 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip5YT-00047a-Md for nfsv4@ietf.org; Mon, 05 Nov 2007 12:16:06 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA5HG4cn005465 for ; Mon, 5 Nov 2007 17:16:04 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR100F01LM5HC00@mail-amer.sun.com> (original mail from Jeff.A.Smith@Sun.COM) for nfsv4@ietf.org; Mon, 05 Nov 2007 10:16:04 -0700 (MST) Received: from [192.168.2.3] ([129.153.214.81]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR100GZIMLXGM50@mail-amer.sun.com> for nfsv4@ietf.org; Mon, 05 Nov 2007 10:15:35 -0700 (MST) Date: Mon, 05 Nov 2007 11:15:34 -0600 From: "Jeff A. Smith" To: nfsv4@ietf.org Message-id: <9C9DEB0E-28DD-44A1-80E6-28D5C6DE8C3B@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: 6d95a152022472c7d6cdf886a0424dc6 Subject: [nfsv4] question about nfs41 wrongsec processing rules 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 was reading sec. 2.6.3.1 of draft 15, "Using NFS4ERR_WRONGSEC, SECINFO, and SECINFO_NO_NAME", and I found a scenario that I've been unable to resolve to my satisfaction using the wrongsec processing rules. I suspect that I've misinterpreted some of the section. Here's a link to the section in draft 15: http://www.nfsv4-editor.org/draft-15/draft-ietf-nfsv4- minorversion1-15.html#Security%20Error Question: If a client sent a NFS41 server the compound below, and the current secflavor is not allowed, which op can the server fail w/wrongsec? PUTFH* + SECINFO_NO_NAME(cur_fh) + OPEN(fh) Note: PUTFH* is the same as the draft's usage of "Put Filehandle operation") Answer: none? section 2.6.3.1.5 states: "The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC to a put filehandle operation whenever it is immediately followed by SECINFO or SECINFO_NO_NAME. The NFSv4.1 server MUST NOT return NFS4ERR_WRONGSEC from SECINFO or SECINFO_NO_NAME." That seems clear enough. I can't fail putfh+secinfo_no_name with wrongsec, and it makes perfect sense. The server should provide the secinfo result so the client won't have to guess the correct flavor. So what about the open(cur_fh) op? section 2.6.3.1.7 "Put filehandle operation + anything else" "Anything Else" includes OPEN by filehandle." and "The NFSv4.1 server MUST not return NFS4ERR_WRONGSEC to any operation other than a put filehandle operation, LOOKUP, LOOKUPP, and OPEN (by component name)." The server is allowed to return wrongsec for OPEN(claim_null, name) but not OPEN(claim_fh, FH). I think I understand why the distinction is made. OPEN(name) changes the cur_fh like the other ops mentioned, but OPEN(fh) does not. Since the server was not allowed to fail any of the ops in the compound with wrongsec, it just allowed a (rogue) client to open a file using the wrong sec flavor. This seems like a very bad thing. I said rogue client simply because the solaris client is not structured such that it can build compounds like this. Obviously, for this to "work" the client would have needed to obtain the FH initially using an acceptable flavor. After that point, the allowed flavor changed. What about the compound below? Which OP can the server fail with wrongsec? Assume the server would like to fail the initial PUTFH* op with wrongsec. PUTFH* + SECINFO_NO_NAME(cur_fh) + OPEN(claim_fh) + READ(cur_stateid) + CLOSE(cur_stateid) The last sentence of 2.6.3.1.7 "Put Filehandle + Anything Else" prevents the server from failing the OPEN(FH), READ, and CLOSE operations with WRONGSEC. To match this rule requires that after the PUTFH*+SECINFO match, the server keeps the PUTFH "in play" and keeps looking for matches on the remaining ops. I suspect this the source of my problem, and I've taken a little too much creative license in interpreting this section. How can the server return WRONGSEC for this compound and adhere to the wrongsec processing rules in 2.6.3.1.*? I have some ideas on how to tweak the section to allow the server to fail the compounds with WRONGSEC, but before going there, I want to make sure I'm applying the rules correctly to the compound. I'm also not sure I understand the requirements being met by this section, so my actually proposing a change at this point would be foolish. Could someone please clarify how a server should apply the wrongsec processing rules? For the questions below, assume that the PUTFH* is not using the correct sec flavor, and the server would like to return WRONGSEC as soon as it can. a) Should wrongsec processing be applied to all ops or only at the start of the compound? (I think all) b) Once a match is made, is wrongsec processing over? (I think no. Keep looking for op matches.) c) If the answer to b) is "no, keep looking", then how is the search restarted? If we matched a PUTFH+SECINFO, do we start looking for another PUTFH or do we keep the initial PUTFH in play, and look for other ops which would cause wrongsec processing rule matches? Jeff _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 05 13:36: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 1Ip6oO-0003ce-4O; Mon, 05 Nov 2007 13:36:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip6oM-0003b4-C9 for nfsv4@ietf.org; Mon, 05 Nov 2007 13:36:34 -0500 Received: from mout.perfora.net ([74.208.4.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip6oL-0006Ld-0v for nfsv4@ietf.org; Mon, 05 Nov 2007 13:36:34 -0500 Received: from jeeves.macrbg.com ([72.179.36.242]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1Ip6lc29P8-0005zn; Mon, 05 Nov 2007 13:34:07 -0500 Message-Id: <3D9B65CC-647A-4945-B346-C6EB7DACADE3@openrbg.com> From: Robert Gordon To: Benny Halevy In-Reply-To: <472EF4AD.10107@panasas.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: [nfsv4] Device stateids (v3) Date: Mon, 5 Nov 2007 12:33:43 -0600 References: <4728C290.40705@panasas.com> <472EF4AD.10107@panasas.com> X-Mailer: Apple Mail (2.912) X-Provags-ID: V01U2FsdGVkX18ucaSe631zP6Vns6hV/bu3UNslDBc/FKXinrj w53Q9pv+oe8fcRFVMupBjZHxxblfTipgLgRjFpHgmVOh1nMi4h yJMH9gh3sux+/HgytSSmA== X-Spam-Score: -0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: "Noveck, Dave" , NFSv4 , 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 On Nov 5, 2007, at 4:47 AM, Benny Halevy wrote: > I updated and hopefully simplified the proposal based on Dave's > comments. > > - device ID major/minor is used instead of devsetid. > - CB_DEVICERECALL merged into CB_DEVICENOTIFY (now used > for deletions, changes, and additions) > - removed DEVICERETURN > - defined new SEQ4_STATUS_DEVICE_STATE_REVOKED sequence flag. > > Benny So, in this proposal are you suggesting that CB_DEVICENOTIFY is a mandatory operation to implement at the client ? also, i had thought that the deviceid moving from 32 bits to 64 was to accommodate maj/minor partitioning; now we have a 128 bit deviceid ?? is that really necessary ? Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 05 13:56: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 1Ip77d-00010y-Po; Mon, 05 Nov 2007 13:56:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip77c-0000z5-L4 for nfsv4@ietf.org; Mon, 05 Nov 2007 13:56:28 -0500 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 1Ip77b-0007Tc-5z for nfsv4@ietf.org; Mon, 05 Nov 2007 13:56:28 -0500 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 lA5ItccI020477; Mon, 5 Nov 2007 13:55:38 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 5 Nov 2007 13:55:38 -0500 Received: from bh-buildlin1.bhalevy.com ([172.17.28.131]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 13:54:55 -0500 Message-ID: <472F6727.90505@panasas.com> Date: Mon, 05 Nov 2007 20:55:35 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Robert Gordon Subject: Re: [nfsv4] Device stateids (v3) References: <4728C290.40705@panasas.com> <472EF4AD.10107@panasas.com> <3D9B65CC-647A-4945-B346-C6EB7DACADE3@openrbg.com> In-Reply-To: <3D9B65CC-647A-4945-B346-C6EB7DACADE3@openrbg.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2007 18:54:56.0270 (UTC) FILETIME=[5B7532E0:01C81FDD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: "Noveck, Dave" , NFSv4 , 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 On Nov. 05, 2007, 20:33 +0200, Robert Gordon wrote: > On Nov 5, 2007, at 4:47 AM, Benny Halevy wrote: > >> I updated and hopefully simplified the proposal based on Dave's >> comments. >> >> - device ID major/minor is used instead of devsetid. >> - CB_DEVICERECALL merged into CB_DEVICENOTIFY (now used >> for deletions, changes, and additions) >> - removed DEVICERETURN >> - defined new SEQ4_STATUS_DEVICE_STATE_REVOKED sequence flag. >> >> Benny > > So, in this proposal are you suggesting that CB_DEVICENOTIFY > is a mandatory operation to implement at the client ? yes, pretty much as CB_DEVICERECALL was in the last proposal. The client can ignore the ADDED notifications though if it wants. > > also, i had thought that the deviceid moving from 32 bits to 64 > was to accommodate maj/minor partitioning; now we have a 128 bit > deviceid ?? is that really necessary ? not exactly. The move to 64 bit was to accommodate for the existing 64-bit device IDs we have implemented in panfs. The 64-bit major is to match fsid.major. This shouldn't be a big deal for files as you have very few device IDs and only one in each layout. For objects I thought of changing the pnfs-obj layout to have one major for the layout and just minor for each device in the map but I'm really not sure it's worth it. > > Robert. > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From ChadaghastMorales@houghtonmifflinbooks.com Mon Nov 05 14:20:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7UZ-0002Ac-RZ; Mon, 05 Nov 2007 14:20:11 -0500 Received: from t58a9.t.pppool.de ([89.55.88.169] helo=rabitff97afd7b) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ip7UY-00009f-Rh; Mon, 05 Nov 2007 14:20:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host70796004.houghtonmifflinbooks.com (8.13.1/8.13.1) with SMTP id B3aBCCGl84.385391.YBq.1aO.2151055154785 for ; Mon, 5 Nov 2007 20:19:42 -0100 Message-ID: <2666201c81fe0$e44a7780$fe7aa8c0@rabitff97afd7b> From: "Eddie Stevens" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_2665E_01C81FE0.E44A7780-- From nfsv4-bounces@ietf.org Mon Nov 05 14:30: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 1Ip7ex-0006Ie-EZ; Mon, 05 Nov 2007 14:30:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip7ew-0006Hb-R5 for nfsv4@ietf.org; Mon, 05 Nov 2007 14:30:54 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip7ev-0008KB-Fy for nfsv4@ietf.org; Mon, 05 Nov 2007 14:30:54 -0500 X-IronPort-AV: E=Sophos;i="4.21,374,1188802800"; d="scan'208";a="119754305" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 05 Nov 2007 11:30:37 -0800 Received: from sacexrs01.hq.netapp.com (sacexrs01.hq.netapp.com [10.99.190.105]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id lA5JUXMe016304; Mon, 5 Nov 2007 11:30:37 -0800 (PST) Received: from SACEXMV01.hq.netapp.com ([10.99.190.107]) by sacexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 11:30:34 -0800 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] Proposed resolutions for some pnfs-related[[Comment]]sections Date: Mon, 5 Nov 2007 11:30:33 -0800 Message-ID: <01AE8AF878612047A442668306EAEB0501390D77@SACEXMV01.hq.netapp.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections Thread-Index: AcgfZRRGoLk0yZMVS3iDB+7LLLBtmAAeBHhA References: From: "Muntz, Daniel" To: "Robert Gordon" , "Noveck, Dave" X-OriginalArrivalTime: 05 Nov 2007 19:30:34.0267 (UTC) FILETIME=[55CDA6B0:01C81FE2] X-Spam-Score: -4.0 (----) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Is anyone using the special case of 14.3? If the spcial case is removed, and a particular implementation wants to use the MDS FH as the DS FH, it may do so. It can call the MDS FH a DS FH for one or more of the DSs, and the spec would be agnostic on the issue (i.e., you're not using an MDS FH in a layout; you're using a DS FH that happens to be the same as the MDS FH). In my (possibly oversimplified) mind, the MDS FH is "the" FH for the file, to be used for meta-data ops, etc. The DS FHs are part of the mechanism for accessing stripes of the file. Is there a compelling reason to make the client deal with distinguishing between whether it's going to use an MDS FH vs. a DS FH for a stripe operation? Is there a case where it makes sense to complicate the meaning of "MDS FH" vs. "DS FH" by allowing this special case? -Dan -----Original Message----- From: Robert Gordon [mailto:Robert.Gordon@Sun.COM]=20 Sent: Sunday, November 04, 2007 8:32 PM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections On Nov 4, 2007, at 6:10 PM, Noveck, Dave wrote: >> strictly speaking the last sentence is not true; > > Why not? > >> since the filehandle may be the MDS filehandle, > > Where does the current spec say that? > >> and that is not conveyed in the layout. > > Probably not. > > In draft-15, the first sentence of section 14.7 is: > > Clients MUST use the filehandle described within the layout when > accessing data on NFSv4.1 data servers. > > That doesn't sound to me the like the filehandle may be the MDS=20 > filehandle. > > My intention was not change the spec in this regard. Is there some=20 > other text that allows this? 14.3 File Layout Data Types. [snip] 4. nfl_fh_list. An array of data server filehandles for each list of data servers in each element of the nflda_multipath_ds_list array. The number of elements in nfl_fh_list depends on whether sparse or dense packing is being used. If sparse packing is being used, the number of elements in nfl_fh_list MUST be of three values: Zero. This means that filehandles used for each data server are the same as the filehandle returned by the OPEN operation from the metadata server. [snip] 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 Yanni597@bullseyeranch.com Mon Nov 05 15:12:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip8J4-0008TS-KO for nfsv4-archive@lists.ietf.org; Mon, 05 Nov 2007 15:12:22 -0500 Received: from host180-174-dynamic.23-79-r.retail.telecomitalia.it ([79.23.174.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip8J3-0000p8-16 for nfsv4-archive@lists.ietf.org; Mon, 05 Nov 2007 15:12:22 -0500 Received: by 10.203.169.1 with SMTP id vUgQQNoNCzkDG; Tue, 6 Nov 2007 21:13:54 +0100 (GMT) Received: by 192.168.229.199 with SMTP id pmEmMdGXymxhsV.2192630800186; Tue, 6 Nov 2007 21:13:52 +0100 (GMT) Message-ID: <000401c820b1$8b26b890$b4ae174f@alessio30307fb> From: "Yanni sadfsd" To: Subject: srevihs0 Date: Tue, 6 Nov 2007 21:13:49 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C820B9.ECEB2090" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Antivirus: avast! (VPS 071104-0, 04/11/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 2.2 (++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0006_01C820B9.ECEB2090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable whats poppin nfsv4-archive if you cant get it hard or cum too quick, we have a solution http://itths.com/ Yanni sadfsd ------=_NextPart_000_0006_01C820B9.ECEB2090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
whats poppin nfsv4-archive
if you cant get it hard or cum too quick, we = have a=20 solution
http://itths.com/
Yanni sadfsd
------=_NextPart_000_0006_01C820B9.ECEB2090-- From nfsv4-bounces@ietf.org Mon Nov 05 16:35: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 1Ip9br-00084q-E5; Mon, 05 Nov 2007 16:35:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip9bp-00083m-FP for nfsv4@ietf.org; Mon, 05 Nov 2007 16:35:49 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip9bo-0004pI-Sa for nfsv4@ietf.org; Mon, 05 Nov 2007 16:35:49 -0500 X-IronPort-AV: E=Sophos;i="4.21,374,1188802800"; d="scan'208";a="119787384" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 05 Nov 2007 13:35:47 -0800 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 lA5LZd1p026323; Mon, 5 Nov 2007 13:35:45 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 13:35:44 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 13:35:44 -0800 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] Proposed resolutions for some pnfs-related[[Comment]]sections Date: Mon, 5 Nov 2007 16:35:42 -0500 Message-ID: In-Reply-To: <01AE8AF878612047A442668306EAEB0501390D77@SACEXMV01.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections Thread-Index: AcgfZRRGoLk0yZMVS3iDB+7LLLBtmAAeBHhAAAVxcxA= From: "Noveck, Dave" To: "Muntz, Daniel" , "Robert Gordon" X-OriginalArrivalTime: 05 Nov 2007 21:35:44.0542 (UTC) FILETIME=[D246ABE0:01C81FF3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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 the special case is removed, and a particular implementation wants to=20 > use the MDS FH as the DS FH, it may do so. But if you allow it do so, then, even though the encouragement of the special case is gone, you are still allowing a situation in which it is=20 ambiguous for a given op wherther it is being executed by the MDS or the DS. Although we can write text allow for that, it strikes me as something we will wind up regrettting. > Is there a compelling reason to make the client deal with distinguishing=20 > between whether it's going to use an MDS FH vs. a DS FH for a stripe=20 > operation?=20 I don't think this is a client issue. The client needs to distiguish=20 whether he is talking to MDS and DS and that is going to be true whatever we do about this issue. > Is there a case where it makes sense to complicate the meaning of=20 > "MDS FH" vs. "DS FH" by allowing this special case? It's the server that has the complexity when he receives an FH and has to distinguish which one it is (when it may not be disguishable), and thus which personality a given oepration is being directed at. -----Original Message----- From: Muntz, Daniel=20 Sent: Monday, November 05, 2007 2:31 PM To: Robert Gordon; Noveck, Dave Cc: nfsv4@ietf.org Subject: RE: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections Is anyone using the special case of 14.3? If the spcial case is removed, and a particular implementation wants to use the MDS FH as the DS FH, it may do so. It can call the MDS FH a DS FH for one or more of the DSs, and the spec would be agnostic on the issue (i.e., you're not using an MDS FH in a layout; you're using a DS FH that happens to be the same as the MDS FH). In my (possibly oversimplified) mind, the MDS FH is "the" FH for the file, to be used for meta-data ops, etc. The DS FHs are part of the mechanism for accessing stripes of the file. Is there a compelling reason to make the client deal with distinguishing between whether it's going to use an MDS FH vs. a DS FH for a stripe operation? Is there a case where it makes sense to complicate the meaning of "MDS FH" vs. "DS FH" by allowing this special case? -Dan -----Original Message----- From: Robert Gordon [mailto:Robert.Gordon@Sun.COM]=20 Sent: Sunday, November 04, 2007 8:32 PM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections On Nov 4, 2007, at 6:10 PM, Noveck, Dave wrote: >> strictly speaking the last sentence is not true; > > Why not? > >> since the filehandle may be the MDS filehandle, > > Where does the current spec say that? > >> and that is not conveyed in the layout. > > Probably not. > > In draft-15, the first sentence of section 14.7 is: > > Clients MUST use the filehandle described within the layout when > accessing data on NFSv4.1 data servers. > > That doesn't sound to me the like the filehandle may be the MDS=20 > filehandle. > > My intention was not change the spec in this regard. Is there some=20 > other text that allows this? 14.3 File Layout Data Types. [snip] 4. nfl_fh_list. An array of data server filehandles for each list of data servers in each element of the nflda_multipath_ds_list array. The number of elements in nfl_fh_list depends on whether sparse or dense packing is being used. If sparse packing is being used, the number of elements in nfl_fh_list MUST be of three values: Zero. This means that filehandles used for each data server are the same as the filehandle returned by the OPEN operation from the metadata server. [snip] 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 Mon Nov 05 16:39: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 1Ip9fG-0003PX-KQ; Mon, 05 Nov 2007 16:39:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip9fF-0003OT-85 for nfsv4@ietf.org; Mon, 05 Nov 2007 16:39:21 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip9fE-0004vK-Qg for nfsv4@ietf.org; Mon, 05 Nov 2007 16:39:21 -0500 X-IronPort-AV: E=Sophos;i="4.21,374,1188802800"; d="scan'208";a="119788379" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 05 Nov 2007 13:39:19 -0800 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 lA5LdJDA003289; Mon, 5 Nov 2007 13:39:19 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 13:39:19 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 13:39:19 -0800 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 (v3) Date: Mon, 5 Nov 2007 16:39:17 -0500 Message-ID: In-Reply-To: <472F6727.90505@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Device stateids (v3) Thread-Index: Acgf3bKpBEB3AoPOT5OzkMjSpUoP4gAFlcLg From: "Noveck, Dave" To: "Benny Halevy" , "Robert Gordon" X-OriginalArrivalTime: 05 Nov 2007 21:39:19.0139 (UTC) FILETIME=[522F9330:01C81FF4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Marc Eshel , 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 > > So, in this proposal are you suggesting that CB_DEVICENOTIFY > > is a mandatory operation to implement at the client ? > > yes, pretty much as CB_DEVICERECALL was in the last proposal. > The client can ignore the ADDED notifications though if it wants. pNFS is not a mandatory feature so I assume that a client can return NFS4ERR_NOTSUPP. Are we saying you MUST NOT do that if you have done one of the pNFS operations? -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Monday, November 05, 2007 1:56 PM To: Robert Gordon Cc: Noveck, Dave; Marc Eshel; NFSv4 Subject: Re: [nfsv4] Device stateids (v3) On Nov. 05, 2007, 20:33 +0200, Robert Gordon wrote: > On Nov 5, 2007, at 4:47 AM, Benny Halevy wrote: >=20 >> I updated and hopefully simplified the proposal based on Dave's >> comments. >> >> - device ID major/minor is used instead of devsetid. >> - CB_DEVICERECALL merged into CB_DEVICENOTIFY (now used >> for deletions, changes, and additions) >> - removed DEVICERETURN >> - defined new SEQ4_STATUS_DEVICE_STATE_REVOKED sequence flag. >> >> Benny >=20 > So, in this proposal are you suggesting that CB_DEVICENOTIFY > is a mandatory operation to implement at the client ? yes, pretty much as CB_DEVICERECALL was in the last proposal. The client can ignore the ADDED notifications though if it wants. >=20 > also, i had thought that the deviceid moving from 32 bits to 64 > was to accommodate maj/minor partitioning; now we have a 128 bit > deviceid ?? is that really necessary ? not exactly. The move to 64 bit was to accommodate for the existing 64-bit device IDs we have implemented in panfs. The 64-bit major is to match fsid.major. This shouldn't be a big deal for files as you have very few device IDs and only one in each layout. For objects I thought of changing the pnfs-obj layout to have one major for the layout and just minor for each device in the map but I'm really not sure it's worth it. >=20 > Robert.=20 > =20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 05 16:54: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 1Ip9tP-0002Fc-SV; Mon, 05 Nov 2007 16:53:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip9tO-0002Dd-OI for nfsv4@ietf.org; Mon, 05 Nov 2007 16:53:58 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip9tN-0004Td-Hm for nfsv4@ietf.org; Mon, 05 Nov 2007 16:53:58 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA5LrvNY002847 for ; Mon, 5 Nov 2007 21:53:57 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR100901ZEUHP00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Mon, 05 Nov 2007 14:53:57 -0700 (MST) Received: from [10.1.194.250] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR100ITWZHVLAA0@mail-amer.sun.com>; Mon, 05 Nov 2007 14:53:56 -0700 (MST) Date: Mon, 05 Nov 2007 15:53:54 -0600 From: Robert Gordon Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections 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: -1.0 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Nov 5, 2007, at 3:35 PM, Noveck, Dave wrote: >> Is there a case where it makes sense to complicate the meaning of >> "MDS FH" vs. "DS FH" by allowing this special case? > > It's the server that has the complexity when he receives an FH and > has to distinguish which one it is (when it may not be disguishable), > and thus which personality a given oepration is being directed at. A server could be implemented in such a way that the stateid conveys the fact that the IO is intended for the data-server persona... couldn't it ? Robert.. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 05 17:02: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 1IpA1d-0005KM-0v; Mon, 05 Nov 2007 17:02:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpA1b-0005Jr-M0 for nfsv4@ietf.org; Mon, 05 Nov 2007 17:02:27 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpA1b-0005sz-79 for nfsv4@ietf.org; Mon, 05 Nov 2007 17:02:27 -0500 X-IronPort-AV: E=Sophos;i="4.21,374,1188802800"; d="scan'208";a="119795323" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 05 Nov 2007 14:02:26 -0800 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 lA5M2QqS005273; Mon, 5 Nov 2007 14:02:26 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 14:02:26 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 14:02:26 -0800 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] Proposed resolutions for some pnfs-related[[Comment]]sections Date: Mon, 5 Nov 2007 17:02:24 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections Thread-Index: Acgf9mmYWUvpHOL8RcaHcQ9JwYMG7AAAIosA From: "Noveck, Dave" To: "Robert Gordon" X-OriginalArrivalTime: 05 Nov 2007 22:02:26.0141 (UTC) FILETIME=[8CE748D0:01C81FF7] X-Spam-Score: -4.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 Yes it could. In fact, there are reasons that they pretty well have to be distinguishable. An MDS-based stateid can reply on the cleintid (gotten from the sessionid) for uniqueness there the DS stateids which are going to be interpreted by DS's with other sessions don't have that ability. I think I'm going to try to come with attempt-2 to deal with this issue. One complexity is that there are some DS ops that don't have=20 stateids. -----Original Message----- From: Robert Gordon [mailto:Robert.Gordon@Sun.COM]=20 Sent: Monday, November 05, 2007 4:54 PM To: Noveck, Dave Cc: Muntz, Daniel; nfsv4@ietf.org Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections On Nov 5, 2007, at 3:35 PM, Noveck, Dave wrote: >> Is there a case where it makes sense to complicate the meaning of >> "MDS FH" vs. "DS FH" by allowing this special case? > > It's the server that has the complexity when he receives an FH and > has to distinguish which one it is (when it may not be disguishable), > and thus which personality a given oepration is being directed at. A server could be implemented in such a way that the stateid conveys the fact that the IO is intended for the data-server persona... =20 couldn't it ? Robert.. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 05 17:07: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 1IpA6G-0001zV-3C; Mon, 05 Nov 2007 17:07:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpA6E-0001zJ-SD for nfsv4@ietf.org; Mon, 05 Nov 2007 17:07:14 -0500 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 1IpA6D-0004xk-9V for nfsv4@ietf.org; Mon, 05 Nov 2007 17:07:14 -0500 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 lA5Lv627025491; Mon, 5 Nov 2007 16:57:06 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 5 Nov 2007 16:57:06 -0500 Received: from bh-buildlin1.bhalevy.com ([172.17.28.131]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 16:57:06 -0500 Message-ID: <472F91B0.9020905@panasas.com> Date: Mon, 05 Nov 2007 23:57:04 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Noveck, Dave" Subject: Re: [nfsv4] Device stateids (v3) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2007 21:57:06.0526 (UTC) FILETIME=[CE65E7E0:01C81FF6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: Marc Eshel , 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 Nov. 05, 2007, 23:39 +0200, "Noveck, Dave" wrote: >>> So, in this proposal are you suggesting that CB_DEVICENOTIFY >>> is a mandatory operation to implement at the client ? >> yes, pretty much as CB_DEVICERECALL was in the last proposal. >> The client can ignore the ADDED notifications though if it wants. > > pNFS is not a mandatory feature so I assume that a client can > return NFS4ERR_NOTSUPP. Are we saying you MUST NOT do that if > you have done one of the pNFS operations? This will make sense. and the same for CB_LAYOUTRECALL. for a MDS supporting pNFS, I'd say that the following operations must be implemented: GETDEVICEINFO, (GETDEVICELIST can remain optional) LAYOUTCOMMIT, LAYOUTGET, LAYOUTRETURN for a client that supports pNFS and issued one of the pNFS operations: CB_DEVICENOTIFY, CB_LAYOUTRECALL (if issued LAYOUTGET) > > > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com] > Sent: Monday, November 05, 2007 1:56 PM > To: Robert Gordon > Cc: Noveck, Dave; Marc Eshel; NFSv4 > Subject: Re: [nfsv4] Device stateids (v3) > > > On Nov. 05, 2007, 20:33 +0200, Robert Gordon wrote: >> On Nov 5, 2007, at 4:47 AM, Benny Halevy wrote: >> >>> I updated and hopefully simplified the proposal based on Dave's >>> comments. >>> >>> - device ID major/minor is used instead of devsetid. >>> - CB_DEVICERECALL merged into CB_DEVICENOTIFY (now used >>> for deletions, changes, and additions) >>> - removed DEVICERETURN >>> - defined new SEQ4_STATUS_DEVICE_STATE_REVOKED sequence flag. >>> >>> Benny >> So, in this proposal are you suggesting that CB_DEVICENOTIFY >> is a mandatory operation to implement at the client ? > > yes, pretty much as CB_DEVICERECALL was in the last proposal. > The client can ignore the ADDED notifications though if it wants. > >> also, i had thought that the deviceid moving from 32 bits to 64 >> was to accommodate maj/minor partitioning; now we have a 128 bit >> deviceid ?? is that really necessary ? > > not exactly. The move to 64 bit was to accommodate for the existing > 64-bit device IDs we have implemented in panfs. The 64-bit major > is to match fsid.major. This shouldn't be a big deal for files > as you have very few device IDs and only one in each layout. > For objects I thought of changing the pnfs-obj layout to have one major > for the layout and just minor for each device in the map but I'm > really not sure it's worth it. > >> 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 Mon Nov 05 17:54:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpApR-0006rf-Pc; Mon, 05 Nov 2007 17:53:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpApQ-0006rY-Sm for nfsv4@ietf.org; Mon, 05 Nov 2007 17:53:56 -0500 Received: from p01c11o146.mxlogic.net ([208.65.144.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpApP-0006Lz-M4 for nfsv4@ietf.org; Mon, 05 Nov 2007 17:53:56 -0500 Received: from unknown [63.110.244.103] (EHLO p01c11o146.mxlogic.net) by p01c11o146.mxlogic.net (mxl_mta-5.2.0-1) with ESMTP id 30f9f274.2486848432.71511.00-533.p01c11o146.mxlogic.net (envelope-from ); Mon, 05 Nov 2007 15:53:55 -0700 (MST) Received: from unknown [63.110.244.103] by p01c11o146.mxlogic.net (mxl_mta-5.2.0-1) with SMTP id 3bd9f274.1805007792.69361.00-002.p01c11o146.mxlogic.net (envelope-from ); Mon, 05 Nov 2007 15:48:19 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nfsv4] File Layout Questions (Layouts of the same file and Packing) Date: Mon, 5 Nov 2007 14:48:05 -0800 Message-ID: In-Reply-To: <875645.47299.qm@web38113.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] File Layout Questions (Layouts of the same file and Packing) Thread-Index: Acgc8qjOmcXd6jOaR4K0iLs8RPRp7gDCUyxQ References: <875645.47299.qm@web38113.mail.mud.yahoo.com> From: "Anatoly Pinchuk" To: , X-Spam: [F=0.3605544436; S=0.360(2007101601); SS=0.500] X-MAIL-FROM: X-SOURCE-IP: [63.110.244.103] X-Spam-Score: -1.0 (-) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 1. If the client file layouts can have different stripe unit sizes we = need more than just a text clarification. In that case the layout = structure should include additional information to calculate a data file = offset for dense packing. Offset returned in layout4 structure and = stripe unit size is not enough to do the calculation. Here is an = example: =A0 There are devices: struct nfsv4_1_file_layout_ds_addr4 dev0 =3D { // ID is 0 =A0=A0=A0 {0}, =A0=A0=A0 {{A}} }, dev1 =3D { // ID is 1 =A0=A0=A0 {0}, =A0=A0=A0 {{B}} }; =A0 File Layouts for a client file struct nfsv4_1_file_layout4 fl0 =3D { =A0=A0=A0 0, =A0=A0=A0 x, // stripe unit size of 0x400 is coded with x =A0=A0=A0 0, =A0=A0=A0 fh0 }, fl1 =3D { =A0=A0=A0 1, =A0=A0=A0 y, // stripe unit size of 0x1000 and dense packing are coded = with y =A0=A0=A0 0, =A0=A0=A0 fh1 }; =A0 fl0 and fl1 correspond to file ranges [0, 0x400-1] and [0x400, = 0x1400-1]; =A0 Now a client requests layout for an offset of 0x800 and length 0x400 and = the reply is: =A0 struct layout4 lo =3D { =A0=A0=A0 0x800, =A0=A0=A0 0x400, =A0=A0=A0 lo_iomode, // some=A0IO mode =A0=A0=A0 lo_content // see below }; =A0 struct layout_content4 lo_content =3D { =A0=A0=A0 LAYOUT4_NFSV4_1_FILES, =A0=A0=A0 loc_body // see below }; loc_body contains fl1 defined above. =A0 So, the client knows the server (B) and the file handle (fh1) to do IO = on. Offset for the fh1 is needed as well. The formula from paragraph = 14.5 does not provide correct offset since =A0 data_file_offset =3D floor(file_offset / stripe_width) * stripe_unit_size + file_offset % stripe_unit_size =3D floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 =3D 0x800; =A0 and the correct offset is rel_off =3D (file_offset - layout_offset) =3D (0x800 - 0x400) =3D 0x400; = data_file_offset =3D floor(rel_offset / stripe_width) * stripe_unit_size + rel_offset % stripe_unit_size =3D floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 =3D 0x400; =A0 Offset of first byte the layout is applicable to (layout_offset =3D = 0x400) is used in the calculation of the data file offset. Therefore, it = should be stored in the nfsv4_1_file_layout4 structure returned to the = client. 2. Packing can be kept in the layout, but doing so limits number of ways = the layouts can be created. Pathological example would be having just = two data servers A and B with dense and sparse packing = implemented=A0respectively. Then no=A0layout can correspond to both A = and B data file servers. In such configuration a multi-path can not be = created and client file data access parallelism can not be achieved at = all. A remedy could be storing the packing per data server. As for the = stripe unit size, since it describes the data distribution, it probably = should follow stripe indices and be stored in a device structure. In = general, packing and stripe unit size rather belong to the device than = layout. -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Thursday, November 01, 2007 6:50 PM To: Anatoly Pinchuk; nfsv4@ietf.org Subject: Re: [nfsv4] File Layout Questions (Layouts of the same file and = Packing) =20 > 1. Layouts of the same client file >=20 > There seems to be an agreement that more than one layout is possible > corresponding to a given client file. If so, it would be great to > describe if there are dependencies between the layouts of the same > file. > One interesting question is if the stripe unit size can be different > in > such layouts. The spec doesn't disallow this. If you want to suggest some test to make this clear, that would be welcome. > 2. Sparse or dense packing >=20 > Currently packing is stored in a layout which makes it impossible to > bring two data servers with different packing implementations under > the > same layout. Also, it is unlikely that a data server implements both > sparse and dense packing. Would it be more flexible then to have > packing > defined per equivalent data server group or even per data server? I thought the packing and stripe unit size should be in the device address, and asked this question of WG several on June 12, 2007. The consensus was to define it in the layout. So that's where we are. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 00:27: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 1IpGyW-0000ng-SH; Tue, 06 Nov 2007 00:27:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpGyW-0000na-6Q for nfsv4@ietf.org; Tue, 06 Nov 2007 00:27:44 -0500 Received: from web38114.mail.mud.yahoo.com ([209.191.124.141]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpGyV-0001Ig-Ph for nfsv4@ietf.org; Tue, 06 Nov 2007 00:27:44 -0500 Received: (qmail 97057 invoked by uid 60001); 6 Nov 2007 05:27:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=WfyR8gytrwCiGdHnYl2r2n+BIhHd8woUfa0r22XTBnf3pIrHShJm+ibqzs+yAeUOMVx/SRaVe8xsfbh5iQ5xFCAMdME3dfb31mEFv9tzeh2ye/1xEllCHUAccrwvwKSgjgnw1t58ebyAFXht/Ap0MLbnDprGT4zXuqD0ryTnD+4=; X-YMail-OSG: HLzLlM4VM1kXKw.wqAubvTUKwYrN0Skoo1qshOalmIIQc9Emo8RPOLQ5tECP65I6XR1jMOYgSw-- Received: from [198.95.226.230] by web38114.mail.mud.yahoo.com via HTTP; Mon, 05 Nov 2007 21:27:43 PST Date: Mon, 5 Nov 2007 21:27:43 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] question about nfs41 wrongsec processing rules To: nfsv4@ietf.org In-Reply-To: <9C9DEB0E-28DD-44A1-80E6-28D5C6DE8C3B@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <183086.96083.qm@web38114.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Jeff A. Smith" wrote: > Question: > If a client sent a NFS41 server the compound below, > and the current secflavor is not allowed, which op > can the server fail w/wrongsec? > > PUTFH* + SECINFO_NO_NAME(cur_fh) + OPEN(fh) > Note: PUTFH* is the same as the draft's > usage of "Put Filehandle operation") > > Answer: none? I agree that the literal interpretation of what is in draft-15 is "none". That obviously isn't what we want. I'm loath to add text to the spec that allows NFS4ERR_WRONGSEC in the final operation of: + SECINFO* + Client implementations that carefully construct COMPOUNDs shouldn't have to add NFS4ERR_WRONGSEC to its table of allowable error codes for every file-based operation in the protocol. Instead, I suggest we state that combinations that create the conundrum Jeff has pointed out get NFS4ERR_UNSAFE_COMPOUND. The server MAY return NFS4ERR_UNSAFE_COMPOUND or it the security tuple used is acceptable, it MAY allow to execute successfully. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 00:36: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 1IpH73-00008d-EQ; Tue, 06 Nov 2007 00:36:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpH72-000085-22 for nfsv4@ietf.org; Tue, 06 Nov 2007 00:36:32 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpH71-0001WS-LX for nfsv4@ietf.org; Tue, 06 Nov 2007 00:36:31 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA65aUuP026664 for ; Tue, 6 Nov 2007 05:36:30 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR200801KS1AT00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 05 Nov 2007 22:36:30 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR200A48KWPQD50@mail-amer.sun.com>; Mon, 05 Nov 2007 22:36:30 -0700 (MST) Date: Mon, 05 Nov 2007 23:36:52 -0600 From: Spencer Shepler Subject: Re: [nfsv4] question about nfs41 wrongsec processing rules In-reply-to: <183086.96083.qm@web38114.mail.mud.yahoo.com> To: email2mre-ietf@yahoo.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: <183086.96083.qm@web38114.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Nov 5, 2007, at 11:27 PM, Mike Eisler wrote: > > --- "Jeff A. Smith" wrote: > > >> Question: >> If a client sent a NFS41 server the compound below, >> and the current secflavor is not allowed, which op >> can the server fail w/wrongsec? >> >> PUTFH* + SECINFO_NO_NAME(cur_fh) + OPEN(fh) >> Note: PUTFH* is the same as the draft's >> usage of "Put Filehandle operation") >> >> Answer: none? > > I agree that the literal interpretation of what is in draft-15 > is "none". That obviously isn't what we want. > > I'm loath to add text to the spec that allows NFS4ERR_WRONGSEC in the > final operation of: > > + SECINFO* + > > Client implementations that carefully construct COMPOUNDs shouldn't > have > to add NFS4ERR_WRONGSEC to its table of allowable error codes for > every file-based operation in the protocol. > > Instead, I suggest we state that combinations that create > the conundrum Jeff has pointed out get NFS4ERR_UNSAFE_COMPOUND. > The server MAY return NFS4ERR_UNSAFE_COMPOUND or it the security > tuple used is acceptable, it MAY allow to execute > successfully. I am okay with this; essentially the client is strongly discouraged from constructing COMPOUNDs of this nature and if it chooses to then the NFS4ERR_UNSAFE_COMPOUND can be interpreted similarly to the receipt of WRONGSEC. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 00:53:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpHNi-000321-Nr; Tue, 06 Nov 2007 00:53:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpHNi-00031h-0u for nfsv4@ietf.org; Tue, 06 Nov 2007 00:53:46 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpHNe-0007pc-I9 for nfsv4@ietf.org; Tue, 06 Nov 2007 00:53:46 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA65rfCF011619 for ; Tue, 6 Nov 2007 05:53:41 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR200401LOSBE00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 05 Nov 2007 22:53:41 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR200BTZLPH0M30@mail-amer.sun.com> for nfsv4@ietf.org; Mon, 05 Nov 2007 22:53:41 -0700 (MST) Date: Mon, 05 Nov 2007 23:54:08 -0600 From: Spencer Shepler Subject: Re: [nfsv4] GETDEVICEINFO and GETDEVICELIST in the draft-15 spec In-reply-to: <39CF2A4B63947142A66EAA65B2FDF2F005BDD2D6@CORPUSMX40A.corp.emc.com> To: NFSv4 Message-id: <0C695516-F373-44C4-B3DC-BEEC2AD3A959@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.3) Content-type: text/plain; format=flowed; delsp=yes; charset=WINDOWS-1252 Content-transfer-encoding: QUOTED-PRINTABLE References: <39CF2A4B63947142A66EAA65B2FDF2F005BDD2D6@CORPUSMX40A.corp.emc.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Nov 1, 2007, at 2:09 PM, Glasgow_Jason@emc.com wrote: > I have two minor issues with the draft-15 spec related to =20 > GETDEVICEINFO and GETDEVICELIST. The spec does not adequately = =20 > specify the meaning of gdia_maxcount. The sentence describing its = =20 > usage states: > > > > =93The client provides gdia_maxcount to limit the amount of device = =20 > address information to be returned for the mapping. If the mapping = =20 > can not be returned within the maximum specified, NFS4ERR_TOOSMALL = =20 > is returned.=94 > > > > This sentence does not make clear if gdia_maxount limits the number= =20 > of bytes in the GETDEVICEINFO4res data structure, within the =20 > =93device_addr4=94 structure, or within the protocol specific opaqu= e =20 > data =93da_addr_body=94. I propose that the wording be changed to = =20 > clarify that this refers to the number of bytes in the =20 > =93device_addr4=94 portion of the response. I agree that the use of gdia_maxcount is underspecified. However, I would prefer the the "maxcount" be interpreted as it is for the READDIR operation. Quoting from that operation description: "The maxcount value of the argument is the maximum number of bytes= =20 for the result. This maximum size represents all of the data being returned within the READDIR4resok structure and includes the XDR overhead. The server may return less data. If the server is una= ble to return a single directory entry within the maxcount limit, the error NFS4ERR_TOOSMALL will be returned to the client." Therefore, I would suggest the text for GETDEVICEINFO be: "The client provides gdia_maxcount to limit the number of bytes for t= he result. This maximum size represents all of the data being returne= d within the GETDEVICEINFO4resok structure and includes the XDR overhead. The server may return less data. If the server is unabl= e to return the information within the gdia_maxcount limit, the error NFS4ERR_TOOSMALL will be returned." And for GETDEVICELIST: "The client provides gdla_maxcount to limit the number of bytes for t= he result. This maximum size represents all of the data being returne= d within the GETDEVICELIST4resok structure and includes the XDR overhead. The server may return less data. If the server is unabl= e to return a single entry device list item within the gdla_maxcount limit, the error NFS4ERR_TOOSMALL will be returned." The remaining suggestions of adding NFS4ERR_TOOSMALL to the return union is fine with me. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 05:39: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 1IpLq8-0006KQ-W0; Tue, 06 Nov 2007 05:39:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpLq8-0006Iz-2D for nfsv4@ietf.org; Tue, 06 Nov 2007 05:39:24 -0500 Received: from web38108.mail.mud.yahoo.com ([209.191.124.135]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpLq7-0001Sw-LU for nfsv4@ietf.org; Tue, 06 Nov 2007 05:39:23 -0500 Received: (qmail 58203 invoked by uid 60001); 6 Nov 2007 10:39:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=d07lko1vSnIcDygI8Lpx//KXi4iDVm6nRHJfAeEg1lLTwwUJqYcCpHAB8NPYIzPk4irI6MPDVeS+TMX5ESvTzlQz4h4qyfK45azilJa97mGW04iA/ruOfB0dbFZG+cMgMcRnclnJlWqlprL1A2m79JrF3UWPIFg+9YOg5cUWirQ=; X-YMail-OSG: 3F82Z50VM1kQMt.9CuPptozYEUlkVaOTpITsbJ4NVg6.LwUc96qNH2Xn0EDVvntKm.mX28BrGA-- Received: from [198.95.226.230] by web38108.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2007 02:39:22 PST Date: Tue, 6 Nov 2007 02:39:22 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] Request for an additional recommended attribute To: nfsv4@ietf.org In-Reply-To: <39CF2A4B63947142A66EAA65B2FDF2F005C372C3@CORPUSMX40A.corp.emc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <953430.57905.qm@web38108.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Jason, This all looks good. --- Glasgow_Jason@emc.com wrote: > Mike, > > I am happy to use the layout hint to communicate to the server. I > will > update the block spec accordingly. I agree that "hint" is now a > misnomer, but I can live with that. > > As to changing the SLA from 30 to 60 seconds, the block spec will be > updated to allow for two behaviors. I'm working on the exact > wording, > but it will be something like: > > A server which implements fencing can accept any maximum timeout > value > from a client, and then fence the storage immediately if the lease > expires. > > A server which does not implement fencing and does not wish to change > the SLA, can return an error to the SETATTR operation. When a client > receives the error NFS4ERR_INVAL in response to the SETATTR operation > for layout hints, the client MUST NOT use the LAYOUTGET operation. > After responding with NFS4ERR_INVAL to the SETATTR for layout hint, > the > server MUST return an error to all subsequent LAYOUTGET operations > from > that client. > > I think this should address your concerns. > > -Jason _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 05:41: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 1IpLs5-0007vW-PL; Tue, 06 Nov 2007 05:41:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpLs4-0007vR-G3 for nfsv4@ietf.org; Tue, 06 Nov 2007 05:41:24 -0500 Received: from web38101.mail.mud.yahoo.com ([209.191.124.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IpLs1-0006j9-5D for nfsv4@ietf.org; Tue, 06 Nov 2007 05:41:24 -0500 Received: (qmail 19826 invoked by uid 60001); 6 Nov 2007 10:41:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=592omK0HSRcry+PcrdhwrFD/HH+FvEqCLLNtr9bcnn7dxm8IpybQt4tDKnPPmAL7wr5Z8VxyAraB1PsmWE4uaIKHhQ0qZDqreqOlVtIDGUBW/Q+LV8jbZM0BYIK7wodxEj6yAaF3jKCdki3ILq6RbCbQ98+RSZcff691zJqxRJw=; X-YMail-OSG: eZ3kL4kVM1lPhcYyoyYmi.85zWKi_9uyWRrjL9_OGM094Ji_HkGUgNbNMo.nS0wZthRufA-- Received: from [198.95.226.230] by web38101.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2007 02:41:20 PST Date: Tue, 6 Nov 2007 02:41:20 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] Device stateids (v3) To: Benny Halevy , "Noveck, Dave" In-Reply-To: <472F91B0.9020905@panasas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <501153.19641.qm@web38101.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Marc Eshel , NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Benny Halevy wrote: > for a client that supports pNFS and issued one of the pNFS > operations: > CB_DEVICENOTIFY, > CB_LAYOUTRECALL (if issued LAYOUTGET) Why can't CB_NOTIFY be used in instead of CB_DEVICENOTIFY? _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 05: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 1IpM9q-0004e5-6C; Tue, 06 Nov 2007 05:59:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpM9o-0004au-Ta for nfsv4@ietf.org; Tue, 06 Nov 2007 05:59:44 -0500 Received: from web38113.mail.mud.yahoo.com ([209.191.124.140]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IpM9l-0007Do-4T for nfsv4@ietf.org; Tue, 06 Nov 2007 05:59:44 -0500 Received: (qmail 10945 invoked by uid 60001); 6 Nov 2007 10:59:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=KzrzTF5IGE/mVSDM38MA/QxJJn9hqmdcF1f36DmO3n/lg+pQISg/ccSa/TaMuKe+HRHdPeJk//XTOnVhRTxvrfYXPdyup32xGXGc2QIxe1o8flCWWPuJ1uQGdFy8k/kyHsx7qsK+p6veaHPXhxF3n+KcqdBzgU3AeMOYLEAfkis=; X-YMail-OSG: vmUmeSsVM1lDAK.6XBjmRLnuCsRs61RRbWXFgwYb4EavhvXdESHEbd1q.ZkWiDjaTlhu4UQrHg-- Received: from [198.95.226.230] by web38113.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2007 02:59:40 PST Date: Tue, 6 Nov 2007 02:59:40 -0800 (PST) From: Mike Eisler To: nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <746006.10804.qm@web38113.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [nfsv4] Directory Delegation Push - Not Needed X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org To come back to issue Dave describes below, I think we do not have support the pushing or notification of directory delegations. So in other words, nothing more to do. My reasoning is that because we have no way to establish an "open" reference on a directory, and because we have to way to open a directory for writing, a directory delegation isn't going to be denied due to contention with a writer, then we don't need to push a delegation (or extend CB_NOTIFY to notify the client that the contention is no longer present). While it is true a lazy server could refuse a directory delegation if the directory is currently have a modification (e.g. file create) performed on it, we should not complicate the protocol to support lazy servers. The non-lazy server would just queue the delegation request after all the modification requests. The half-way lazy server would just return NFS4ERR_DELAY (Need to check if NFS4ERR_DELAY is among the list of errors GET_DIR_DELEGATION can return). --- "Noveck, Dave" wrote: > I recall that we had a discussion about whether CB_PUSH_DELEG could > in > fact > propagate a delegation requested by GET_DIR_DELEGATION, as opposed to > delegation > for non-directory types of objects. I guess there was also > implicitly a > question > about whether it should be able to do so. > > So on the first point, the answer seems to be "No" since > CB_PUSH_DELEGargs > contains an open_delegation4, which doesn't have a provision for a > lot > of the > data returned in a GET_DIR_DELEGATION4resok. Since this information > is > not > provided on the response to the GET_DIR_DELEGATION or in the > CB_PUSH_DELEG, > it doesn't seem that there is a current provision for CB_PUSH_DELEG > to > deliver a directory delegation. > > In fact, there is no provision currently for GET_DIR_DELEGATION to > promise > to deliver a directory delegation when the delgation is available > (i.e. > there > is no conflict on that specific object), which would call for > CB_PUSH_DELEG > or something like it. The only provision in which it promises to > signal > you > is when there is resources unavailable, i.e. something will be > resolved > by > CB_RECALLABLE_OBJ_AVAIL. > > I'm supposing that this structure derives from the fact that there > are > no > write directory delegations and it is thus impossible for there to be > a > hard conflict that would not allow a directory delegation to be > granted. > I'm not sure if this logic is valid since it is possible for a server > not > to grant a directory delegation because frequent directory changes > makes > this not an efficient way to go. And if that could cause a > delegation > to be denied, the situation might be changed when those changes stop. > > Anyway, what I am going to do now is to change CB_PUSH_DELEG so it > doens't > reference GET_DIR_DELEGATION and if we want to extend > GET_DIR_DELEGATION > > and CB_PUSH_DELEG to support this, we can handle that separately from > the > review of the locking chapters. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 06:05: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 1IpMFk-00055R-WD; Tue, 06 Nov 2007 06:05:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpMFh-0004vh-Ty for nfsv4@ietf.org; Tue, 06 Nov 2007 06:05:51 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpMFh-0002Vo-ES for nfsv4@ietf.org; Tue, 06 Nov 2007 06:05:49 -0500 X-IronPort-AV: E=Sophos;i="4.21,377,1188802800"; d="scan'208";a="119941848" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 06 Nov 2007 03:05:33 -0800 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 lA6B5XEM015481; Tue, 6 Nov 2007 03:05:33 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 03:05:33 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 03:05:32 -0800 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] question about nfs41 wrongsec processing rules Date: Tue, 6 Nov 2007 06:05:30 -0500 Message-ID: In-Reply-To: <183086.96083.qm@web38114.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] question about nfs41 wrongsec processing rules Thread-Index: AcggNhPho/2rMjn7TVqio2wSJ7jm2QALS4uw From: "Noveck, Dave" To: , X-OriginalArrivalTime: 06 Nov 2007 11:05:32.0734 (UTC) FILETIME=[F31865E0:01C82064] 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 > Client implementations that carefully construct COMPOUNDs=20 > shouldn't have to add NFS4ERR_WRONGSEC to its table of=20 > allowable error codes for every file-based operation in=20 > the protocol. Why not? > Instead, I suggest we state that combinations that create=20 > the conundrum Jeff has pointed out get NFS4ERR_UNSAFE_COMPOUND. How is adding UNSAFE_COMPOUND to the table, different from ading WRONGSEC, except that when you get it you are likely to be more confused. I know that as of draft-15, the error/op table does allow this, but right now the majority opinion is to get rid of it in all the ops where it can't happen, given the only thing the spec says=20 about UNSAFE_COMPOUND: o A server MAY return NFS4ERR_UNSAFE_COMPOUND to a non-idempotent current filehandle change operation, if it looks at the next operation (in the same COMPOUND procedure) and finds it is not GETFH. The server SHOULD do this if it is unable to determine in advance whether the total response size would exceed ca_maxresponsesize_cached or ca_maxresponsesize. > The server MAY return NFS4ERR_UNSAFE_COMPOUND or it the security=20 > tuple used is acceptable, it MAY allow to execute successfully. Does it make sense to turn USAFE_COMPOUND into a grab-bag of different error situations and apply it to all the ops where any of those can occur, or even even all ops? =20 -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Tuesday, November 06, 2007 12:28 AM To: nfsv4@ietf.org Subject: Re: [nfsv4] question about nfs41 wrongsec processing rules --- "Jeff A. Smith" wrote: > Question: > If a client sent a NFS41 server the compound below, > and the current secflavor is not allowed, which op > can the server fail w/wrongsec? >=20 > PUTFH* + SECINFO_NO_NAME(cur_fh) + OPEN(fh) > Note: PUTFH* is the same as the draft's > usage of "Put Filehandle operation") >=20 > Answer: none? I agree that the literal interpretation of what is in draft-15 is "none". That obviously isn't what we want. I'm loath to add text to the spec that allows NFS4ERR_WRONGSEC in the final operation of: + SECINFO* + Client implementations that carefully construct COMPOUNDs shouldn't have to add NFS4ERR_WRONGSEC to its table of allowable error codes for every file-based operation in the protocol. Instead, I suggest we state that combinations that create the conundrum Jeff has pointed out get NFS4ERR_UNSAFE_COMPOUND. The server MAY return NFS4ERR_UNSAFE_COMPOUND or it the security tuple used is acceptable, it MAY allow to execute successfully. _______________________________________________ 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 Nov 06 06: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 1IpMJo-0004JQ-7V; Tue, 06 Nov 2007 06:10:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpMJn-0004Im-4y for nfsv4@ietf.org; Tue, 06 Nov 2007 06:10:03 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpMJj-0007f4-IQ for nfsv4@ietf.org; Tue, 06 Nov 2007 06:10:03 -0500 X-IronPort-AV: E=Sophos;i="4.21,378,1188802800"; d="scan'208";a="119942393" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 06 Nov 2007 03:09:36 -0800 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 lA6B9aA9012378; Tue, 6 Nov 2007 03:09:36 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 03:09:35 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 03:09:35 -0800 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] GETDEVICEINFO and GETDEVICELIST in the draft-15 spec Date: Tue, 6 Nov 2007 06:09:33 -0500 Message-ID: In-Reply-To: <0C695516-F373-44C4-B3DC-BEEC2AD3A959@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] GETDEVICEINFO and GETDEVICELIST in the draft-15 spec Thread-Index: AcggOaE3HZWq77jxT1ucGRFkaER+kwAK82MA From: "Noveck, Dave" To: "Spencer Shepler" , "NFSv4" X-OriginalArrivalTime: 06 Nov 2007 11:09:35.0659 (UTC) FILETIME=[83E3CFB0:01C82065] X-Spam-Score: -4.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 NFS4ERR_TOOSMALL is already specified as a valid error for these ops.=20 -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Tuesday, November 06, 2007 12:54 AM To: NFSv4 Subject: Re: [nfsv4] GETDEVICEINFO and GETDEVICELIST in the draft-15 spec On Nov 1, 2007, at 2:09 PM, Glasgow_Jason@emc.com wrote: > I have two minor issues with the draft-15 spec related to=20 > GETDEVICEINFO and GETDEVICELIST. The spec does not adequately specify > the meaning of gdia_maxcount. The sentence describing its usage=20 > states: > > > > "The client provides gdia_maxcount to limit the amount of device=20 > address information to be returned for the mapping. If the mapping can > not be returned within the maximum specified, NFS4ERR_TOOSMALL is=20 > returned." > > > > This sentence does not make clear if gdia_maxount limits the number of > bytes in the GETDEVICEINFO4res data structure, within the=20 > "device_addr4" structure, or within the protocol specific opaque data=20 > "da_addr_body". I propose that the wording be changed to clarify that > this refers to the number of bytes in the "device_addr4" portion of=20 > the response. I agree that the use of gdia_maxcount is underspecified. However, I would prefer the the "maxcount" be interpreted as it is for the READDIR operation. Quoting from that operation description: "The maxcount value of the argument is the maximum number of bytes for the result. This maximum size represents all of the data being returned within the READDIR4resok structure and includes the XDR overhead. The server may return less data. If the server is unable to return a single directory entry within the maxcount limit, the error NFS4ERR_TOOSMALL will be returned to the client." Therefore, I would suggest the text for GETDEVICEINFO be: "The client provides gdia_maxcount to limit the number of bytes for the result. This maximum size represents all of the data being returned within the GETDEVICEINFO4resok structure and includes the XDR overhead. The server may return less data. If the server is unable to return the information within the gdia_maxcount limit, the error NFS4ERR_TOOSMALL will be returned." And for GETDEVICELIST: "The client provides gdla_maxcount to limit the number of bytes for the result. This maximum size represents all of the data being returned within the GETDEVICELIST4resok structure and includes the XDR overhead. The server may return less data. If the server is unable to return a single entry device list item within the gdla_maxcount limit, the error NFS4ERR_TOOSMALL will be returned." The remaining suggestions of adding NFS4ERR_TOOSMALL to the return union is fine with me. 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 Nov 06 06: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 1IpMYz-0003fF-5W; Tue, 06 Nov 2007 06:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpMYx-0003dk-EE for nfsv4@ietf.org; Tue, 06 Nov 2007 06:25:43 -0500 Received: from web38115.mail.mud.yahoo.com ([209.191.124.142]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IpMYu-00088R-RB for nfsv4@ietf.org; Tue, 06 Nov 2007 06:25:43 -0500 Received: (qmail 53963 invoked by uid 60001); 6 Nov 2007 11:25:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=up46sFtoH5++PipuczIdjpSsTyoVs6CQkeQD4SGJa7i0rm1bsjx6YDJIau16I19hIP3CMfgdrf00Bcb5eMg4PqTBGqUVe6ReLaNdtYHkxMfMo9VN7f5Ca9oH5A/g0SLK6c8Qbq8Zdm1P8VTTuqHidvtdT+2miLS0atmLkarpk3g=; X-YMail-OSG: Jl8Yj0UVM1ndorVkJUPCMF3k_OTS1l4QIfxgXvDEoHVkJlO5cOeRU2t56.piPSxGAn1Ms05MX6DKndJKJTIhcr7lVXdHFjwzrg9b93TpaKSk.6ZqPdw- Received: from [198.95.226.230] by web38115.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2007 03:25:39 PST Date: Tue, 6 Nov 2007 03:25:39 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] question about nfs41 wrongsec processing rules To: nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <244375.53263.qm@web38115.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > > Client implementations that carefully construct COMPOUNDs > > shouldn't have to add NFS4ERR_WRONGSEC to its table of > > allowable error codes for every file-based operation in > > the protocol. > > Why not? I recall this was feedback client implementors gave dating back to before RFC3530 was published. > > > Instead, I suggest we state that combinations that create > > the conundrum Jeff has pointed out get NFS4ERR_UNSAFE_COMPOUND. > > How is adding UNSAFE_COMPOUND to the table, different from > ading WRONGSEC, except that when you get it you are likely to > be more confused. The client that causes NFS4ERR_UNSAFE_COMPOUND to be returned is doing something wrong. Recovery isn't possible. Whereas, NFS4ERR_WRONGSEC doesn't indicate the client is doing something wrong, and the rules for NFS4ERR_WRONGSEC are intended to allow the client to recover). > I know that as of draft-15, the error/op table does allow this, > but right now the majority opinion is to get rid of it in all the > ops where it can't happen, given the only thing the spec says > about UNSAFE_COMPOUND: > > o A server MAY return NFS4ERR_UNSAFE_COMPOUND to a non-idempotent > current filehandle change operation, if it looks at the next > operation (in the same COMPOUND procedure) and finds it is not > GETFH. The server SHOULD do this if it is unable to determine > in > advance whether the total response size would exceed > ca_maxresponsesize_cached or ca_maxresponsesize. > NFS4ERR_UNSAFE_COMPOUND is arguably about a badly constructed COMPOUND request. The "UNSAFE" might be more generalized to be "BAD". So the text could be: A server MAY return NFS4ERR_BAD_COMPOUND from * a non-idempotent current filehandle change operation, if it looks at the next operation (in the same COMPOUND procedure) and finds it is not GETFH. The server SHOULD do this if it is unable to determine in advance whether the total response size would exceed ca_maxresponsesize_cached or ca_maxresponsesize. * any operation in a COMPOUND if it consists of a put filehandle operation followed by SECINFO or SECINFO_NO_NAME, and an operation after SECINFO or SECINFO_NO_NAME uses the filehandle specified in the put filehandle operation. Or we could create another error code, and leave NFS4ERR_UNSAFE_COMPOUND as is. > > The server MAY return NFS4ERR_UNSAFE_COMPOUND or it the security > > tuple used is acceptable, it MAY allow to execute > successfully. > > Does it make sense to turn USAFE_COMPOUND into a grab-bag of > different > error situations and apply it to all the ops where any of those can > occur, > or even even all ops? > > > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > Sent: Tuesday, November 06, 2007 12:28 AM > To: nfsv4@ietf.org > Subject: Re: [nfsv4] question about nfs41 wrongsec processing rules > > > --- "Jeff A. Smith" wrote: > > > > Question: > > If a client sent a NFS41 server the compound below, > > and the current secflavor is not allowed, which op > > can the server fail w/wrongsec? > > > > PUTFH* + SECINFO_NO_NAME(cur_fh) + OPEN(fh) > > Note: PUTFH* is the same as the draft's > > usage of "Put Filehandle operation") > > > > Answer: none? > > I agree that the literal interpretation of what is in draft-15 is > "none". That obviously isn't what we want. > > I'm loath to add text to the spec that allows NFS4ERR_WRONGSEC in the > final operation of: > > + SECINFO* + > > Client implementations that carefully construct COMPOUNDs shouldn't > have > to add NFS4ERR_WRONGSEC to its table of allowable error codes for > every > file-based operation in the protocol. > > Instead, I suggest we state that combinations that create the > conundrum > Jeff has pointed out get NFS4ERR_UNSAFE_COMPOUND. > The server MAY return NFS4ERR_UNSAFE_COMPOUND or it the security > tuple > used is acceptable, it MAY allow to execute successfully. > > > > _______________________________________________ > 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 Nov 06 07:08: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 1IpNEA-0003Vd-0u; Tue, 06 Nov 2007 07:08:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpNE8-0003St-I6 for nfsv4@ietf.org; Tue, 06 Nov 2007 07:08:16 -0500 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 1IpNE3-0000h6-IK for nfsv4@ietf.org; Tue, 06 Nov 2007 07:08:16 -0500 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 lA6C4q30008096; Tue, 6 Nov 2007 07:04:52 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 6 Nov 2007 07:04:52 -0500 Received: from [127.0.0.1] ([172.17.28.131]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 07:04:51 -0500 Message-ID: <4730585D.3010608@panasas.com> Date: Tue, 06 Nov 2007 14:04:45 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: email2mre-ietf@yahoo.com Subject: Re: [nfsv4] Device stateids (v3) References: <501153.19641.qm@web38101.mail.mud.yahoo.com> In-Reply-To: <501153.19641.qm@web38101.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2007 12:04:51.0644 (UTC) FILETIME=[3C5EF7C0:01C8206D] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Noveck, Dave" , NFSv4 , 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 Mike Eisler wrote: > --- Benny Halevy wrote: > > > >> for a client that supports pNFS and issued one of the pNFS >> operations: >> CB_DEVICENOTIFY, >> CB_LAYOUTRECALL (if issued LAYOUTGET) >> > > Why can't CB_NOTIFY be used in instead of CB_DEVICENOTIFY? > > Well, it can, but I think overloading a callback meant for directory notifications doesn't make the the client's life any easier. The fact that device mapping resemble directory delegations by the fact that entries can be added, changed, or deleted from the state is insufficient IMO since the actual notification contents are totally different. Having a separate callback operation for device notifications rather than doing both device and directory notification using the same callback is simpler to understand and to implement. since the respective xdr routine and the upper layer service wouldn't have to fork on the notification type to see if they're dealing with a directory or with device IDs. Benny _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 07:44: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 1IpNnC-0006JP-5k; Tue, 06 Nov 2007 07:44:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpNnA-0006JG-OY for nfsv4@ietf.org; Tue, 06 Nov 2007 07:44:28 -0500 Received: from web38104.mail.mud.yahoo.com ([209.191.124.131]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpNnA-0005Sd-Bq for nfsv4@ietf.org; Tue, 06 Nov 2007 07:44:28 -0500 Received: (qmail 13874 invoked by uid 60001); 6 Nov 2007 12:44:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=sXk4FMOdbBijRIMQEnIcuwPPZi25dJz2hHhR70QEwXE8sRWUPvUHnrbPzyQWoWqdBb0K2dQRg/sxpiS7vVxi4Tz3W7vy8qBexnWcQ/Ka/A63JwwcdX+79GfEga44ZY7lTPL+caa6FE6a9xQeFGRILC52OwsgpnAsEuMs3b3beGo=; X-YMail-OSG: 3UhJuXUVM1nMHjVHxgNX4BtHgWM7jbcLHoOffgdmbJq1shM.jtGVNj7ygtirnPyzrW1Ijq2nPg-- Received: from [198.95.226.230] by web38104.mail.mud.yahoo.com via HTTP; Tue, 06 Nov 2007 04:44:27 PST Date: Tue, 6 Nov 2007 04:44:27 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] Device stateids (v3) To: nfsv4@ietf.org In-Reply-To: <4730585D.3010608@panasas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <767629.13341.qm@web38104.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Benny Halevy wrote: > Mike Eisler wrote: > > --- Benny Halevy wrote: > > > > > > > >> for a client that supports pNFS and issued one of the pNFS > >> operations: > >> CB_DEVICENOTIFY, > >> CB_LAYOUTRECALL (if issued LAYOUTGET) > >> > > > > Why can't CB_NOTIFY be used in instead of CB_DEVICENOTIFY? > > > > > Well, it can, but I think overloading a callback meant for directory And in draft-15, it does. This change was made in draft-15 based on a perceived rough consensus reach months ago. I've read reports of complaints during last months bake-a-thon, but those complaints were never aired on the WG list or in an official WG meeting. There isn't great deal of time left to make edits and we've got substantive changes to make. Unfortunately, adding a new op is something that we don't always get right the first time. > notifications > doesn't make the the client's life any easier. The fact that device > mapping resemble > directory delegations by the fact that entries can be added, changed, > or > deleted > from the state is insufficient IMO since the actual notification > contents > are totally different. Which is analogous to saying that because ACLs are totally different from file size, two separate operations should be used for retrieving ACLs and file sizes. But instead we have a bitmask for GETATTR to allow clients to selectively get attributes they are interested in. Similarly CB_NOTIFY uses a bitmap to selectively push events. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 08:25: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 1IpOQs-0008VY-HM; Tue, 06 Nov 2007 08:25:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpOQq-0008UJ-Gz for nfsv4@ietf.org; Tue, 06 Nov 2007 08:25:28 -0500 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 1IpOQo-0002tG-2Y for nfsv4@ietf.org; Tue, 06 Nov 2007 08:25:28 -0500 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 lA6DPNdk009378; Tue, 6 Nov 2007 08:25:23 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 6 Nov 2007 08:25:23 -0500 Received: from [127.0.0.1] ([172.17.28.131]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 08:25:20 -0500 Message-ID: <47306B3A.2090908@panasas.com> Date: Tue, 06 Nov 2007 15:25:14 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: [nfsv4] GETDEVICEINFO and GETDEVICELIST in the draft-15 spec References: <39CF2A4B63947142A66EAA65B2FDF2F005BDD2D6@CORPUSMX40A.corp.emc.com> <0C695516-F373-44C4-B3DC-BEEC2AD3A959@sun.com> In-Reply-To: <0C695516-F373-44C4-B3DC-BEEC2AD3A959@sun.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 06 Nov 2007 13:25:21.0096 (UTC) FILETIME=[7AF2DC80:01C82078] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cassoulet.panasas.com id lA6DPNdk009378 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Spencer Shepler wrote: > > On Nov 1, 2007, at 2:09 PM, Glasgow_Jason@emc.com wrote: > >> I have two minor issues with the draft-15 spec related to=20 >> GETDEVICEINFO and GETDEVICELIST. The spec does not adequately=20 >> specify the meaning of gdia_maxcount. The sentence describing its=20 >> usage states: >> >> >> >> =93The client provides gdia_maxcount to limit the amount of device=20 >> address information to be returned for the mapping. If the mapping=20 >> can not be returned within the maximum specified, NFS4ERR_TOOSMALL is=20 >> returned.=94 >> >> >> >> This sentence does not make clear if gdia_maxount limits the number=20 >> of bytes in the GETDEVICEINFO4res data structure, within the=20 >> =93device_addr4=94 structure, or within the protocol specific opaque d= ata=20 >> =93da_addr_body=94. I propose that the wording be changed to clarify=20 >> that this refers to the number of bytes in the =93device_addr4=94 port= ion=20 >> of the response. > > I agree that the use of gdia_maxcount is underspecified. > > However, I would prefer the the "maxcount" be interpreted > as it is for the READDIR operation. > > Quoting from that operation description: > "The maxcount value of the argument is the maximum number of bytes fo= r > the result. This maximum size represents all of the data being > returned within the READDIR4resok structure and includes the XDR > overhead. The server may return less data. If the server is unable > to return a single directory entry within the maxcount limit, the > error NFS4ERR_TOOSMALL will be returned to the client." > > Therefore, I would suggest the text for GETDEVICEINFO be: > > "The client provides gdia_maxcount to limit the number of bytes for the > result. This maximum size represents all of the data being returned > within the GETDEVICEINFO4resok structure and includes the XDR > overhead. The server may return less data. If the server is unable > to return the information within the gdia_maxcount limit, the error > NFS4ERR_TOOSMALL will be returned." > > And for GETDEVICELIST: > > "The client provides gdla_maxcount to limit the number of bytes for the > result. This maximum size represents all of the data being returned > within the GETDEVICELIST4resok structure and includes the XDR > overhead. The server may return less data. If the server is unable > to return a single entry device list item within the gdla_maxcount > limit, the error NFS4ERR_TOOSMALL will be returned." > > > The remaining suggestions of adding NFS4ERR_TOOSMALL to the > return union is fine with me. > I agree with Spencer. This was my interpretation too. > > 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 LilianosakaBain@libraryspot.com Tue Nov 06 08:28:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpOTs-0002nl-0g; Tue, 06 Nov 2007 08:28:36 -0500 Received: from cpe-71-74-124-53.neo.res.rr.com ([71.74.124.53] helo=lem3956) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpOTr-0006pV-NZ; Tue, 06 Nov 2007 08:28:35 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host20986065.libraryspot.com (8.13.1/8.13.1) with SMTP id MEx8QPWT86.504241.sxL.cQD.3491878452840 for ; Tue, 6 Nov 2007 08:28:30 +0500 Message-ID: <29e35701c82078$fb13c3c0$0202a8c0@lem3956> From: "Eddie Gifford" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_29E353_01C82078.FB13C3C0-- From nfsv4-bounces@ietf.org Tue Nov 06 09:13: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 1IpPBh-0000lc-65; Tue, 06 Nov 2007 09:13:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpPBg-0000kD-8f for nfsv4@ietf.org; Tue, 06 Nov 2007 09:13:52 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpPBf-0008Cl-Ot for nfsv4@ietf.org; Tue, 06 Nov 2007 09:13:52 -0500 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 lA6EDo0X004005; Tue, 6 Nov 2007 09:13:50 -0500 (EST) Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lA6EDfoR004609; Tue, 6 Nov 2007 09:13:48 -0500 (EST) From: Glasgow_Jason@emc.com Received: from CORPUSMX40A.corp.emc.com ([10.254.64.47]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 09:13:40 -0500 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] GETDEVICEINFO and GETDEVICELIST in the draft-15 spec Date: Tue, 6 Nov 2007 09:13:38 -0500 Message-ID: <39CF2A4B63947142A66EAA65B2FDF2F005C37F72@CORPUSMX40A.corp.emc.com> In-Reply-To: <47306B3A.2090908@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] GETDEVICEINFO and GETDEVICELIST in the draft-15 spec Thread-Index: AcggeLn95uaJryPTQVyjmI6fXxVUUQABgrIg References: <39CF2A4B63947142A66EAA65B2FDF2F005BDD2D6@CORPUSMX40A.corp.emc.com><0C695516-F373-44C4-B3DC-BEEC2AD3A959@sun.com> <47306B3A.2090908@panasas.com> To: , X-OriginalArrivalTime: 06 Nov 2007 14:13:40.0620 (UTC) FILETIME=[3B331CC0:01C8207F] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=1%, Reason='EMC_FROM_0+ -3, NO_REAL_NAME 0, __CP_NOT_1 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: 31247fb3be228bb596db9127becad0bc 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 also agree with Spencer's updated suggestions for GETDEVICEINFO and GETDEVICELIST. Thanks, Jason -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Tuesday, November 06, 2007 8:25 AM To: Spencer Shepler Cc: NFSv4 Subject: Re: [nfsv4] GETDEVICEINFO and GETDEVICELIST in the draft-15 spec Spencer Shepler wrote: > > On Nov 1, 2007, at 2:09 PM, Glasgow_Jason@emc.com wrote: > >> I have two minor issues with the draft-15 spec related to=20 >> GETDEVICEINFO and GETDEVICELIST. The spec does not adequately=20 >> specify the meaning of gdia_maxcount. The sentence describing its=20 >> usage states: >> >> >> >> "The client provides gdia_maxcount to limit the amount of device=20 >> address information to be returned for the mapping. If the mapping=20 >> can not be returned within the maximum specified, NFS4ERR_TOOSMALL is >> returned." >> >> >> >> This sentence does not make clear if gdia_maxount limits the number=20 >> of bytes in the GETDEVICEINFO4res data structure, within the=20 >> "device_addr4" structure, or within the protocol specific opaque data >> "da_addr_body". I propose that the wording be changed to clarify=20 >> that this refers to the number of bytes in the "device_addr4" portion >> of the response. > > I agree that the use of gdia_maxcount is underspecified. > > However, I would prefer the the "maxcount" be interpreted > as it is for the READDIR operation. > > Quoting from that operation description: > "The maxcount value of the argument is the maximum number of bytes for > the result. This maximum size represents all of the data being > returned within the READDIR4resok structure and includes the XDR > overhead. The server may return less data. If the server is unable > to return a single directory entry within the maxcount limit, the > error NFS4ERR_TOOSMALL will be returned to the client." > > Therefore, I would suggest the text for GETDEVICEINFO be: > > "The client provides gdia_maxcount to limit the number of bytes for the > result. This maximum size represents all of the data being returned > within the GETDEVICEINFO4resok structure and includes the XDR > overhead. The server may return less data. If the server is unable > to return the information within the gdia_maxcount limit, the error > NFS4ERR_TOOSMALL will be returned." > > And for GETDEVICELIST: > > "The client provides gdla_maxcount to limit the number of bytes for the > result. This maximum size represents all of the data being returned > within the GETDEVICELIST4resok structure and includes the XDR > overhead. The server may return less data. If the server is unable > to return a single entry device list item within the gdla_maxcount > limit, the error NFS4ERR_TOOSMALL will be returned." > > > The remaining suggestions of adding NFS4ERR_TOOSMALL to the > return union is fine with me. > I agree with Spencer. This was my interpretation too. > > Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 09:44: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 1IpPf3-0000n6-B0; Tue, 06 Nov 2007 09:44:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpPf1-0000kc-0G for nfsv4@ietf.org; Tue, 06 Nov 2007 09:44:11 -0500 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 1IpPex-0005bb-H9 for nfsv4@ietf.org; Tue, 06 Nov 2007 09:44:10 -0500 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 lA6Ei7qA010793; Tue, 6 Nov 2007 09:44:07 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 6 Nov 2007 09:44:07 -0500 Received: from [127.0.0.1] ([172.17.28.131]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 09:44:06 -0500 Message-ID: <47307DB0.5020702@panasas.com> Date: Tue, 06 Nov 2007 16:44:00 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: email2mre-ietf@yahoo.com Subject: Re: [nfsv4] Device stateids (v3) References: <767629.13341.qm@web38104.mail.mud.yahoo.com> In-Reply-To: <767629.13341.qm@web38104.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2007 14:44:06.0949 (UTC) FILETIME=[7BC6CD50:01C82083] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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 Mike Eisler wrote: > --- Benny Halevy wrote: > > >> Mike Eisler wrote: >> >>> --- Benny Halevy wrote: >>> >>> >>> >>> >>>> for a client that supports pNFS and issued one of the pNFS >>>> operations: >>>> CB_DEVICENOTIFY, >>>> CB_LAYOUTRECALL (if issued LAYOUTGET) >>>> >>>> >>> Why can't CB_NOTIFY be used in instead of CB_DEVICENOTIFY? >>> >>> >>> >> Well, it can, but I think overloading a callback meant for directory >> > > And in draft-15, it does. > > This change was made in draft-15 based on a perceived rough > consensus reach months ago. I've read reports of complaints > during last months bake-a-thon, but those complaints were never > aired on the WG list or in an official WG meeting. > I'm not sure that the perception of rough consensus was common to everybody. That's probably an indication that we all need to communicate our thoughts and intentions more clearly on the mailing list. > There isn't great deal of time left to make edits and we've got > substantive changes to make. Unfortunately, adding a new op > is something that we don't always get right the first time. > I apologize for not raising this concern earlier. It's not a big deal so if you feel more comfortable with doing both in CB_NOTIFY then it can be done. > >> notifications >> doesn't make the the client's life any easier. The fact that device >> mapping resemble >> directory delegations by the fact that entries can be added, changed, >> or >> deleted >> from the state is insufficient IMO since the actual notification >> contents >> are totally different. >> > > Which is analogous to saying that because ACLs are totally different > from file size, two separate operations should be used for retrieving > ACLs and file sizes. But instead we have a bitmask for GETATTR to > allow clients to selectively get attributes they are interested in. > Similarly CB_NOTIFY uses a bitmap to selectively push events. > > [This can be developed further on a separate thread :) but actually I think that the file size should indeed be handled differently as setting it is a data modifying operation...] Speaking of the bitmap in CB_NOTIFY wouldn't it be simpler if instead of having a list of struct notify4, each having a bitmap and an opaque array we'll have a list of discriminated unions (especially as the draft says "The notify_type4 can only have one bit set for each notification in the array") for example: enum notify_type4 { NOTIFY4_CHANGE_CHILD_ATTRS = 0, NOTIFY4_CHANGE_DIR_ATTRS = 1, NOTIFY4_REMOVE_ENTRY = 2, NOTIFY4_ADD_ENTRY = 3, NOTIFY4_RENAME_ENTRY = 4, NOTIFY4_CHANGE_COOKIE_VERIFIER = 5, NOTIFY4_DEVICE_ID_ADD = 6, NOTIFY4_DEVICE_ID_CHANGE = 7, NOTIFY4_DEVICE_ID_DELETE = 8 }; union notify4 switch (notify_type4 notify_type) { case NOTIFY4_CHANGE_CHILD_ATTRS: notify_attr4 notify_child_attr; case NOTIFY4_CHANGE_DIR_ATTRS: notify_attr4 notify_dir_attr; /* or just fattr4 for holding the new attrs as ne_file isn't needed in this case? */ case NOTIFY4_REMOVE_ENTRY: notify_remove4 notify_remove; case NOTIFY4_ADD_ENTRY: notify_add4 notify_add; case NOTIFY4_RENAME_ENTRY: notify_rename4 notify_rename; case NOTIFY4_CHANGE_COOKIE_VERIFIER: notify_verifier4 notify_verifier; case NOTIFY4_DEVICE_ID_ADD: case NOTIFY4_DEVICE_ID_CHANGE: case NOTIFY4_DEVICE_ID_DELETE: notify_deviceid4 notify_deviceid; } struct CB_NOTIFY4args { stateid4 cna_stateid; nfs_fh4 cna_fh; notify4 cna_changes<>; }; _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From CliffoctaveAvila@brainyquote.com Tue Nov 06 11:01:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQs0-00013M-7q; Tue, 06 Nov 2007 11:01:40 -0500 Received: from pool-72-88-216-60.nwrknj.fios.verizon.net ([72.88.216.60] helo=home8923d7b781.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpQrz-00039o-Tv; Tue, 06 Nov 2007 11:01:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host01674088.brainyquote.com (8.13.1/8.13.1) with SMTP id 2PukBUZV26.628371.2Aj.ptz.9359914642337 for ; Tue, 6 Nov 2007 11:01:18 +0500 Message-ID: <8138a01c8208e$4e8282c0$0201a8c0@home8923d7b781> From: "Hal Blackwell" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_81386_01C8208E.4E8282C0-- From nfsv4-bounces@ietf.org Tue Nov 06 11:09: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 1IpQzo-0000Ym-3C; Tue, 06 Nov 2007 11:09:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQzm-0000Yh-T8 for nfsv4@ietf.org; Tue, 06 Nov 2007 11:09:42 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpQzm-0003La-II for nfsv4@ietf.org; Tue, 06 Nov 2007 11:09:42 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6G9f7l025412 for ; Tue, 6 Nov 2007 16:09:41 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR300701BRGOF00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Tue, 06 Nov 2007 09:09:41 -0700 (MST) Received: from [10.0.1.192] ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR300IUUE7FM6D0@mail-amer.sun.com> for nfsv4@ietf.org; Tue, 06 Nov 2007 09:09:16 -0700 (MST) Date: Tue, 06 Nov 2007 10:09:12 -0600 From: Robert Gordon Subject: Re: [nfsv4] Device stateids (v3) In-reply-to: <472F91B0.9020905@panasas.com> To: NFSv4 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: <472F91B0.9020905@panasas.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Nov 5, 2007, at 3:57 PM, Benny Halevy wrote: > for a MDS supporting pNFS, I'd say that the following operations > must be implemented: > GETDEVICEINFO, (GETDEVICELIST can remain optional) I'm generating a table that lists the mandatory/optional/mandatory not to implement disposition for each operation. I was surprised to see benny claim that GETDEVICELIST is optional; Since no one has objected .. then I'll assume it IS optional. -- Robert... "Don't Make Assumptions" _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 11:17: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 1IpR7T-0000eA-En; Tue, 06 Nov 2007 11:17:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpR7R-0000d9-TB for nfsv4@ietf.org; Tue, 06 Nov 2007 11:17:37 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpR7N-0008En-MT for nfsv4@ietf.org; Tue, 06 Nov 2007 11:17:37 -0500 X-IronPort-AV: E=Sophos;i="4.21,378,1188802800"; d="scan'208";a="120011993" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 06 Nov 2007 08:17:32 -0800 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 lA6GHVFH007589; Tue, 6 Nov 2007 08:17:31 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 08:17:31 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 08:17:31 -0800 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 (v3) Date: Tue, 6 Nov 2007 11:17:29 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Device stateids (v3) Thread-Index: Acggj8acRWxQVo3QThOd0RATOSMrbwAAIAyA From: "Noveck, Dave" To: "Robert Gordon" , "NFSv4" X-OriginalArrivalTime: 06 Nov 2007 16:17:31.0520 (UTC) FILETIME=[885C7800:01C82090] X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 pnfs is an optional feature so all the ops associated with have to be optional. Maybe for things like this that are mandatory if you implement a particular feature but the feature is optional, the=20 table should give the name of the particular feature, rather than simply saying "optional". -----Original Message----- From: Robert Gordon [mailto:Robert.Gordon@Sun.COM]=20 Sent: Tuesday, November 06, 2007 11:09 AM To: NFSv4 Subject: Re: [nfsv4] Device stateids (v3) On Nov 5, 2007, at 3:57 PM, Benny Halevy wrote: > for a MDS supporting pNFS, I'd say that the following operations =20 > must be implemented: > GETDEVICEINFO, (GETDEVICELIST can remain optional) I'm generating a table that lists the mandatory/optional/mandatory =20 not to implement disposition for each operation. I was surprised to see benny claim that GETDEVICELIST is optional; =20 Since no one has objected .. then I'll assume it IS optional. -- Robert... "Don't Make Assumptions" _______________________________________________ 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 Nov 06 11:26:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpRG7-00012m-Hu; Tue, 06 Nov 2007 11:26:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpRG5-00012c-SN for nfsv4@ietf.org; Tue, 06 Nov 2007 11:26:33 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpRG5-0003kE-4f for nfsv4@ietf.org; Tue, 06 Nov 2007 11:26:33 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6GQW9v008068 for ; Tue, 6 Nov 2007 16:26:32 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR300701DWEGO00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Tue, 06 Nov 2007 09:26:32 -0700 (MST) Received: from [10.0.1.192] ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR3009PVEZLZF70@mail-amer.sun.com>; Tue, 06 Nov 2007 09:26:09 -0700 (MST) Date: Tue, 06 Nov 2007 10:26:06 -0600 From: Robert Gordon Subject: Re: [nfsv4] Device stateids (v3) In-reply-to: To: "Noveck, Dave" Message-id: <72A4A73C-433A-4834-B54A-EFD669101AA8@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 References: X-Spam-Score: -1.0 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Nov 6, 2007, at 10:17 AM, Noveck, Dave wrote: > pnfs is an optional feature so all the ops associated with have to > be optional. Maybe for things like this that are mandatory if you > implement a particular feature but the feature is optional, the > table should give the name of the particular feature, rather than > simply saying "optional". I agree, the table will reflect this. I think that benny was saying that if you implement the optional feature pnfs, the GETDEVICELIST operation would be optional to implement. -- Robert... "Don't Make Assumptions" _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 12:06: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 1IpRsf-00006n-Dm; Tue, 06 Nov 2007 12:06:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpRse-0008Vt-8d for nfsv4@ietf.org; Tue, 06 Nov 2007 12:06:24 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpRsd-000523-MI for nfsv4@ietf.org; Tue, 06 Nov 2007 12:06:24 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id lA6H6J4E006124 for ; Tue, 6 Nov 2007 12:06:19 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id lA6H6JCx459802 for ; Tue, 6 Nov 2007 12:06:19 -0500 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 lA6H6IEW001514 for ; Tue, 6 Nov 2007 12:06:18 -0500 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 lA6H6IfZ001505; Tue, 6 Nov 2007 12:06:18 -0500 In-Reply-To: To: Robert Gordon MIME-Version: 1.0 Subject: Re: [nfsv4] Device stateids (v3) X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Marc Eshel Date: Tue, 6 Nov 2007 09:06:17 -0800 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 8.0|August 02, 2007) at 11/06/2007 12:06:18, Serialize complete at 11/06/2007 12:06:18 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 It is not enough to say that GETDEVICELIST can return an empty list an any server that don't want to implement it just return an empty list? Marc. Robert Gordon wrote on 11/06/2007 08:09:12 AM: > On Nov 5, 2007, at 3:57 PM, Benny Halevy wrote: > > > for a MDS supporting pNFS, I'd say that the following operations > > must be implemented: > > GETDEVICEINFO, (GETDEVICELIST can remain optional) > > > I'm generating a table that lists the mandatory/optional/mandatory > not to implement > disposition for each operation. > > I was surprised to see benny claim that GETDEVICELIST is optional; > Since no > one has objected .. then I'll assume it IS optional. > > -- > Robert... > "Don't Make Assumptions" > > > > _______________________________________________ > 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 Nov 06 12:41: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 1IpSQi-0005jU-20; Tue, 06 Nov 2007 12:41:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSQh-0005jP-4n for nfsv4@ietf.org; Tue, 06 Nov 2007 12:41:35 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpSQd-0002Ad-OE for nfsv4@ietf.org; Tue, 06 Nov 2007 12:41:35 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6HfVUD001836 for ; Tue, 6 Nov 2007 17:41:31 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR300G01HYXBX00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 06 Nov 2007 10:41:31 -0700 (MST) Received: from [192.168.0.4] (adsl-71-145-130-143.dsl.austtx.sbcglobal.net [71.145.130.143]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR300AL0IGWQDA0@mail-amer.sun.com>; Tue, 06 Nov 2007 10:41:21 -0700 (MST) Date: Tue, 06 Nov 2007 11:41:48 -0600 From: Spencer Shepler Subject: Re: [nfsv4] GETDEVICEINFO and GETDEVICELIST in the draft-15 spec In-reply-to: <39CF2A4B63947142A66EAA65B2FDF2F005C37F72@CORPUSMX40A.corp.emc.com> To: Glasgow_Jason@emc.com Message-id: <9C3416A2-E92B-465F-A6C3-6408E3734E7D@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: <39CF2A4B63947142A66EAA65B2FDF2F005BDD2D6@CORPUSMX40A.corp.emc.com> <0C695516-F373-44C4-B3DC-BEEC2AD3A959@sun.com> <47306B3A.2090908@panasas.com> <39CF2A4B63947142A66EAA65B2FDF2F005C37F72@CORPUSMX40A.corp.emc.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 Thanks. The updates have been made. Spencer On Nov 6, 2007, at 8:13 AM, Glasgow_Jason@emc.com wrote: > I also agree with Spencer's updated suggestions for GETDEVICEINFO and > GETDEVICELIST. > Thanks, Jason > > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com] > Sent: Tuesday, November 06, 2007 8:25 AM > To: Spencer Shepler > Cc: NFSv4 > Subject: Re: [nfsv4] GETDEVICEINFO and GETDEVICELIST in the draft-15 > spec > > Spencer Shepler wrote: >> >> On Nov 1, 2007, at 2:09 PM, Glasgow_Jason@emc.com wrote: >> >>> I have two minor issues with the draft-15 spec related to >>> GETDEVICEINFO and GETDEVICELIST. The spec does not adequately >>> specify the meaning of gdia_maxcount. The sentence describing its >>> usage states: >>> >>> >>> >>> "The client provides gdia_maxcount to limit the amount of device >>> address information to be returned for the mapping. If the mapping >>> can not be returned within the maximum specified, >>> NFS4ERR_TOOSMALL is > >>> returned." >>> >>> >>> >>> This sentence does not make clear if gdia_maxount limits the number >>> of bytes in the GETDEVICEINFO4res data structure, within the >>> "device_addr4" structure, or within the protocol specific opaque >>> data > >>> "da_addr_body". I propose that the wording be changed to clarify >>> that this refers to the number of bytes in the "device_addr4" >>> portion > >>> of the response. >> >> I agree that the use of gdia_maxcount is underspecified. >> >> However, I would prefer the the "maxcount" be interpreted >> as it is for the READDIR operation. >> >> Quoting from that operation description: >> "The maxcount value of the argument is the maximum number of bytes > for >> the result. This maximum size represents all of the data being >> returned within the READDIR4resok structure and includes the XDR >> overhead. The server may return less data. If the server is > unable >> to return a single directory entry within the maxcount limit, the >> error NFS4ERR_TOOSMALL will be returned to the client." >> >> Therefore, I would suggest the text for GETDEVICEINFO be: >> >> "The client provides gdia_maxcount to limit the number of bytes for > the >> result. This maximum size represents all of the data being returned >> within the GETDEVICEINFO4resok structure and includes the XDR >> overhead. The server may return less data. If the server is unable >> to return the information within the gdia_maxcount limit, the error >> NFS4ERR_TOOSMALL will be returned." >> >> And for GETDEVICELIST: >> >> "The client provides gdla_maxcount to limit the number of bytes for > the >> result. This maximum size represents all of the data being returned >> within the GETDEVICELIST4resok structure and includes the XDR >> overhead. The server may return less data. If the server is unable >> to return a single entry device list item within the gdla_maxcount >> limit, the error NFS4ERR_TOOSMALL will be returned." >> >> >> The remaining suggestions of adding NFS4ERR_TOOSMALL to the >> return union is fine with me. >> > I agree with Spencer. This was my interpretation too. >> >> 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 Nov 06 12:50: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 1IpSZS-000486-2L; Tue, 06 Nov 2007 12:50:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSZQ-00047o-QC for nfsv4@ietf.org; Tue, 06 Nov 2007 12:50:36 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpSZM-0002MA-6c for nfsv4@ietf.org; Tue, 06 Nov 2007 12:50:36 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6HoVHO007058 for ; Tue, 6 Nov 2007 17:50:31 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR300E01IGGA200@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 06 Nov 2007 10:50:31 -0700 (MST) Received: from [192.168.0.4] (adsl-71-145-130-143.dsl.austtx.sbcglobal.net [71.145.130.143]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR300ARCIW7QDA0@mail-amer.sun.com> for nfsv4@ietf.org; Tue, 06 Nov 2007 10:50:31 -0700 (MST) Date: Tue, 06 Nov 2007 11:50:58 -0600 From: Spencer Shepler Subject: pNFS mandatory operations (was Re: [nfsv4] Device stateids (v3)) In-reply-to: To: NFSv4 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: -1.0 (-) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 Nov 6, 2007, at 10:17 AM, Noveck, Dave wrote: > pnfs is an optional feature so all the ops associated with have to > be optional. Maybe for things like this that are mandatory if you > implement a particular feature but the feature is optional, the > table should give the name of the particular feature, rather than > simply saying "optional". Yes, it should. LAYOUTGET wouldn't be very helpful unless LAYOUTRETURN were also implemented. Without further justification to the contrary, I believe that GETDEVICELIST should be mandatory to implement if the pNFS feature is supported. Spencer > > -----Original Message----- > From: Robert Gordon [mailto:Robert.Gordon@Sun.COM] > Sent: Tuesday, November 06, 2007 11:09 AM > To: NFSv4 > Subject: Re: [nfsv4] Device stateids (v3) > > > On Nov 5, 2007, at 3:57 PM, Benny Halevy wrote: > >> for a MDS supporting pNFS, I'd say that the following operations >> must be implemented: >> GETDEVICEINFO, (GETDEVICELIST can remain optional) > > > I'm generating a table that lists the mandatory/optional/mandatory > not to implement > disposition for each operation. > > I was surprised to see benny claim that GETDEVICELIST is optional; > Since no > one has objected .. then I'll assume it IS optional. > > -- > Robert... > "Don't Make Assumptions" > > > > _______________________________________________ > 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 Nov 06 12:52: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 1IpSap-0005Zb-UK; Tue, 06 Nov 2007 12:52:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSao-0005VV-44 for nfsv4@ietf.org; Tue, 06 Nov 2007 12:52:02 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpSan-00067S-LZ for nfsv4@ietf.org; Tue, 06 Nov 2007 12:52:02 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6Hq02P025264 for ; Tue, 6 Nov 2007 17:52:00 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR300G01IGSM000@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 06 Nov 2007 10:52:00 -0700 (MST) Received: from [192.168.0.4] (adsl-71-145-130-143.dsl.austtx.sbcglobal.net [71.145.130.143]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR300BIUIY80M90@mail-amer.sun.com>; Tue, 06 Nov 2007 10:51:45 -0700 (MST) Date: Tue, 06 Nov 2007 11:52:11 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Device stateids (v3) 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: 0ddefe323dd869ab027dbfff7eff0465 Cc: Robert Gordon , 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 Nov 6, 2007, at 11:06 AM, Marc Eshel wrote: > It is not enough to say that GETDEVICELIST can return an empty list > an any > server that don't want to implement it just return an empty list? No. If the server is returning an empty list than that means something very different than the operation is not supported. It is misleading to the client even if the words in the specification were to say something to the contrary Spencer > Marc. > > Robert Gordon wrote on 11/06/2007 08:09:12 AM: > >> On Nov 5, 2007, at 3:57 PM, Benny Halevy wrote: >> >>> for a MDS supporting pNFS, I'd say that the following operations >>> must be implemented: >>> GETDEVICEINFO, (GETDEVICELIST can remain optional) >> >> >> I'm generating a table that lists the mandatory/optional/mandatory >> not to implement >> disposition for each operation. >> >> I was surprised to see benny claim that GETDEVICELIST is optional; >> Since no >> one has objected .. then I'll assume it IS optional. >> >> -- >> Robert... >> "Don't Make Assumptions" >> >> >> >> _______________________________________________ >> 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 Nov 06 12:58: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 1IpSh5-0002LX-QT; Tue, 06 Nov 2007 12:58:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSh4-0002Ja-CB for nfsv4@ietf.org; Tue, 06 Nov 2007 12:58:30 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpSh0-0002de-Oh for nfsv4@ietf.org; Tue, 06 Nov 2007 12:58:30 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id lA6HwQaT032543 for ; Tue, 6 Nov 2007 12:58:26 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id lA6HwQJg474878 for ; Tue, 6 Nov 2007 12:58:26 -0500 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 lA6HwQxG019554 for ; Tue, 6 Nov 2007 12:58:26 -0500 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 lA6HwQTu019550; Tue, 6 Nov 2007 12:58:26 -0500 In-Reply-To: To: Spencer Shepler MIME-Version: 1.0 Subject: Re: [nfsv4] Device stateids (v3) X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Marc Eshel Date: Tue, 6 Nov 2007 09:58:23 -0800 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 8.0|August 02, 2007) at 11/06/2007 12:58:25, Serialize complete at 11/06/2007 12:58:25 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: -4.0 (----) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Robert Gordon , NFSv4 , Spencer.Shepler@Sun.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 Spencer.Shepler@Sun.COM wrote on 11/06/2007 09:52:11 AM: > > On Nov 6, 2007, at 11:06 AM, Marc Eshel wrote: > > > It is not enough to say that GETDEVICELIST can return an empty list > > an any > > server that don't want to implement it just return an empty list? > > No. If the server is returning an empty list than that means > something very different than the operation is not supported. > It is misleading to the client even if the words in the specification > were to say something to the contrary How does it help the client to get not supported vs. empty list ? what can the client do differently based on the 2 different responses ? Marc. > > Spencer > > > Marc. > > > > Robert Gordon wrote on 11/06/2007 08:09:12 AM: > > > >> On Nov 5, 2007, at 3:57 PM, Benny Halevy wrote: > >> > >>> for a MDS supporting pNFS, I'd say that the following operations > >>> must be implemented: > >>> GETDEVICEINFO, (GETDEVICELIST can remain optional) > >> > >> > >> I'm generating a table that lists the mandatory/optional/mandatory > >> not to implement > >> disposition for each operation. > >> > >> I was surprised to see benny claim that GETDEVICELIST is optional; > >> Since no > >> one has objected .. then I'll assume it IS optional. > >> > >> -- > >> Robert... > >> "Don't Make Assumptions" > >> > >> > >> > >> _______________________________________________ > >> 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 Nov 06 13:06: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 1IpSod-0002Vl-Ht; Tue, 06 Nov 2007 13:06:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSoc-0002Pb-87 for nfsv4@ietf.org; Tue, 06 Nov 2007 13:06:18 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpSob-0006eg-Pi for nfsv4@ietf.org; Tue, 06 Nov 2007 13:06:18 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6I6G63004574 for ; Tue, 6 Nov 2007 18:06:17 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR300H01J1AGD00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 06 Nov 2007 11:06:16 -0700 (MST) Received: from [192.168.0.4] (adsl-71-145-130-143.dsl.austtx.sbcglobal.net [71.145.130.143]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR300A56JLTQDB0@mail-amer.sun.com>; Tue, 06 Nov 2007 11:05:54 -0700 (MST) Date: Tue, 06 Nov 2007 12:06:20 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Device stateids (v3) In-reply-to: To: Marc Eshel Message-id: <4F3C7F85-F09B-4EA1-8367-70A652355B5F@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: b4a0a5f5992e2a4954405484e7717d8c Cc: Robert Gordon , 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 Nov 6, 2007, at 11:58 AM, Marc Eshel wrote: > Spencer.Shepler@Sun.COM wrote on 11/06/2007 09:52:11 AM: > >> >> On Nov 6, 2007, at 11:06 AM, Marc Eshel wrote: >> >>> It is not enough to say that GETDEVICELIST can return an empty list >>> an any >>> server that don't want to implement it just return an empty list? >> >> No. If the server is returning an empty list than that means >> something very different than the operation is not supported. >> It is misleading to the client even if the words in the specification >> were to say something to the contrary > > How does it help the client to get not supported vs. empty list ? > what can > the client do differently based on the 2 different responses ? an operation level error of ENOTSUPP is very clear where an empty list may actually be a valid response where the server may support the GETDEVICELIST operation but just not have any deviceids available at that point in time. Spencer >>> Robert Gordon wrote on 11/06/2007 >>> 08:09:12 AM: >>> >>>> On Nov 5, 2007, at 3:57 PM, Benny Halevy wrote: >>>> >>>>> for a MDS supporting pNFS, I'd say that the following operations >>>>> must be implemented: >>>>> GETDEVICEINFO, (GETDEVICELIST can remain optional) >>>> >>>> >>>> I'm generating a table that lists the mandatory/optional/mandatory >>>> not to implement >>>> disposition for each operation. >>>> >>>> I was surprised to see benny claim that GETDEVICELIST is optional; >>>> Since no >>>> one has objected .. then I'll assume it IS optional. >>>> >>>> -- >>>> Robert... >>>> "Don't Make Assumptions" >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Nov 06 13:08: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 1IpSqZ-0007AL-Jf; Tue, 06 Nov 2007 13:08:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSqX-00073G-WC for nfsv4@ietf.org; Tue, 06 Nov 2007 13:08:18 -0500 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 1IpSqU-0002yB-Jb for nfsv4@ietf.org; Tue, 06 Nov 2007 13:08:17 -0500 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 lA6I8DRa015823; Tue, 6 Nov 2007 13:08:13 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 6 Nov 2007 13:08:13 -0500 Received: from fs1.bhalevy.com ([172.17.28.131]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 13:08:13 -0500 Message-ID: <4730AD8A.2010703@panasas.com> Date: Tue, 06 Nov 2007 20:08:10 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Robert Gordon Subject: Re: [nfsv4] Device stateids (v3) References: <72A4A73C-433A-4834-B54A-EFD669101AA8@Sun.COM> In-Reply-To: <72A4A73C-433A-4834-B54A-EFD669101AA8@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2007 18:08:13.0919 (UTC) FILETIME=[FF8A1EF0:01C8209F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "Noveck, Dave" , 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 Nov. 06, 2007, 18:26 +0200, Robert Gordon wrote: > On Nov 6, 2007, at 10:17 AM, Noveck, Dave wrote: > >> pnfs is an optional feature so all the ops associated with have to >> be optional. Maybe for things like this that are mandatory if you >> implement a particular feature but the feature is optional, the >> table should give the name of the particular feature, rather than >> simply saying "optional". > > I agree, the table will reflect this. > > I think that benny was saying that if you implement the > optional feature pnfs, the GETDEVICELIST operation would > be optional to implement. Correct. It is an optimization. pNFS should work flawlessly just by using GETDEVICEINFO on-demand whenever the client needs to resolve a device ID that it hasn't seen before or that fell out of its cache. Benny > > -- > Robert... > "Don't Make Assumptions" _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 13:16: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 1IpSyl-0007Jn-S8; Tue, 06 Nov 2007 13:16:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSyk-0007HF-Ar for nfsv4@ietf.org; Tue, 06 Nov 2007 13:16:46 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpSyf-0003CD-N5 for nfsv4@ietf.org; Tue, 06 Nov 2007 13:16:46 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6IGfqQ022512 for ; Tue, 6 Nov 2007 18:16:41 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR300001HIC3A00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 06 Nov 2007 11:16:41 -0700 (MST) Received: from [192.168.0.4] (adsl-71-145-130-143.dsl.austtx.sbcglobal.net [71.145.130.143]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR300B2BK380MA0@mail-amer.sun.com>; Tue, 06 Nov 2007 11:16:21 -0700 (MST) Date: Tue, 06 Nov 2007 12:16:48 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Directory Delegation Push - Not Needed In-reply-to: <746006.10804.qm@web38113.mail.mud.yahoo.com> To: email2mre-ietf@yahoo.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: <746006.10804.qm@web38113.mail.mud.yahoo.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 Nov 6, 2007, at 4:59 AM, Mike Eisler wrote: > To come back to issue Dave describes below, > I think we do not have support the pushing or > notification of directory delegations. So in other > words, nothing more to do. Yes, I agree with the analysis. Spencer > > My reasoning is that because we have no way to establish an "open" > reference on a directory, and because we have to way to open a > directory for writing, a directory delegation isn't going to be > denied due to contention with a writer, then we don't need to push > a delegation (or extend CB_NOTIFY to notify the client that the > contention is no longer present). While it is true a lazy server > could refuse a directory delegation if the directory is currently > have a modification (e.g. file create) performed on it, we should > not complicate the protocol to support lazy servers. The non-lazy > server would just queue the delegation request after all the > modification requests. The half-way lazy server would just return > NFS4ERR_DELAY (Need to check if NFS4ERR_DELAY is among the list of > errors GET_DIR_DELEGATION can return). > > > --- "Noveck, Dave" wrote: > > >> I recall that we had a discussion about whether CB_PUSH_DELEG could >> in >> fact >> propagate a delegation requested by GET_DIR_DELEGATION, as opposed to >> delegation >> for non-directory types of objects. I guess there was also >> implicitly a >> question >> about whether it should be able to do so. >> >> So on the first point, the answer seems to be "No" since >> CB_PUSH_DELEGargs >> contains an open_delegation4, which doesn't have a provision for a >> lot >> of the >> data returned in a GET_DIR_DELEGATION4resok. Since this information >> is >> not >> provided on the response to the GET_DIR_DELEGATION or in the >> CB_PUSH_DELEG, >> it doesn't seem that there is a current provision for CB_PUSH_DELEG >> to >> deliver a directory delegation. >> >> In fact, there is no provision currently for GET_DIR_DELEGATION to >> promise >> to deliver a directory delegation when the delgation is available >> (i.e. >> there >> is no conflict on that specific object), which would call for >> CB_PUSH_DELEG >> or something like it. The only provision in which it promises to >> signal >> you >> is when there is resources unavailable, i.e. something will be >> resolved >> by >> CB_RECALLABLE_OBJ_AVAIL. >> >> I'm supposing that this structure derives from the fact that there >> are >> no >> write directory delegations and it is thus impossible for there to be >> a >> hard conflict that would not allow a directory delegation to be >> granted. >> I'm not sure if this logic is valid since it is possible for a server >> not >> to grant a directory delegation because frequent directory changes >> makes >> this not an efficient way to go. And if that could cause a >> delegation >> to be denied, the situation might be changed when those changes stop. >> >> Anyway, what I am going to do now is to change CB_PUSH_DELEG so it >> doens't >> reference GET_DIR_DELEGATION and if we want to extend >> GET_DIR_DELEGATION >> >> and CB_PUSH_DELEG to support this, we can handle that separately from >> the >> review of the locking chapters. > > > _______________________________________________ > 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 Nov 06 13:19: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 1IpT10-00015T-B2; Tue, 06 Nov 2007 13:19:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpT0z-00015I-7j for nfsv4@ietf.org; Tue, 06 Nov 2007 13:19:05 -0500 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 1IpT0y-0006zh-SI for nfsv4@ietf.org; Tue, 06 Nov 2007 13:19:05 -0500 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 lA6IA4Hm015878; Tue, 6 Nov 2007 13:10:04 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 6 Nov 2007 13:10:04 -0500 Received: from fs1.bhalevy.com ([172.17.28.131]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 13:10:04 -0500 Message-ID: <4730ADF8.9000802@panasas.com> Date: Tue, 06 Nov 2007 20:10:00 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Spencer Shepler , Marc Eshel Subject: Re: [nfsv4] Device stateids (v3) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2007 18:10:04.0453 (UTC) FILETIME=[416C4550:01C820A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Robert Gordon , 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 Nov. 06, 2007, 19:52 +0200, Spencer Shepler wrote: > On Nov 6, 2007, at 11:06 AM, Marc Eshel wrote: > >> It is not enough to say that GETDEVICELIST can return an empty list >> an any >> server that don't want to implement it just return an empty list? > > No. If the server is returning an empty list than that means > something very different than the operation is not supported. > It is misleading to the client even if the words in the specification > were to say something to the contrary Agreed. Benny > > Spencer > >> Marc. >> >> Robert Gordon wrote on 11/06/2007 08:09:12 AM: >> >>> On Nov 5, 2007, at 3:57 PM, Benny Halevy wrote: >>> >>>> for a MDS supporting pNFS, I'd say that the following operations >>>> must be implemented: >>>> GETDEVICEINFO, (GETDEVICELIST can remain optional) >>> >>> I'm generating a table that lists the mandatory/optional/mandatory >>> not to implement >>> disposition for each operation. >>> >>> I was surprised to see benny claim that GETDEVICELIST is optional; >>> Since no >>> one has objected .. then I'll assume it IS optional. >>> >>> -- >>> Robert... >>> "Don't Make Assumptions" >>> >>> >>> >>> _______________________________________________ >>> 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 Tue Nov 06 13:36: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 1IpTHx-0003ZH-Fm; Tue, 06 Nov 2007 13:36:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTHw-0003Yn-8c for nfsv4@ietf.org; Tue, 06 Nov 2007 13:36:36 -0500 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 1IpTHv-0007Ta-KX for nfsv4@ietf.org; Tue, 06 Nov 2007 13:36:36 -0500 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 lA6IaW7W016537; Tue, 6 Nov 2007 13:36:32 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 6 Nov 2007 13:36:32 -0500 Received: from fs1.bhalevy.com ([172.17.28.131]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 13:36:32 -0500 Message-ID: <4730B42D.30602@panasas.com> Date: Tue, 06 Nov 2007 20:36:29 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: pNFS mandatory operations (was Re: [nfsv4] Device stateids (v3)) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2007 18:36:32.0431 (UTC) FILETIME=[F3EE7BF0:01C820A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Nov. 06, 2007, 19:50 +0200, Spencer Shepler wrote: > On Nov 6, 2007, at 10:17 AM, Noveck, Dave wrote: > >> pnfs is an optional feature so all the ops associated with have to >> be optional. Maybe for things like this that are mandatory if you >> implement a particular feature but the feature is optional, the >> table should give the name of the particular feature, rather than >> simply saying "optional". > > Yes, it should. LAYOUTGET wouldn't be very helpful unless > LAYOUTRETURN were also implemented. > > Without further justification to the contrary, I believe that > GETDEVICELIST should be mandatory to implement if the pNFS feature is > supported. why? Our server has no idea of a device list at the moment but it knows to get the device info for each device Id it returns in a layout. This must be sufficient for the client. Benny > > Spencer > > > >> -----Original Message----- >> From: Robert Gordon [mailto:Robert.Gordon@Sun.COM] >> Sent: Tuesday, November 06, 2007 11:09 AM >> To: NFSv4 >> Subject: Re: [nfsv4] Device stateids (v3) >> >> >> On Nov 5, 2007, at 3:57 PM, Benny Halevy wrote: >> >>> for a MDS supporting pNFS, I'd say that the following operations >>> must be implemented: >>> GETDEVICEINFO, (GETDEVICELIST can remain optional) >> >> I'm generating a table that lists the mandatory/optional/mandatory >> not to implement >> disposition for each operation. >> >> I was surprised to see benny claim that GETDEVICELIST is optional; >> Since no >> one has objected .. then I'll assume it IS optional. >> >> -- >> Robert... >> "Don't Make Assumptions" >> >> >> >> _______________________________________________ >> 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 Tue Nov 06 13:50: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 1IpTVo-0007EC-5r; Tue, 06 Nov 2007 13:50:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpTVm-0007DL-Tt for nfsv4@ietf.org; Tue, 06 Nov 2007 13:50:54 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpTVi-000474-M1 for nfsv4@ietf.org; Tue, 06 Nov 2007 13:50:54 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6Ioo48012250 for ; Tue, 6 Nov 2007 18:50:50 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR300A01KG00P00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 06 Nov 2007 11:50:50 -0700 (MST) Received: from [192.168.0.4] (adsl-71-145-130-143.dsl.austtx.sbcglobal.net [71.145.130.143]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR300BVDLOJ0MA0@mail-amer.sun.com> for nfsv4@ietf.org; Tue, 06 Nov 2007 11:50:44 -0700 (MST) Date: Tue, 06 Nov 2007 12:51:10 -0600 From: Spencer Shepler Subject: Re: pNFS mandatory operations (was Re: [nfsv4] Device stateids (v3)) In-reply-to: <4730B42D.30602@panasas.com> To: NFSv4 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: <4730B42D.30602@panasas.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Nov 6, 2007, at 12:36 PM, Benny Halevy wrote: > On Nov. 06, 2007, 19:50 +0200, Spencer Shepler > wrote: >> On Nov 6, 2007, at 10:17 AM, Noveck, Dave wrote: >> >>> pnfs is an optional feature so all the ops associated with have to >>> be optional. Maybe for things like this that are mandatory if you >>> implement a particular feature but the feature is optional, the >>> table should give the name of the particular feature, rather than >>> simply saying "optional". >> >> Yes, it should. LAYOUTGET wouldn't be very helpful unless >> LAYOUTRETURN were also implemented. >> >> Without further justification to the contrary, I believe that >> GETDEVICELIST should be mandatory to implement if the pNFS feature is >> supported. > > why? > Our server has no idea of a device list at the moment but it knows > to get the device info for each device Id it returns in a layout. > This must be sufficient for the client. You have provided the justification. Your server will refuse to or is incapable of implementing a mechanism to support device lists. Spencer >>> -----Original Message----- >>> From: Robert Gordon [mailto:Robert.Gordon@Sun.COM] >>> Sent: Tuesday, November 06, 2007 11:09 AM >>> To: NFSv4 >>> Subject: Re: [nfsv4] Device stateids (v3) >>> >>> >>> On Nov 5, 2007, at 3:57 PM, Benny Halevy wrote: >>> >>>> for a MDS supporting pNFS, I'd say that the following operations >>>> must be implemented: >>>> GETDEVICEINFO, (GETDEVICELIST can remain optional) >>> >>> I'm generating a table that lists the mandatory/optional/mandatory >>> not to implement >>> disposition for each operation. >>> >>> I was surprised to see benny claim that GETDEVICELIST is optional; >>> Since no >>> one has objected .. then I'll assume it IS optional. >>> >>> -- >>> Robert... >>> "Don't Make Assumptions" >>> >>> >>> >>> _______________________________________________ >>> 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 Tue Nov 06 15:12: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 1IpUn3-0001u7-4G; Tue, 06 Nov 2007 15:12:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpUn1-0001tt-Hb for nfsv4@ietf.org; Tue, 06 Nov 2007 15:12:47 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpUmy-0006Ix-8f for nfsv4@ietf.org; Tue, 06 Nov 2007 15:12:47 -0500 X-IronPort-AV: E=Sophos;i="4.21,380,1188802800"; d="scan'208";a="120086604" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 06 Nov 2007 12:12:28 -0800 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 lA6KCS8C029128; Tue, 6 Nov 2007 12:12:28 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 12:12:28 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 12:12:27 -0800 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] Proposed resolutions for some pnfs-related [[Comment]] sections Date: Tue, 6 Nov 2007 15:12:26 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections Thread-Index: AcgfEDS5dpjs0w9FReWR/47l6Y0a5wBn/wOA From: "Noveck, Dave" To: "Robert Gordon" , "Benny Halevy" X-OriginalArrivalTime: 06 Nov 2007 20:12:27.0835 (UTC) FILETIME=[5A6B70B0:01C820B1] X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 think that Dave is going to update that text.. or in the process of.. I've made some updates but I want to make sure we have consensus here and=20 so I can make whatver additional changes are required and close this out. > I think using zero in the stateid sequence field is okay. OK, but I'm saying that for the DS non-zero stateid sequence field=20 should be not OK. All of the reasons for allowing this on the MDS have to do with parallel opens/closes and needing ways to prevent the effects of races. It is=20 allowed on other ops that take a stateid for reasons of symmetry. In the case of a DS, it is just simpler to say that seqid field zero is the only allowable case. That would avoid making implementation to work to support somethng that doesn't seem to have any value. > We also need to say that the client should use either the OPEN or > DELEGATION stateid, and may use the lock stateid (with the most recent > sequence id) if mandatory locking is implemented. How does the client know if mandatory locking is implemented? As to the seqid, I don't see the value. Since the DS cannot be sure that you are sending the correct one, it needs to validate it assuming you are not. But if it capable of doing that, then it should be capable of getting the appropriate state to use, without you sending the seqid. -----Original Message----- From: Robert Gordon [mailto:Robert.Gordon@Sun.COM]=20 Sent: Sunday, November 04, 2007 1:26 PM To: Benny Halevy; Noveck, Dave Cc: NFSv4 Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections On Nov 4, 2007, at 1:59 AM, Benny Halevy wrote: >> In addition to the cref section there seems to me to be confusion >> in the other parts of this and adjoining sections. The big issue >> is that there is discussion of getting stateid seqids right but >> that seems to me pointless complexity for the data server. Given >> parallel open the general pattern will be to use seqid=3D0 and only >> use non-zero seqid for a few special operation like OPEN_DOWNGRADE >> and CLOSE, none of which is going to be sent to the data server. >> >> So I'm proposing that the stateids for the data server always have >> seqid as zero and you get BAD_STATEID if not. > > I thought that the client should just use the most recent stateid =20 > returned > to it by the MDS, as per 14.10.1: > "When the client issues I/O to a data server, the stateid used must =20 > be one > previously returned by the metadata server. Permitted stateids =20 > include an > open stateid (the stateid field of data type OPEN4resok as returned =20 > by OPEN), > a delegation stateid (the stateid field of data types =20 > open_read_delegation4 > and open_write_delegation4 as returned by OPEN or WANT_DELEGATION, =20 > or as > sent by CB_PUSH_DELEG), or a stateid returned by the LOCK or LOCKU =20 > operations." I think that Dave is going to update that text.. or in the process of.. I think using zero in the stateid sequence field is okay. We also need to say that the client should use either the OPEN or DELEGATION stateid, and may use the lock stateid (with the most recent sequence id) if mandatory locking is implemented. Robert. =20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 15:45: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 1IpVIB-0004s7-NW; Tue, 06 Nov 2007 15:44:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpVIA-0004s2-Jo for nfsv4@ietf.org; Tue, 06 Nov 2007 15:44:58 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpVI6-0007E7-Td for nfsv4@ietf.org; Tue, 06 Nov 2007 15:44:58 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6Kis5t001843 for ; Tue, 6 Nov 2007 20:44:54 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR300901PDY8000@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Tue, 06 Nov 2007 13:44:54 -0700 (MST) Received: from [10.1.194.250] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR300D92QYFSV30@mail-amer.sun.com>; Tue, 06 Nov 2007 13:44:40 -0700 (MST) Date: Tue, 06 Nov 2007 14:44:36 -0600 From: Robert Gordon Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections In-reply-to: To: "Noveck, Dave" Message-id: <2A0C4E29-9858-4D3E-82D9-ED59F194733F@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: -1.0 (-) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Benny Halevy , 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 Nov 6, 2007, at 2:12 PM, Noveck, Dave wrote: > In the case of a DS, it is just simpler to say that seqid field zero > is the only allowable case. That would avoid making implementation > to work to support somethng that doesn't seem to have any value. I agree; The seqid MUST be zero. If not then the DS will return NFS4ERR_INVAL (?) >> We also need to say that the client should use either the OPEN or >> DELEGATION stateid, and may use the lock stateid (with the most >> recent >> sequence id) if mandatory locking is implemented. > > How does the client know if mandatory locking is implemented? NFS4ERR_LOCKED would have been returned to the client if it had used an open or delegation stateid; > > As to the seqid, I don't see the value. Since the DS cannot be sure > that you are sending the correct one, it needs to validate it assuming > you are not. But if it capable of doing that, then it should be > capable > of getting the appropriate state to use, without you sending the > seqid. You are right; and I agree. I'd forgotten the following :- "14.10.2.1. Lock State Propagation If the pNFS server supports mandatory locking, any mandatory locks on a file MUST be made effective at the data servers before the request that establishes them returns to the caller. Thus, mandatory lock state MUST be synchronously propagated to the data servers." and (for completeness) we also say this in the last paragraph of 13.5.1: "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." -- Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 15:50: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 1IpVNN-000161-FR; Tue, 06 Nov 2007 15:50:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpVNL-00015t-Lm for nfsv4@ietf.org; Tue, 06 Nov 2007 15:50:19 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpVNH-0007MS-TQ for nfsv4@ietf.org; Tue, 06 Nov 2007 15:50:19 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6KoFsW010130 for ; Tue, 6 Nov 2007 20:50:15 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR300401QHDFA00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 06 Nov 2007 13:50:15 -0700 (MST) Received: from [192.168.0.4] ([129.150.32.136]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR300AGJR7DQDE0@mail-amer.sun.com>; Tue, 06 Nov 2007 13:50:02 -0700 (MST) Date: Tue, 06 Nov 2007 14:50:28 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections In-reply-to: To: "Noveck, Dave" Message-id: <473B4E87-F08A-45E3-9DFF-60A12187E8E1@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: -1.0 (-) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Benny Halevy , Robert Gordon , 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 Nov 6, 2007, at 2:12 PM, Noveck, Dave wrote: >> I think that Dave is going to update that text.. or in the process > of.. > > I've made some updates but I want to make sure we have consensus here > and > so I can make whatver additional changes are required and close this > out. > >> I think using zero in the stateid sequence field is okay. > > OK, but I'm saying that for the DS non-zero stateid sequence field > should be not OK. > > All of the reasons for allowing this on the MDS have to do with > parallel > opens/closes and needing ways to prevent the effects of races. It is > allowed on other ops that take a stateid for reasons of symmetry. > > In the case of a DS, it is just simpler to say that seqid field zero > is the only allowable case. That would avoid making implementation > to work to support somethng that doesn't seem to have any value. I agree with this. The stateid sent in requests destined for at data server MUST have the seqid portion == 0. > >> We also need to say that the client should use either the OPEN or >> DELEGATION stateid, and may use the lock stateid (with the most >> recent >> sequence id) if mandatory locking is implemented. > > How does the client know if mandatory locking is implemented? That is the fundamental issue then, right? Without a method of determining if mandatory file locking is being used at the server, the client's behavior can not vary. Either the client is required to use the lock stateid (if file locking is being used by the client) or it isn't required to do so. > As to the seqid, I don't see the value. Since the DS cannot be sure > that you are sending the correct one, it needs to validate it assuming > you are not. But if it capable of doing that, then it should be > capable > of getting the appropriate state to use, without you sending the > seqid. If the pNFS server is providing mandatory file locking then it would presumably have a method of determining the client's access to the file. The seqid is a method of determining at what point in the state transitions the client was "located" when submitting the I/O. So another way to phrase your response to this is that the we, as protocol designers, are not concerned with the timeline of access (did the client submit an I/O and simultaneously submit a LOCK/LOCKU operation that changes its access). Therefore, in the case of mandatory file locking support, the data server is only required to know about changes in the file locking state such that it can confirm the client's access with respect to the current file locks held and not the past state of file locks held. In summary, the seqid of the stateid supplied to the data server is required to be zero regardless of stateid type. We then decide if a lock stateid is required in the event that the server is supporting mandatory file locking. Spencer > > -----Original Message----- > From: Robert Gordon [mailto:Robert.Gordon@Sun.COM] > Sent: Sunday, November 04, 2007 1:26 PM > To: Benny Halevy; Noveck, Dave > Cc: NFSv4 > Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related > [[Comment]] sections > > > > On Nov 4, 2007, at 1:59 AM, Benny Halevy wrote: > >>> In addition to the cref section there seems to me to be confusion >>> in the other parts of this and adjoining sections. The big issue >>> is that there is discussion of getting stateid seqids right but >>> that seems to me pointless complexity for the data server. Given >>> parallel open the general pattern will be to use seqid=0 and only >>> use non-zero seqid for a few special operation like OPEN_DOWNGRADE >>> and CLOSE, none of which is going to be sent to the data server. >>> >>> So I'm proposing that the stateids for the data server always have >>> seqid as zero and you get BAD_STATEID if not. >> >> I thought that the client should just use the most recent stateid >> returned >> to it by the MDS, as per 14.10.1: >> "When the client issues I/O to a data server, the stateid used must >> be one >> previously returned by the metadata server. Permitted stateids >> include an >> open stateid (the stateid field of data type OPEN4resok as returned >> by OPEN), >> a delegation stateid (the stateid field of data types >> open_read_delegation4 >> and open_write_delegation4 as returned by OPEN or WANT_DELEGATION, >> or as >> sent by CB_PUSH_DELEG), or a stateid returned by the LOCK or LOCKU >> operations." > > I think that Dave is going to update that text.. or in the process > of.. > > I think using zero in the stateid sequence field is okay. > > We also need to say that the client should use either the OPEN or > DELEGATION stateid, and may use the lock stateid (with the most recent > sequence id) if mandatory locking is implemented. > > 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 Nov 06 15:54:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpVRh-0004mU-S2; Tue, 06 Nov 2007 15:54:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpVRf-0004lN-Ro for nfsv4@ietf.org; Tue, 06 Nov 2007 15:54:48 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpVRf-00032k-BI for nfsv4@ietf.org; Tue, 06 Nov 2007 15:54:47 -0500 X-IronPort-AV: E=Sophos;i="4.21,380,1188802800"; d="scan'208";a="120098937" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 06 Nov 2007 12:54:01 -0800 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 lA6Ks0KD010710; Tue, 6 Nov 2007 12:54:00 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 12:54:00 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 12:53:59 -0800 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] Proposed resolutions for some pnfs-related [[Comment]] sections Date: Tue, 6 Nov 2007 15:53:58 -0500 Message-ID: In-Reply-To: <2A0C4E29-9858-4D3E-82D9-ED59F194733F@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections Thread-Index: AcggtiN5NKuKY5cxTe+dmlyBPLQPAwAAIX2Q From: "Noveck, Dave" To: "Robert Gordon" X-OriginalArrivalTime: 06 Nov 2007 20:53:59.0861 (UTC) FILETIME=[27C86E50:01C820B7] X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Benny Halevy , 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 agree; The seqid MUST be zero. If not then the DS will return > NFS4ERR_INVAL (?) I was thinking BAD_STATEID since every op that can receive this already has to have BAD_STATEID in its error list. I'm trying to avoid requiring any more changes to the error/op lists, although I hope I won't push that to exteremes. -----Original Message----- From: Robert Gordon [mailto:Robert.Gordon@Sun.COM]=20 Sent: Tuesday, November 06, 2007 3:45 PM To: Noveck, Dave Cc: Benny Halevy; NFSv4 Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections On Nov 6, 2007, at 2:12 PM, Noveck, Dave wrote: > In the case of a DS, it is just simpler to say that seqid field zero > is the only allowable case. That would avoid making implementation > to work to support somethng that doesn't seem to have any value. I agree; The seqid MUST be zero. If not then the DS will return NFS4ERR_INVAL (?) >> We also need to say that the client should use either the OPEN or >> DELEGATION stateid, and may use the lock stateid (with the most =20 >> recent >> sequence id) if mandatory locking is implemented. > > How does the client know if mandatory locking is implemented? NFS4ERR_LOCKED would have been returned to the client if it had used an open or delegation stateid; > > As to the seqid, I don't see the value. Since the DS cannot be sure > that you are sending the correct one, it needs to validate it assuming > you are not. But if it capable of doing that, then it should be =20 > capable > of getting the appropriate state to use, without you sending the =20 > seqid. You are right; and I agree. I'd forgotten the following :- "14.10.2.1. Lock State Propagation If the pNFS server supports mandatory locking, any mandatory locks on a file MUST be made effective at the data servers before the request that establishes them returns to the caller. Thus, mandatory lock state MUST be synchronously propagated to the data servers." and (for completeness) we also say this in the last paragraph of 13.5.1: "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." -- Robert.=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 16:06: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 1IpVck-0005dF-7O; Tue, 06 Nov 2007 16:06:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpVcj-0005cu-7y for nfsv4@ietf.org; Tue, 06 Nov 2007 16:06:13 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpVcf-0007kV-UA for nfsv4@ietf.org; Tue, 06 Nov 2007 16:06:13 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6L691o011664 for ; Tue, 6 Nov 2007 21:06:09 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR300801PDVDB00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Tue, 06 Nov 2007 14:06:09 -0700 (MST) Received: from [10.1.194.250] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR3006FERXYVQ10@mail-amer.sun.com>; Tue, 06 Nov 2007 14:05:59 -0700 (MST) Date: Tue, 06 Nov 2007 15:05:55 -0600 From: Robert Gordon Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections 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: -1.0 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Benny Halevy , 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 Nov 6, 2007, at 2:53 PM, Noveck, Dave wrote: >> I agree; The seqid MUST be zero. If not then the DS will return >> NFS4ERR_INVAL (?) > > I was thinking BAD_STATEID since every op that can receive this > already > has to have BAD_STATEID in its error list. I'm trying to avoid > requiring any more changes to the error/op lists, although I hope I > won't push that to exteremes. I agree. (but think that NAUGHTY_STATEID would add some humor to the protocol) Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 18:15: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 1IpXdl-0001LX-UX; Tue, 06 Nov 2007 18:15:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpXdk-0001Iv-B9 for nfsv4@ietf.org; Tue, 06 Nov 2007 18:15:24 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpXdh-0004E3-Bu for nfsv4@ietf.org; Tue, 06 Nov 2007 18:15:24 -0500 X-IronPort-AV: E=Sophos;i="4.21,380,1188802800"; d="scan'208";a="120133977" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 06 Nov 2007 15:15:20 -0800 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 lA6NFKPB016286; Tue, 6 Nov 2007 15:15:20 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 15:15:20 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 15:15:20 -0800 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] Proposed resolutions for some pnfs-related [[Comment]] sections Date: Tue, 6 Nov 2007 18:15:17 -0500 Message-ID: In-Reply-To: <2A0C4E29-9858-4D3E-82D9-ED59F194733F@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections Thread-Index: AcggtiN5NKuKY5cxTe+dmlyBPLQPAwAFAFpw From: "Noveck, Dave" To: "Robert Gordon" X-OriginalArrivalTime: 06 Nov 2007 23:15:20.0001 (UTC) FILETIME=[E6571B10:01C820CA] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Benny Halevy , 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 > > How does the client know if mandatory locking is implemented? > NFS4ERR_LOCKED would have been returned to the client if it had=20 > used an open or delegation stateid;=20 If there is an effective mandatory lock that would prevent the IO without us knowing the lockowner that we get LOCKED and he client will subsequently, for that open file, use the locking stateid if one is available. I think that works OK. If he hasn't got LOCKED he SHOULD NOT use the lock stateid. If he has a delegation, then the delegation stateid should be used. In that case, the client has an assurance that either all opens are from that one client (write delegation case) and the client is capable of checking himself among the various lockowners or there can be no mandatory locks (ead delegation case) and IO should just go through.=20 -----Original Message----- From: Robert Gordon [mailto:Robert.Gordon@Sun.COM]=20 Sent: Tuesday, November 06, 2007 3:45 PM To: Noveck, Dave Cc: Benny Halevy; NFSv4 Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections On Nov 6, 2007, at 2:12 PM, Noveck, Dave wrote: > In the case of a DS, it is just simpler to say that seqid field zero=20 > is the only allowable case. That would avoid making implementation to > work to support somethng that doesn't seem to have any value. I agree; The seqid MUST be zero. If not then the DS will return NFS4ERR_INVAL (?) >> We also need to say that the client should use either the OPEN or=20 >> DELEGATION stateid, and may use the lock stateid (with the most=20 >> recent sequence id) if mandatory locking is implemented. > > How does the client know if mandatory locking is implemented? NFS4ERR_LOCKED would have been returned to the client if it had used an open or delegation stateid; > > As to the seqid, I don't see the value. Since the DS cannot be sure=20 > that you are sending the correct one, it needs to validate it assuming > you are not. But if it capable of doing that, then it should be=20 > capable of getting the appropriate state to use, without you sending=20 > the seqid. You are right; and I agree. I'd forgotten the following :- "14.10.2.1. Lock State Propagation If the pNFS server supports mandatory locking, any mandatory locks on a file MUST be made effective at the data servers before the request that establishes them returns to the caller. Thus, mandatory lock state MUST be synchronously propagated to the data servers." and (for completeness) we also say this in the last paragraph of 13.5.1: "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." -- Robert.=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 06 18:33: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 1IpXv9-0002Og-TA; Tue, 06 Nov 2007 18:33:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpXv8-0002Nf-O9 for nfsv4@ietf.org; Tue, 06 Nov 2007 18:33:22 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpXv3-0004zl-Mz for nfsv4@ietf.org; Tue, 06 Nov 2007 18:33:22 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA6NXGex017964 for ; Tue, 6 Nov 2007 23:33:16 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR300D01YMJDR00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Tue, 06 Nov 2007 16:33:16 -0700 (MST) Received: from [10.1.194.250] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR3009HVYRCXDA0@mail-amer.sun.com>; Tue, 06 Nov 2007 16:33:12 -0700 (MST) Date: Tue, 06 Nov 2007 17:33:09 -0600 From: Robert Gordon Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections In-reply-to: To: "Noveck, Dave" Message-id: <4E9E8C3F-89F6-461E-A937-9CAA70521416@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: -1.0 (-) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Benny Halevy , 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 Nov 6, 2007, at 5:15 PM, Noveck, Dave wrote: >>> How does the client know if mandatory locking is implemented? > >> NFS4ERR_LOCKED would have been returned to the client if it had >> used an open or delegation stateid; > > If there is an effective mandatory lock that would prevent the IO > without us knowing the lockowner that we get LOCKED and he client will > subsequently, for that open file, use the locking stateid if one is > available. I think that works OK. If he hasn't got LOCKED he SHOULD > NOT use the lock stateid. Correct, that is what i was thinking. > > If he has a delegation, then the delegation stateid should be > used. In > that case, the client has an assurance that either all opens are from > that one client (write delegation case) and the client is capable of > checking himself among the various lockowners or there can be no > mandatory locks (ead delegation case) and IO should just go through. yes.. -- Robert... "Don't Make Assumptions" _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From sameul892@blueroomsound.com Tue Nov 06 19:42:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpYzj-0004JT-VS for nfsv4-archive@lists.ietf.org; Tue, 06 Nov 2007 19:42:11 -0500 Received: from c9349495.virtua.com.br ([201.52.148.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpYzg-0002us-Ax for nfsv4-archive@lists.ietf.org; Tue, 06 Nov 2007 19:42:11 -0500 Received: by 10.223.118.129 with SMTP id oKTQsQhlKGVld; Tue, 6 Nov 2007 22:41:23 -0300 (GMT) Received: by 192.168.79.139 with SMTP id opWSxmUygReXOV.6442446547528; Tue, 6 Nov 2007 22:41:21 -0300 (GMT) Message-ID: <000701c820df$4b020ac0$959434c9@hideusnofear> From: "sameul mankefors" To: Subject: ihcot Date: Tue, 6 Nov 2007 22:41:18 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C820C6.25B4D2C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.2 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 ------=_NextPart_000_0003_01C820C6.25B4D2C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello friends nfsv4-archive Before Manster i had 0 ladies, now i=92ve had 3 this week, its all about = confidence http://www.kocbanki.com/ sameul mankefors ------=_NextPart_000_0003_01C820C6.25B4D2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hello friends nfsv4-archive
Before Manster i had 0 ladies, now i=92ve had = 3 this week,=20 its all about confidence
http://www.kocbanki.com/
sameul mankefors
------=_NextPart_000_0003_01C820C6.25B4D2C0-- From nfsv4-bounces@ietf.org Wed Nov 07 10:58: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 1IpnIc-00078V-2U; Wed, 07 Nov 2007 10:58:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpnIa-00076q-Qe for nfsv4@ietf.org; Wed, 07 Nov 2007 10:58:36 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpnIa-0005Bd-DG for nfsv4@ietf.org; Wed, 07 Nov 2007 10:58:36 -0500 X-IronPort-AV: E=Sophos;i="4.21,385,1188802800"; d="scan'208";a="120318875" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 07 Nov 2007 07:58:35 -0800 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 lA7FwZLE004467 for ; Wed, 7 Nov 2007 07:58:35 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 07:58:35 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 07:58:35 -0800 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: Wed, 7 Nov 2007 10:58:34 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PUTFH+SECINFO_NO_NAME+OPEN(fh) issue Thread-Index: AcghVwzNCsUxHWHHTfyX8dJRhwscuw== From: "Noveck, Dave" To: X-OriginalArrivalTime: 07 Nov 2007 15:58:35.0251 (UTC) FILETIME=[0D815430:01C82157] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [nfsv4] PUTFH+SECINFO_NO_NAME+OPEN(fh) issue 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 is my take on this troublesome compound. The problem here is that with the rules as we have them OPEN(fh) needs to be able to return WRONGSEC but is not allowed to. It isn't clear how to fix this. Two proposals that have=20 not seemed satisfactory are: Mike has proposed that we legislate this case out of existence and say that the OPEN(fh) (and really any operation) can return UNSAFE_COMPOUND or a new=20 error BAD_COMPOUND. I've suggested allowing all those ops to return=20 WRONGSEC. The problem here is that we have to create an exception to the normal expectation that PUTFH would check for WRONGSEC to allow it to be used as a preliminary to SECINFO_NO_NAME. Once you allow this, then you seem stuck with the case that Jeff has proposed in which someone takes things one step further and tries to use the current fh after SECINFO_NO_NAME. If we were earlier in the process I would propose that=20 SECINFO_NO_NAME be redefined not to use the cfh, i.e. that it takes the fh to work on as a separate parameter. Then you wouldn't need the exception for PUTFH+SECINFO_NO_NAME and PUTFH+OPEN(fh) would result in WRONGSEC on the PUTFH, whether the SECINFO_NO_NAME was interposed or not. It seems like it is too late in the game to make that sort of change=20 to the XDR definition of SECINFO_NO_NAME. So an alternative that would address this but is less=20 disruptive than changing the XDR definition of SECINFO_NO_NAME. is to specify that SECINFO_NO_NAME consume the current fh. That is, if there is a saved fh, that becomes the current fh, while if there isn't, the COMPOUND has no cfh after the=20 SECINFO_NO_NAME. I assert that would not be disruptive since any compound that would be disrupted by that change is one that uses the cfh after SECINFO_NO_NAME, i.e. is one that has exactly the problem we are trying to address. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 13:09: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 1IppLe-0006Yz-II; Wed, 07 Nov 2007 13:09:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IppLd-0006Wh-B3 for nfsv4@ietf.org; Wed, 07 Nov 2007 13:09:53 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IppLb-0002Ix-SA for nfsv4@ietf.org; Wed, 07 Nov 2007 13:09:53 -0500 X-IronPort-AV: E=Sophos;i="4.21,385,1188802800"; d="scan'208";a="120360675" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 07 Nov 2007 10:09:29 -0800 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 lA7I4iI0019903; Wed, 7 Nov 2007 10:09:22 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 10:08:52 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 10:08:52 -0800 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] Proposed resolutions for some pnfs-related [[Comment]] sections Date: Wed, 7 Nov 2007 13:08:51 -0500 Message-ID: In-Reply-To: <472D6DE0.7090505@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections Thread-Index: AcgesGGcWDEHlIMPQ96cHybRzBGVfgCtToHA From: "Noveck, Dave" To: "Benny Halevy" X-OriginalArrivalTime: 07 Nov 2007 18:08:52.0386 (UTC) FILETIME=[40E17820:01C82169] X-Spam-Score: -4.0 (----) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 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 have the following issue with access time in LAYOUTCOMMIT: > >=20 > > > > The loca_time_modify and loca_time_access If LAYOUTCOMMIT > > is only for writes, then why update access time? fields > > allow the client to suggest times it would like the metadata > > server to set. The metadata server may use these time values or > > it may use the time of the LAYOUTCOMMIT operation to set these > > time values. If the metadata server uses the client provided > > times, it should ensure time does not flow backwards. If the > > client wants to force the metadata server to set an exact time, > > the client should use a SETATTR operation in a compound right > > after LAYOUTCOMMIT. See for > > more details. If the new client desires the resultant mtime or > > atime, it should construct the COMPOUND so that a GETATTR > > follows the LAYOUTCOMMIT. > > > >=20 > > The issue of loca_access_time was discussed at the pnfs review but as > > I understand things, there was no resolution that got universal > > approval. The simplest thing, which I'm going to propose, if nobody > > has a better idea, is simply to get of rid loca_access_time. >=20 > I object to doing that. OK, but right now, we have a situation in LAYOUTCOMMIT is discussed in several dozen places, and most them implicitly give the impression and many of them explicitly (including the description of LAYOUTCOMMIT itself) say that this is to be used when writing. That seems to be=20 inconsistent with having access time be a field in that and that is the issue that is raised in the , and that we have to address very=20 soon. > Since the MDS does intercept the I/Os going to the DSs loca_access_time > will be useful to the MD server, otherwise, if it supports atime > (and is configured to track it), it will be forced to get the atime > from all the file's DSs which can have a significant hit on performance. Asking the clients to communicate with the MDS to propagate this will also have a performance cost. It is true that the client would have to update only a single MDS, but if this is within the control protocol, we have opportunities for extensive batching of updates to multiple files=20 to be transferred at the same time, so it is not clear to me that making the client do this is a net win. > Note that unlike an explicit SETATTR this value is basically a hint and > the server does not have to respect it. >=20 > Also, I would like the spec to be clear about allowing LAYOUTCOMMIT > for reads as this is still needed for the objects layout type for reporting > read errors. This is not a case in which the spec is unclear and you can simply=20 clarify it allowing LAYOUTCOMMIT on read. It seems to me that you are=20 asking for a fundamentally different treatment of LAYOUTCOMMIT making it something that can/should/must (depending on what?) be used for various types of layouts under various conditions. That is very different from=20 what is there now and I don't see any way that that level of rewriting=20 can be done in time to get it into draft-16. -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Sunday, November 04, 2007 2:00 AM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections On Nov. 02, 2007, 20:49 +0200, "Noveck, Dave" wrote: > I'm trying to get rid of many [[Comment]] sections and there are a=20 > few discussed below that I'd like to run by people. Let me know > right away if you have an issue with any of the proposed resolutions. >=20 > The first concerns the possibility which might exist for a file=20 > layout type to have a COMPOUND that contains some ops addressing > the server as a metadata server and others as a data server. I > think we should disallow this. >=20 > > It is not allowed for a single COMPOUND to contain operations > acting on both individual personalities, although an COMPOUND > pertaining to a single individual personality may contain > housekeeping operation which affect both personalities. > This makes sense to me. >=20 > The next item relates to stateids and IO mode validations: >=20 >
> > Open and deny mode validation MUST be performed against > the open and deny mode(s) held by the data servers. When > access is reduced or a deny mode made more restrictive > (because of CLOSE or DOWNGRADE) the data server MUST > prevent any I/Os that would be denied if performed on the > metadata server. Conversely, when access is expanded, > the data server MUST NOT reject a request because of > open or deny issues without making sure that the open > mode upgrade or deny mode relaxation is not in progress. > > It seems like the recent (June/July 2007) > stateid.seqid discussion might modify this; > a client might send a new state.seqid, that tells the data server > it's seqid is out of date; the data server might return > NFS4ERR_DELAY. > >=20 > >
=09 >=20 > In addition to the cref section there seems to me to be confusion > in the other parts of this and adjoining sections. The big issue > is that there is discussion of getting stateid seqids right but > that seems to me pointless complexity for the data server. Given > parallel open the general pattern will be to use seqid=3D0 and only > use non-zero seqid for a few special operation like OPEN_DOWNGRADE > and CLOSE, none of which is going to be sent to the data server. >=20 > So I'm proposing that the stateids for the data server always have > seqid as zero and you get BAD_STATEID if not. I thought that the client should just use the most recent stateid returned to it by the MDS, as per 14.10.1: "When the client issues I/O to a data server, the stateid used must be one previously returned by the metadata server. Permitted stateids include an open stateid (the stateid field of data type OPEN4resok as returned by OPEN), a delegation stateid (the stateid field of data types open_read_delegation4 and open_write_delegation4 as returned by OPEN or WANT_DELEGATION, or as sent by CB_PUSH_DELEG), or a stateid returned by the LOCK or LOCKU operations." >=20 > Another thing that is wrong about this section is the discussion of > deny modes. Deny modes have their effect at open time, and, unless > we have IO's with special stateids (which I believe are not allowed)=20 > do not affect IO's. Right >=20 > Also, "without making sure that the open mode upgrade or deny mode=20 > relaxation is not in progress" seems flat-out wrong. You can never=20 > be assured that it is not in progress when you actually do the > rejection. > If you check that it is not an a given instant and the proceed to > do the rejection, it might be in progress when you actually do the > rejection. All you should check is that it hasn't previously been > made allowable. >=20 > We have the following issue with access time in LAYOUTCOMMIT: >=20 > > The loca_time_modify and loca_time_access If LAYOUTCOMMIT > is only for writes, then why update access time? fields > allow the client to suggest times it would like the metadata > server to set. The metadata server may use these time values or > it may use the time of the LAYOUTCOMMIT operation to set these > time values. If the metadata server uses the client provided > times, it should ensure time does not flow backwards. If the > client wants to force the metadata server to set an exact time, > the client should use a SETATTR operation in a compound right > after LAYOUTCOMMIT. See = for > more details. If the new client desires the resultant mtime or > atime, it should construct the COMPOUND so that a GETATTR > follows the LAYOUTCOMMIT. > >=20 > The issue of loca_access_time was discussed at the pnfs review but as > I understand things, there was no resolution that got universal > approval. The simplest thing, which I'm going to propose, if nobody > has a better idea, is simply to get of rid loca_access_time. I object to doing that. Since the MDS does intercept the I/Os going to the DSs loca_access_time will be useful to the MD server, otherwise, if it supports atime (and is configured to track it), it will be forced to get the atime from all the file's DSs which can have a significant hit on performance. Note that unlike an explicit SETATTR this value is basically a hint and the server does not have to respect it. Also, I would like the spec to be clear about allowing LAYOUTCOMMIT for reads as this is still needed for the objects layout type for reporting read errors. >=20 > Also we have the following inconsistent paragraphs: >=20 > > When lr_returntype is LAYOUTRETURN4_FILE, the layout being > returned may be a subdivision of a layout previously obtained > with LAYOUTGET. The layout being returned may also be a subset > or superset of a layout specified by CB_LAYOUTRECALL. However, > if it is a subset, the recall is not complete until the full > recalled scope has been returned. Recalled scope refers to the > octet range in the case of LAYOUTRETURN4_FILE, use of > LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. It > is also permissible, and no error should result, for a client to > return a octet range covering a layout it does not hold. If the > lrf_length is all 1s, the layout covers the range from > lrf_offset to EOF. > >=20 > And, >=20 > > If the layout identified in the arguments does not exist, the > error > NFS4ERR_BADLAYOUT is returned. If a layout exists, but the iomode > does not match, NFS4ERR_BADIOMODE is returned.=20 > =20 > This error > return description does not align with the statement above that > the client should not receive an error when it returns a layout > that it does not hold.=20 > > > =09 > It appears to me that the intent of the first paragraph cited was to=20 > simplify the job of the client, particularly in those cases (like the > file layout type) where layouts are simple so that it can avoid detailed > logic to keep precise track of the octet ranges for which it has a > layout. =20 > On the other hand, having the server be unable to report cases in which=20 > a the client has lost its mind is troublesome. Here's my suggested=20 > resolution. >=20 > > When lr_returntype is LAYOUTRETURN4_FILE, the layout being > returned may be a subdivision of a layout previously obtained > with LAYOUTGET. The layout being returned may also be a subset > or superset of a layout specified by CB_LAYOUTRECALL. However, > if it is a subset, the recall is not complete until the full > recalled scope has been returned. Recalled scope refers to the > octet range in the case of LAYOUTRETURN4_FILE, use of > LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. It > is also permissible, and no error should result, for a client to > return an octet range covering a layout it does not currently > hold, > as long as it, at some time held a layout for some octet range of > file in question. If the lrf_length is all 1s, the layout covers > the range from lrf_offset to the last octet for which the client > actually holds a layout. > >=20 > And, >=20 > > If it determinable that layout identified in the argument is such > that the client could never have possessed a layout for that file > (of any octet range) NFS4ERR_BADLAYOUT should be returned. If a > layout exists, but the iomode does not match, NFS4ERR_BADIOMODE=20 > is returned.=20 > I'm OK with that. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 13:32: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 1IpphB-0004qo-1U; Wed, 07 Nov 2007 13:32:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipph9-0004pr-5j for nfsv4@ietf.org; Wed, 07 Nov 2007 13:32:07 -0500 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 1Ipph2-0003jZ-QO for nfsv4@ietf.org; Wed, 07 Nov 2007 13:32:07 -0500 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 lA7IVwht011284; Wed, 7 Nov 2007 13:31:58 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 7 Nov 2007 13:31:58 -0500 Received: from fs1.bhalevy.com ([172.17.28.131]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Nov 2007 13:31:55 -0500 Message-ID: <47320499.2070302@panasas.com> Date: Wed, 07 Nov 2007 20:31:53 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Noveck, Dave" Subject: Re: should we allow LAYOUTCOMMIT for reads (was: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 18:31:55.0306 (UTC) FILETIME=[792A50A0:01C8216C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e 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 Can we optionally provide access_time and/or a layout_type specific structure piggybacked on LAYOUTRETURN instead? Benny On Nov. 07, 2007, 20:08 +0200, "Noveck, Dave" wrote: >>> We have the following issue with access time in LAYOUTCOMMIT: >>> >>> >>> The loca_time_modify and loca_time_access If > LAYOUTCOMMIT >>> is only for writes, then why update access time? fields >>> allow the client to suggest times it would like the metadata >>> server to set. The metadata server may use these time values > or >>> it may use the time of the LAYOUTCOMMIT operation to set these >>> time values. If the metadata server uses the client provided >>> times, it should ensure time does not flow backwards. If the >>> client wants to force the metadata server to set an exact > time, >>> the client should use a SETATTR operation in a compound right >>> after LAYOUTCOMMIT. See > for >>> more details. If the new client desires the resultant mtime > or >>> atime, it should construct the COMPOUND so that a GETATTR >>> follows the LAYOUTCOMMIT. >>> >>> >>> The issue of loca_access_time was discussed at the pnfs review but > as >>> I understand things, there was no resolution that got universal >>> approval. The simplest thing, which I'm going to propose, if nobody >>> has a better idea, is simply to get of rid loca_access_time. >> I object to doing that. > > OK, but right now, we have a situation in LAYOUTCOMMIT is discussed in > several dozen places, and most them implicitly give the impression and > many of them explicitly (including the description of LAYOUTCOMMIT > itself) say that this is to be used when writing. That seems to be > inconsistent with having access time be a field in that and that is the > issue that is raised in the , and that we have to address very > soon. > >> Since the MDS does intercept the I/Os going to the DSs > loca_access_time >> will be useful to the MD server, otherwise, if it supports atime >> (and is configured to track it), it will be forced to get the atime >> from all the file's DSs which can have a significant hit on > performance. > > Asking the clients to communicate with the MDS to propagate this will > also have a performance cost. It is true that the client would have to > update only a single MDS, but if this is within the control protocol, we > have opportunities for extensive batching of updates to multiple files > to be transferred at the same time, so it is not clear to me that making > the client do this is a net win. > >> Note that unlike an explicit SETATTR this value is basically a hint > and >> the server does not have to respect it. >> >> Also, I would like the spec to be clear about allowing LAYOUTCOMMIT >> for reads as this is still needed for the objects layout type for > reporting >> read errors. > > This is not a case in which the spec is unclear and you can simply > clarify it allowing LAYOUTCOMMIT on read. It seems to me that you are > asking for a fundamentally different treatment of LAYOUTCOMMIT making it > > something that can/should/must (depending on what?) be used for various > types of layouts under various conditions. That is very different from > what is there now and I don't see any way that that level of rewriting > can be done in time to get it into draft-16. > > > > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com] > Sent: Sunday, November 04, 2007 2:00 AM > To: Noveck, Dave > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related > [[Comment]] sections > > > On Nov. 02, 2007, 20:49 +0200, "Noveck, Dave" > wrote: >> I'm trying to get rid of many [[Comment]] sections and there are a >> few discussed below that I'd like to run by people. Let me know >> right away if you have an issue with any of the proposed resolutions. >> >> The first concerns the possibility which might exist for a file >> layout type to have a COMPOUND that contains some ops addressing >> the server as a metadata server and others as a data server. I >> think we should disallow this. >> > > > >> >> It is not allowed for a single COMPOUND to contain operations >> acting on both individual personalities, although an COMPOUND >> pertaining to a single individual personality may contain >> housekeeping operation which affect both personalities. >> > > This makes sense to me. > > > >> The next item relates to stateids and IO mode validations: >> >>
>> >> Open and deny mode validation MUST be performed against >> the open and deny mode(s) held by the data servers. When >> access is reduced or a deny mode made more restrictive >> (because of CLOSE or DOWNGRADE) the data server MUST >> prevent any I/Os that would be denied if performed on the >> metadata server. Conversely, when access is expanded, >> the data server MUST NOT reject a request because of >> open or deny issues without making sure that the open >> mode upgrade or deny mode relaxation is not in progress. >> >> It seems like the recent (June/July 2007) >> stateid.seqid discussion might modify this; >> a client might send a new state.seqid, that tells the data server >> it's seqid is out of date; the data server might return >> NFS4ERR_DELAY. >> >> >> >>
>> >> In addition to the cref section there seems to me to be confusion >> in the other parts of this and adjoining sections. The big issue >> is that there is discussion of getting stateid seqids right but >> that seems to me pointless complexity for the data server. Given >> parallel open the general pattern will be to use seqid=0 and only >> use non-zero seqid for a few special operation like OPEN_DOWNGRADE >> and CLOSE, none of which is going to be sent to the data server. >> >> So I'm proposing that the stateids for the data server always have >> seqid as zero and you get BAD_STATEID if not. > > I thought that the client should just use the most recent stateid > returned > to it by the MDS, as per 14.10.1: > "When the client issues I/O to a data server, the stateid used must be > one previously returned by the metadata server. Permitted stateids > include an open stateid (the stateid field of data type OPEN4resok as > returned by OPEN), a delegation stateid (the stateid field of data types > open_read_delegation4 and open_write_delegation4 as returned by OPEN or > WANT_DELEGATION, or as sent by CB_PUSH_DELEG), or a stateid returned by > the LOCK or LOCKU operations." > >> Another thing that is wrong about this section is the discussion of >> deny modes. Deny modes have their effect at open time, and, unless >> we have IO's with special stateids (which I believe are not allowed) >> do not affect IO's. > > Right > >> Also, "without making sure that the open mode upgrade or deny mode >> relaxation is not in progress" seems flat-out wrong. You can never >> be assured that it is not in progress when you actually do the >> rejection. >> If you check that it is not an a given instant and the proceed to >> do the rejection, it might be in progress when you actually do the >> rejection. All you should check is that it hasn't previously been >> made allowable. >> >> We have the following issue with access time in LAYOUTCOMMIT: >> >> >> The loca_time_modify and loca_time_access If LAYOUTCOMMIT >> is only for writes, then why update access time? fields >> allow the client to suggest times it would like the metadata >> server to set. The metadata server may use these time values or >> it may use the time of the LAYOUTCOMMIT operation to set these >> time values. If the metadata server uses the client provided >> times, it should ensure time does not flow backwards. If the >> client wants to force the metadata server to set an exact time, >> the client should use a SETATTR operation in a compound right >> after LAYOUTCOMMIT. See for >> more details. If the new client desires the resultant mtime or >> atime, it should construct the COMPOUND so that a GETATTR >> follows the LAYOUTCOMMIT. >> >> >> The issue of loca_access_time was discussed at the pnfs review but as >> I understand things, there was no resolution that got universal >> approval. The simplest thing, which I'm going to propose, if nobody >> has a better idea, is simply to get of rid loca_access_time. > > I object to doing that. > Since the MDS does intercept the I/Os going to the DSs loca_access_time > will be useful to the MD server, otherwise, if it supports atime > (and is configured to track it), it will be forced to get the atime > from all the file's DSs which can have a significant hit on performance. > Note that unlike an explicit SETATTR this value is basically a hint and > the server does not have to respect it. > > Also, I would like the spec to be clear about allowing LAYOUTCOMMIT > for reads as this is still needed for the objects layout type for > reporting > read errors. > >> Also we have the following inconsistent paragraphs: >> >> >> When lr_returntype is LAYOUTRETURN4_FILE, the layout being >> returned may be a subdivision of a layout previously obtained >> with LAYOUTGET. The layout being returned may also be a subset >> or superset of a layout specified by CB_LAYOUTRECALL. However, >> if it is a subset, the recall is not complete until the full >> recalled scope has been returned. Recalled scope refers to the >> octet range in the case of LAYOUTRETURN4_FILE, use of >> LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. It >> is also permissible, and no error should result, for a client to >> return a octet range covering a layout it does not hold. If the >> lrf_length is all 1s, the layout covers the range from >> lrf_offset to EOF. >> >> >> And, >> >> >> If the layout identified in the arguments does not exist, the >> error >> NFS4ERR_BADLAYOUT is returned. If a layout exists, but the > iomode >> does not match, NFS4ERR_BADIOMODE is returned. >> >> This error >> return description does not align with the statement above that >> the client should not receive an error when it returns a layout >> that it does not hold. >> >> >> >> It appears to me that the intent of the first paragraph cited was to >> simplify the job of the client, particularly in those cases (like the >> file layout type) where layouts are simple so that it can avoid > detailed >> logic to keep precise track of the octet ranges for which it has a >> layout. >> On the other hand, having the server be unable to report cases in > which >> a the client has lost its mind is troublesome. Here's my suggested >> resolution. >> >> >> When lr_returntype is LAYOUTRETURN4_FILE, the layout being >> returned may be a subdivision of a layout previously obtained >> with LAYOUTGET. The layout being returned may also be a subset >> or superset of a layout specified by CB_LAYOUTRECALL. However, >> if it is a subset, the recall is not complete until the full >> recalled scope has been returned. Recalled scope refers to the >> octet range in the case of LAYOUTRETURN4_FILE, use of >> LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. It >> is also permissible, and no error should result, for a client to >> return an octet range covering a layout it does not currently >> hold, >> as long as it, at some time held a layout for some octet range > of >> file in question. If the lrf_length is all 1s, the layout covers > >> the range from lrf_offset to the last octet for which the client > >> actually holds a layout. >> >> >> And, >> >> >> If it determinable that layout identified in the argument is > such >> that the client could never have possessed a layout for that > file >> (of any octet range) NFS4ERR_BADLAYOUT should be returned. If a > >> layout exists, but the iomode does not match, NFS4ERR_BADIOMODE >> is returned. >> > > I'm OK with that. -- Benny Halevy Software Architect Tel/Fax: +972-3-647-8340 Mobile: +972-54-802-8340 US: +1-412-203-3187 bhalevy@panasas.com Panasas, Inc. Leader in Parallel Storage www.panasas.com _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 13:39: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 1IppoZ-0006Mr-3h; Wed, 07 Nov 2007 13:39:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IppoX-0006LM-Fm for nfsv4@ietf.org; Wed, 07 Nov 2007 13:39:45 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IppoT-0003yR-4g for nfsv4@ietf.org; Wed, 07 Nov 2007 13:39:45 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA7IdeGW023392 for ; Wed, 7 Nov 2007 18:39:40 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR500201FF0EA00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 07 Nov 2007 11:39:40 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-138-155.dsl.austtx.sbcglobal.net [71.145.138.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR500DI1FTZB3A0@mail-amer.sun.com>; Wed, 07 Nov 2007 11:39:36 -0700 (MST) Date: Wed, 07 Nov 2007 12:40:05 -0600 From: Spencer Shepler Subject: Re: should we allow LAYOUTCOMMIT for reads (was: [nfsv4] Proposed resolutions for some pnfs-related [[Comment]] sections) In-reply-to: <47320499.2070302@panasas.com> To: Benny Halevy Message-id: <0E4B285A-A2CA-4F42-ABE1-F13ECB59B066@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: <47320499.2070302@panasas.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86 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 If the only purpose of the access time field in layoutcommit is to allow the client the ability to update it (no release of allocations or other side -effects), wouldn't SETATTR be sufficient for the client? Or is there concern about appropriate access in setting that attribute where a layout based update of access time would be better? Also, given that many NFS servers disable access time updates for performance reasons, is this a hard/strict requirement? Spencer On Nov 7, 2007, at 12:31 PM, Benny Halevy wrote: > > Can we optionally provide access_time and/or a layout_type specific > structure > piggybacked on LAYOUTRETURN instead? > > Benny > > On Nov. 07, 2007, 20:08 +0200, "Noveck, Dave" > wrote: >>>> We have the following issue with access time in LAYOUTCOMMIT: >>>> >>>> >>>> The loca_time_modify and loca_time_access If >> LAYOUTCOMMIT >>>> is only for writes, then why update access time? >>>> fields >>>> allow the client to suggest times it would like the metadata >>>> server to set. The metadata server may use these time values >> or >>>> it may use the time of the LAYOUTCOMMIT operation to set >>>> these >>>> time values. If the metadata server uses the client provided >>>> times, it should ensure time does not flow backwards. If the >>>> client wants to force the metadata server to set an exact >> time, >>>> the client should use a SETATTR operation in a compound right >>>> after LAYOUTCOMMIT. See >> for >>>> more details. If the new client desires the resultant mtime >> or >>>> atime, it should construct the COMPOUND so that a GETATTR >>>> follows the LAYOUTCOMMIT. >>>> >>>> >>>> The issue of loca_access_time was discussed at the pnfs review but >> as >>>> I understand things, there was no resolution that got universal >>>> approval. The simplest thing, which I'm going to propose, if >>>> nobody >>>> has a better idea, is simply to get of rid loca_access_time. >>> I object to doing that. >> >> OK, but right now, we have a situation in LAYOUTCOMMIT is >> discussed in >> several dozen places, and most them implicitly give the impression >> and >> many of them explicitly (including the description of LAYOUTCOMMIT >> itself) say that this is to be used when writing. That seems to be >> inconsistent with having access time be a field in that and that >> is the >> issue that is raised in the , and that we have to address very >> soon. >> >>> Since the MDS does intercept the I/Os going to the DSs >> loca_access_time >>> will be useful to the MD server, otherwise, if it supports atime >>> (and is configured to track it), it will be forced to get the atime >>> from all the file's DSs which can have a significant hit on >> performance. >> >> Asking the clients to communicate with the MDS to propagate this will >> also have a performance cost. It is true that the client would >> have to >> update only a single MDS, but if this is within the control >> protocol, we >> have opportunities for extensive batching of updates to multiple >> files >> to be transferred at the same time, so it is not clear to me that >> making >> the client do this is a net win. >> >>> Note that unlike an explicit SETATTR this value is basically a hint >> and >>> the server does not have to respect it. >>> >>> Also, I would like the spec to be clear about allowing LAYOUTCOMMIT >>> for reads as this is still needed for the objects layout type for >> reporting >>> read errors. >> >> This is not a case in which the spec is unclear and you can simply >> clarify it allowing LAYOUTCOMMIT on read. It seems to me that you >> are >> asking for a fundamentally different treatment of LAYOUTCOMMIT >> making it >> >> something that can/should/must (depending on what?) be used for >> various >> types of layouts under various conditions. That is very different >> from >> what is there now and I don't see any way that that level of >> rewriting >> can be done in time to get it into draft-16. >> >> >> >> -----Original Message----- >> From: Benny Halevy [mailto:bhalevy@panasas.com] >> Sent: Sunday, November 04, 2007 2:00 AM >> To: Noveck, Dave >> Cc: nfsv4@ietf.org >> Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related >> [[Comment]] sections >> >> >> On Nov. 02, 2007, 20:49 +0200, "Noveck, Dave" >> >> wrote: >>> I'm trying to get rid of many [[Comment]] sections and there are a >>> few discussed below that I'd like to run by people. Let me know >>> right away if you have an issue with any of the proposed >>> resolutions. >>> >>> The first concerns the possibility which might exist for a file >>> layout type to have a COMPOUND that contains some ops addressing >>> the server as a metadata server and others as a data server. I >>> think we should disallow this. >>> >> >> >> >>> >>> It is not allowed for a single COMPOUND to contain operations >>> acting on both individual personalities, although an COMPOUND >>> pertaining to a single individual personality may contain >>> housekeeping operation which affect both personalities. >>> >> >> This makes sense to me. >> >> >> >>> The next item relates to stateids and IO mode validations: >>> >>>
>>> >>> Open and deny mode validation MUST be performed against >>> the open and deny mode(s) held by the data servers. When >>> access is reduced or a deny mode made more restrictive >>> (because of CLOSE or DOWNGRADE) the data server MUST >>> prevent any I/Os that would be denied if performed on the >>> metadata server. Conversely, when access is expanded, >>> the data server MUST NOT reject a request because of >>> open or deny issues without making sure that the open >>> mode upgrade or deny mode relaxation is not in progress. >>> >>> It seems like the recent (June/July 2007) >>> stateid.seqid discussion might modify this; >>> a client might send a new state.seqid, that tells the data server >>> it's seqid is out of date; the data server might return >>> NFS4ERR_DELAY. >>> >>> >>> >>>
>>> >>> In addition to the cref section there seems to me to be confusion >>> in the other parts of this and adjoining sections. The big issue >>> is that there is discussion of getting stateid seqids right but >>> that seems to me pointless complexity for the data server. Given >>> parallel open the general pattern will be to use seqid=0 and only >>> use non-zero seqid for a few special operation like OPEN_DOWNGRADE >>> and CLOSE, none of which is going to be sent to the data server. >>> >>> So I'm proposing that the stateids for the data server always have >>> seqid as zero and you get BAD_STATEID if not. >> >> I thought that the client should just use the most recent stateid >> returned >> to it by the MDS, as per 14.10.1: >> "When the client issues I/O to a data server, the stateid used >> must be >> one previously returned by the metadata server. Permitted stateids >> include an open stateid (the stateid field of data type OPEN4resok as >> returned by OPEN), a delegation stateid (the stateid field of data >> types >> open_read_delegation4 and open_write_delegation4 as returned by >> OPEN or >> WANT_DELEGATION, or as sent by CB_PUSH_DELEG), or a stateid >> returned by >> the LOCK or LOCKU operations." >> >>> Another thing that is wrong about this section is the discussion of >>> deny modes. Deny modes have their effect at open time, and, unless >>> we have IO's with special stateids (which I believe are not allowed) >>> do not affect IO's. >> >> Right >> >>> Also, "without making sure that the open mode upgrade or deny mode >>> relaxation is not in progress" seems flat-out wrong. You can never >>> be assured that it is not in progress when you actually do the >>> rejection. >>> If you check that it is not an a given instant and the proceed to >>> do the rejection, it might be in progress when you actually do the >>> rejection. All you should check is that it hasn't previously been >>> made allowable. >>> >>> We have the following issue with access time in LAYOUTCOMMIT: >>> >>> >>> The loca_time_modify and loca_time_access If >>> LAYOUTCOMMIT >>> is only for writes, then why update access time? fields >>> allow the client to suggest times it would like the metadata >>> server to set. The metadata server may use these time >>> values or >>> it may use the time of the LAYOUTCOMMIT operation to set these >>> time values. If the metadata server uses the client provided >>> times, it should ensure time does not flow backwards. If the >>> client wants to force the metadata server to set an exact >>> time, >>> the client should use a SETATTR operation in a compound right >>> after LAYOUTCOMMIT. See >> > for >>> more details. If the new client desires the resultant >>> mtime or >>> atime, it should construct the COMPOUND so that a GETATTR >>> follows the LAYOUTCOMMIT. >>> >>> >>> The issue of loca_access_time was discussed at the pnfs review >>> but as >>> I understand things, there was no resolution that got universal >>> approval. The simplest thing, which I'm going to propose, if nobody >>> has a better idea, is simply to get of rid loca_access_time. >> >> I object to doing that. >> Since the MDS does intercept the I/Os going to the DSs >> loca_access_time >> will be useful to the MD server, otherwise, if it supports atime >> (and is configured to track it), it will be forced to get the atime >> from all the file's DSs which can have a significant hit on >> performance. >> Note that unlike an explicit SETATTR this value is basically a >> hint and >> the server does not have to respect it. >> >> Also, I would like the spec to be clear about allowing LAYOUTCOMMIT >> for reads as this is still needed for the objects layout type for >> reporting >> read errors. >> >>> Also we have the following inconsistent paragraphs: >>> >>> >>> When lr_returntype is LAYOUTRETURN4_FILE, the layout being >>> returned may be a subdivision of a layout previously obtained >>> with LAYOUTGET. The layout being returned may also be a >>> subset >>> or superset of a layout specified by CB_LAYOUTRECALL. >>> However, >>> if it is a subset, the recall is not complete until the full >>> recalled scope has been returned. Recalled scope refers to >>> the >>> octet range in the case of LAYOUTRETURN4_FILE, use of >>> LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. It >>> is also permissible, and no error should result, for a >>> client to >>> return a octet range covering a layout it does not hold. >>> If the >>> lrf_length is all 1s, the layout covers the range from >>> lrf_offset to EOF. >>> >>> >>> And, >>> >>> >>> If the layout identified in the arguments does not exist, the >>> error >>> NFS4ERR_BADLAYOUT is returned. If a layout exists, but the >> iomode >>> does not match, NFS4ERR_BADIOMODE is returned. >>> >>> This error >>> return description does not align with the statement above that >>> the client should not receive an error when it returns a layout >>> that it does not hold. >>> >>> >>> >>> It appears to me that the intent of the first paragraph cited was to >>> simplify the job of the client, particularly in those cases (like >>> the >>> file layout type) where layouts are simple so that it can avoid >> detailed >>> logic to keep precise track of the octet ranges for which it has a >>> layout. >>> On the other hand, having the server be unable to report cases in >> which >>> a the client has lost its mind is troublesome. Here's my suggested >>> resolution. >>> >>> >>> When lr_returntype is LAYOUTRETURN4_FILE, the layout being >>> returned may be a subdivision of a layout previously obtained >>> with LAYOUTGET. The layout being returned may also be a >>> subset >>> or superset of a layout specified by CB_LAYOUTRECALL. >>> However, >>> if it is a subset, the recall is not complete until the full >>> recalled scope has been returned. Recalled scope refers to >>> the >>> octet range in the case of LAYOUTRETURN4_FILE, use of >>> LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. It >>> is also permissible, and no error should result, for a >>> client to >>> return an octet range covering a layout it does not currently >>> hold, >>> as long as it, at some time held a layout for some octet range >> of >>> file in question. If the lrf_length is all 1s, the layout >>> covers >> >>> the range from lrf_offset to the last octet for which the >>> client >> >>> actually holds a layout. >>> >>> >>> And, >>> >>> >>> If it determinable that layout identified in the argument is >> such >>> that the client could never have possessed a layout for that >> file >>> (of any octet range) NFS4ERR_BADLAYOUT should be returned. >>> If a >> >>> layout exists, but the iomode does not match, >>> NFS4ERR_BADIOMODE >>> is returned. >>> >> >> I'm OK with that. > > > -- > Benny Halevy > Software Architect > Tel/Fax: +972-3-647-8340 > Mobile: +972-54-802-8340 > US: +1-412-203-3187 > bhalevy@panasas.com > > Panasas, Inc. > Leader in Parallel Storage > www.panasas.com > > _______________________________________________ > 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 Nov 07 14:03: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 1IpqBJ-0000DF-N4; Wed, 07 Nov 2007 14:03:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqBI-0000C1-50 for nfsv4@ietf.org; Wed, 07 Nov 2007 14:03:16 -0500 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 1IpqBG-0004Mg-IE for nfsv4@ietf.org; Wed, 07 Nov 2007 14:03:15 -0500 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 lA7J3DWh011981; Wed, 7 Nov 2007 14:03:13 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 7 Nov 2007 14:03:13 -0500 Received: from fs1.bhalevy.com ([172.17.28.131]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Nov 2007 14:03:09 -0500 Message-ID: <47320BEC.2010908@panasas.com> Date: Wed, 07 Nov 2007 21:03:08 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Spencer Shepler References: <47320499.2070302@panasas.com> <0E4B285A-A2CA-4F42-ABE1-F13ECB59B066@sun.com> In-Reply-To: <0E4B285A-A2CA-4F42-ABE1-F13ECB59B066@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 19:03:09.0791 (UTC) FILETIME=[D67206F0:01C82170] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Cc: "Noveck, Dave" , nfsv4@ietf.org Subject: [nfsv4] Re: should we allow LAYOUTCOMMIT for reads 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 Nov. 07, 2007, 20:40 +0200, Spencer Shepler wrote: > If the only purpose of the access time field in layoutcommit is to > allow the client the ability to update it (no release of allocations > or other side -effects), wouldn't SETATTR be sufficient for the client? > Or is there concern about appropriate access in setting that attribute > where a layout based update of access time would be better? explicit setattr won't work the same way if multiple clients are reading the file concurrently as it may set the access time backwards. The intention of the LAYOUTCOMMIT hint was to only set the access_time on the file if the client's reported access_time is later than the current access_time (and not in the future in which case the current time should be used) > > Also, given that many NFS servers disable access time updates for > performance reasons, is this a hard/strict requirement? We have customers that demand atime support so I would say that the ability to maintain it as efficiently as possible is important. Blocks can't get the atime from the LUNs and for objects it's impossible to amortize the cost of getting the atime from the OSDs over multiple objects in a batch. So doing the "soft" update at LAYOUTCOMMIT or LAYOUTRETURN time is essential. Benny > > Spencer > > On Nov 7, 2007, at 12:31 PM, Benny Halevy wrote: > >> Can we optionally provide access_time and/or a layout_type specific >> structure >> piggybacked on LAYOUTRETURN instead? >> >> Benny >> >> On Nov. 07, 2007, 20:08 +0200, "Noveck, Dave" >> wrote: >>>>> We have the following issue with access time in LAYOUTCOMMIT: >>>>> >>>>> >>>>> The loca_time_modify and loca_time_access If >>> LAYOUTCOMMIT >>>>> is only for writes, then why update access time? >>>>> fields >>>>> allow the client to suggest times it would like the metadata >>>>> server to set. The metadata server may use these time values >>> or >>>>> it may use the time of the LAYOUTCOMMIT operation to set >>>>> these >>>>> time values. If the metadata server uses the client provided >>>>> times, it should ensure time does not flow backwards. If the >>>>> client wants to force the metadata server to set an exact >>> time, >>>>> the client should use a SETATTR operation in a compound right >>>>> after LAYOUTCOMMIT. See >>> for >>>>> more details. If the new client desires the resultant mtime >>> or >>>>> atime, it should construct the COMPOUND so that a GETATTR >>>>> follows the LAYOUTCOMMIT. >>>>> >>>>> >>>>> The issue of loca_access_time was discussed at the pnfs review but >>> as >>>>> I understand things, there was no resolution that got universal >>>>> approval. The simplest thing, which I'm going to propose, if >>>>> nobody >>>>> has a better idea, is simply to get of rid loca_access_time. >>>> I object to doing that. >>> OK, but right now, we have a situation in LAYOUTCOMMIT is >>> discussed in >>> several dozen places, and most them implicitly give the impression >>> and >>> many of them explicitly (including the description of LAYOUTCOMMIT >>> itself) say that this is to be used when writing. That seems to be >>> inconsistent with having access time be a field in that and that >>> is the >>> issue that is raised in the , and that we have to address very >>> soon. >>> >>>> Since the MDS does intercept the I/Os going to the DSs >>> loca_access_time >>>> will be useful to the MD server, otherwise, if it supports atime >>>> (and is configured to track it), it will be forced to get the atime >>>> from all the file's DSs which can have a significant hit on >>> performance. >>> >>> Asking the clients to communicate with the MDS to propagate this will >>> also have a performance cost. It is true that the client would >>> have to >>> update only a single MDS, but if this is within the control >>> protocol, we >>> have opportunities for extensive batching of updates to multiple >>> files >>> to be transferred at the same time, so it is not clear to me that >>> making >>> the client do this is a net win. >>> >>>> Note that unlike an explicit SETATTR this value is basically a hint >>> and >>>> the server does not have to respect it. >>>> >>>> Also, I would like the spec to be clear about allowing LAYOUTCOMMIT >>>> for reads as this is still needed for the objects layout type for >>> reporting >>>> read errors. >>> This is not a case in which the spec is unclear and you can simply >>> clarify it allowing LAYOUTCOMMIT on read. It seems to me that you >>> are >>> asking for a fundamentally different treatment of LAYOUTCOMMIT >>> making it >>> >>> something that can/should/must (depending on what?) be used for >>> various >>> types of layouts under various conditions. That is very different >>> from >>> what is there now and I don't see any way that that level of >>> rewriting >>> can be done in time to get it into draft-16. >>> >>> >>> >>> -----Original Message----- >>> From: Benny Halevy [mailto:bhalevy@panasas.com] >>> Sent: Sunday, November 04, 2007 2:00 AM >>> To: Noveck, Dave >>> Cc: nfsv4@ietf.org >>> Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related >>> [[Comment]] sections >>> >>> >>> On Nov. 02, 2007, 20:49 +0200, "Noveck, Dave" >>> >>> wrote: >>>> I'm trying to get rid of many [[Comment]] sections and there are a >>>> few discussed below that I'd like to run by people. Let me know >>>> right away if you have an issue with any of the proposed >>>> resolutions. >>>> >>>> The first concerns the possibility which might exist for a file >>>> layout type to have a COMPOUND that contains some ops addressing >>>> the server as a metadata server and others as a data server. I >>>> think we should disallow this. >>>> >>> >>> >>>> >>>> It is not allowed for a single COMPOUND to contain operations >>>> acting on both individual personalities, although an COMPOUND >>>> pertaining to a single individual personality may contain >>>> housekeeping operation which affect both personalities. >>>> >>> This makes sense to me. >>> >>> >>> >>>> The next item relates to stateids and IO mode validations: >>>> >>>>
>>>> >>>> Open and deny mode validation MUST be performed against >>>> the open and deny mode(s) held by the data servers. When >>>> access is reduced or a deny mode made more restrictive >>>> (because of CLOSE or DOWNGRADE) the data server MUST >>>> prevent any I/Os that would be denied if performed on the >>>> metadata server. Conversely, when access is expanded, >>>> the data server MUST NOT reject a request because of >>>> open or deny issues without making sure that the open >>>> mode upgrade or deny mode relaxation is not in progress. >>>> >>>> It seems like the recent (June/July 2007) >>>> stateid.seqid discussion might modify this; >>>> a client might send a new state.seqid, that tells the data server >>>> it's seqid is out of date; the data server might return >>>> NFS4ERR_DELAY. >>>> >>>> >>>> >>>>
>>>> >>>> In addition to the cref section there seems to me to be confusion >>>> in the other parts of this and adjoining sections. The big issue >>>> is that there is discussion of getting stateid seqids right but >>>> that seems to me pointless complexity for the data server. Given >>>> parallel open the general pattern will be to use seqid=0 and only >>>> use non-zero seqid for a few special operation like OPEN_DOWNGRADE >>>> and CLOSE, none of which is going to be sent to the data server. >>>> >>>> So I'm proposing that the stateids for the data server always have >>>> seqid as zero and you get BAD_STATEID if not. >>> I thought that the client should just use the most recent stateid >>> returned >>> to it by the MDS, as per 14.10.1: >>> "When the client issues I/O to a data server, the stateid used >>> must be >>> one previously returned by the metadata server. Permitted stateids >>> include an open stateid (the stateid field of data type OPEN4resok as >>> returned by OPEN), a delegation stateid (the stateid field of data >>> types >>> open_read_delegation4 and open_write_delegation4 as returned by >>> OPEN or >>> WANT_DELEGATION, or as sent by CB_PUSH_DELEG), or a stateid >>> returned by >>> the LOCK or LOCKU operations." >>> >>>> Another thing that is wrong about this section is the discussion of >>>> deny modes. Deny modes have their effect at open time, and, unless >>>> we have IO's with special stateids (which I believe are not allowed) >>>> do not affect IO's. >>> Right >>> >>>> Also, "without making sure that the open mode upgrade or deny mode >>>> relaxation is not in progress" seems flat-out wrong. You can never >>>> be assured that it is not in progress when you actually do the >>>> rejection. >>>> If you check that it is not an a given instant and the proceed to >>>> do the rejection, it might be in progress when you actually do the >>>> rejection. All you should check is that it hasn't previously been >>>> made allowable. >>>> >>>> We have the following issue with access time in LAYOUTCOMMIT: >>>> >>>> >>>> The loca_time_modify and loca_time_access If >>>> LAYOUTCOMMIT >>>> is only for writes, then why update access time? fields >>>> allow the client to suggest times it would like the metadata >>>> server to set. The metadata server may use these time >>>> values or >>>> it may use the time of the LAYOUTCOMMIT operation to set these >>>> time values. If the metadata server uses the client provided >>>> times, it should ensure time does not flow backwards. If the >>>> client wants to force the metadata server to set an exact >>>> time, >>>> the client should use a SETATTR operation in a compound right >>>> after LAYOUTCOMMIT. See >>>> for >>>> more details. If the new client desires the resultant >>>> mtime or >>>> atime, it should construct the COMPOUND so that a GETATTR >>>> follows the LAYOUTCOMMIT. >>>> >>>> >>>> The issue of loca_access_time was discussed at the pnfs review >>>> but as >>>> I understand things, there was no resolution that got universal >>>> approval. The simplest thing, which I'm going to propose, if nobody >>>> has a better idea, is simply to get of rid loca_access_time. >>> I object to doing that. >>> Since the MDS does intercept the I/Os going to the DSs >>> loca_access_time >>> will be useful to the MD server, otherwise, if it supports atime >>> (and is configured to track it), it will be forced to get the atime >>> from all the file's DSs which can have a significant hit on >>> performance. >>> Note that unlike an explicit SETATTR this value is basically a >>> hint and >>> the server does not have to respect it. >>> >>> Also, I would like the spec to be clear about allowing LAYOUTCOMMIT >>> for reads as this is still needed for the objects layout type for >>> reporting >>> read errors. >>> >>>> Also we have the following inconsistent paragraphs: >>>> >>>> >>>> When lr_returntype is LAYOUTRETURN4_FILE, the layout being >>>> returned may be a subdivision of a layout previously obtained >>>> with LAYOUTGET. The layout being returned may also be a >>>> subset >>>> or superset of a layout specified by CB_LAYOUTRECALL. >>>> However, >>>> if it is a subset, the recall is not complete until the full >>>> recalled scope has been returned. Recalled scope refers to >>>> the >>>> octet range in the case of LAYOUTRETURN4_FILE, use of >>>> LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. It >>>> is also permissible, and no error should result, for a >>>> client to >>>> return a octet range covering a layout it does not hold. >>>> If the >>>> lrf_length is all 1s, the layout covers the range from >>>> lrf_offset to EOF. >>>> >>>> >>>> And, >>>> >>>> >>>> If the layout identified in the arguments does not exist, the >>>> error >>>> NFS4ERR_BADLAYOUT is returned. If a layout exists, but the >>> iomode >>>> does not match, NFS4ERR_BADIOMODE is returned. >>>> >>>> This error >>>> return description does not align with the statement above that >>>> the client should not receive an error when it returns a layout >>>> that it does not hold. >>>> >>>> >>>> >>>> It appears to me that the intent of the first paragraph cited was to >>>> simplify the job of the client, particularly in those cases (like >>>> the >>>> file layout type) where layouts are simple so that it can avoid >>> detailed >>>> logic to keep precise track of the octet ranges for which it has a >>>> layout. >>>> On the other hand, having the server be unable to report cases in >>> which >>>> a the client has lost its mind is troublesome. Here's my suggested >>>> resolution. >>>> >>>> >>>> When lr_returntype is LAYOUTRETURN4_FILE, the layout being >>>> returned may be a subdivision of a layout previously obtained >>>> with LAYOUTGET. The layout being returned may also be a >>>> subset >>>> or superset of a layout specified by CB_LAYOUTRECALL. >>>> However, >>>> if it is a subset, the recall is not complete until the full >>>> recalled scope has been returned. Recalled scope refers to >>>> the >>>> octet range in the case of LAYOUTRETURN4_FILE, use of >>>> LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. It >>>> is also permissible, and no error should result, for a >>>> client to >>>> return an octet range covering a layout it does not currently >>>> hold, >>>> as long as it, at some time held a layout for some octet range >>> of >>>> file in question. If the lrf_length is all 1s, the layout >>>> covers >>>> the range from lrf_offset to the last octet for which the >>>> client >>>> actually holds a layout. >>>> >>>> >>>> And, >>>> >>>> >>>> If it determinable that layout identified in the argument is >>> such >>>> that the client could never have possessed a layout for that >>> file >>>> (of any octet range) NFS4ERR_BADLAYOUT should be returned. >>>> If a >>>> layout exists, but the iomode does not match, >>>> NFS4ERR_BADIOMODE >>>> is returned. >>>> >>> I'm OK with that. >> >> -- >> Benny Halevy >> Software Architect >> Tel/Fax: +972-3-647-8340 >> Mobile: +972-54-802-8340 >> US: +1-412-203-3187 >> bhalevy@panasas.com >> >> Panasas, Inc. >> Leader in Parallel Storage >> www.panasas.com >> >> _______________________________________________ >> 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 Wed Nov 07 14:13: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 1IpqLa-0004NI-L7; Wed, 07 Nov 2007 14:13:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqLZ-0004N9-Gs for nfsv4@ietf.org; Wed, 07 Nov 2007 14:13:53 -0500 Received: from web38103.mail.mud.yahoo.com ([209.191.124.130]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpqLZ-0004kb-2V for nfsv4@ietf.org; Wed, 07 Nov 2007 14:13:53 -0500 Received: (qmail 46537 invoked by uid 60001); 7 Nov 2007 19:13:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=upRtJ76fXjZFnhaSb6VmfF4zsskabs4MpRCETdG69TvVEm2DF02KGkO6W3XOw+oOvHygrMBFPBSF8MF1BvxUik0fROd/SwT5MFUUDFztSgSDjNpxakOnetPr9q3Any+9ouQOiNulZ1KOOP3nh2YL64G2EC+VXcwvav8KZ7hT1+U=; X-YMail-OSG: QTbEWTcVM1njexd0CDkVkICcQvC3Gj4x72r.QJehgRVyQNMNUBZucn9WSQrlr2JVAt69SA-- Received: from [198.95.226.230] by web38103.mail.mud.yahoo.com via HTTP; Wed, 07 Nov 2007 11:13:52 PST Date: Wed, 7 Nov 2007 11:13:52 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] Re: should we allow LAYOUTCOMMIT for reads To: Benny Halevy , Spencer Shepler In-Reply-To: <47320BEC.2010908@panasas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <309403.46319.qm@web38103.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "Noveck, Dave" , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com 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 Nov. 07, 2007, 20:40 +0200, Spencer Shepler > wrote: > > If the only purpose of the access time field in layoutcommit is to > > allow the client the ability to update it (no release of > allocations > > or other side -effects), wouldn't SETATTR be sufficient for the > client? > > Or is there concern about appropriate access in setting that > attribute > > where a layout based update of access time would be better? > > explicit setattr won't work the same way if multiple clients are > reading the file concurrently as it may set the access time > backwards. enum time_how4 { SET_TO_SERVER_TIME4 = 0, SET_TO_CLIENT_TIME4 = 1 }; settime4 union settime4 switch (time_how4 set_it) { case SET_TO_CLIENT_TIME4: nfstime4 time; default: void; }; The client can set set_it to SET_TO_SERVER_TIME4 when it issues the SETATTR. As I recall saying in the pNFS review, LAYOUTCOMMIT seems to be replicating functionality we already have. > The intention of the LAYOUTCOMMIT hint was to only set the > access_time > on the file if the client's reported access_time is later than the > current access_time (and not in the future in which case the current > time > should be used) That seems over engineered. Accurate access_time has never been something NFS (and probably every other networked file system) could guarantee. > We have customers that demand atime support so I would say that What precisely are they demanding? That every read() from the client's cache update the atime? I get that all the time from customers and QA engineers, and I tell them they can use direct I/O to the server if that's what they think they need. And I would tell the customer that perfectly accurate atime is something that won't be provided with pNFS. We eliminated GETATTR from the set of operations a file-based data server can support for a reason. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 14:27: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 1IpqYK-0001zm-6j; Wed, 07 Nov 2007 14:27:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqYI-0001wo-J1 for nfsv4@ietf.org; Wed, 07 Nov 2007 14:27:02 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpqYI-0005Ps-6I for nfsv4@ietf.org; Wed, 07 Nov 2007 14:27:02 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA7JR1mc011568 for ; Wed, 7 Nov 2007 19:27:01 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR500M01HF3EQ00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 07 Nov 2007 12:27:01 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-138-155.dsl.austtx.sbcglobal.net [71.145.138.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR500F28I0ZZND0@mail-amer.sun.com> for nfsv4@ietf.org; Wed, 07 Nov 2007 12:27:00 -0700 (MST) Date: Wed, 07 Nov 2007 13:27:29 -0600 From: Spencer Shepler Subject: Re: [nfsv4] PUTFH+SECINFO_NO_NAME+OPEN(fh) issue In-reply-to: To: NFSv4 Message-id: <918404C9-8863-4354-A781-8AEDA2744735@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 References: X-Spam-Score: -1.0 (-) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Nov 7, 2007, at 9:58 AM, Noveck, Dave wrote: > > So an alternative that would address this but is less > disruptive than changing the XDR definition of SECINFO_NO_NAME. > is to specify that SECINFO_NO_NAME consume the current fh. > That is, if there is a saved fh, that becomes the current fh, > while if there isn't, the COMPOUND has no cfh after the > SECINFO_NO_NAME. I assert that would not be disruptive since > any compound that would be disrupted by that change is one > that uses the cfh after SECINFO_NO_NAME, i.e. is one that has > exactly the problem we are trying to address. Given that it is the PUTFH/RESTOREFH that is to receive the WRONGSEC error: -- 2.6.3.1.7. Put Filehandle Operation + Anything Else "Anything Else" includes OPEN by filehandle. The security policy enforcement applies to the filehandle specified in the put filehandle operation. Therefore PUTFH must return NFS4ERR_WRONGSEC in case of security tuple on the part of the mismatch. -- I would amend your suggestion slightly such that a saved filehandle is not consumed and therefore the SECINFO_NO_NAME leaves the current filehandle in an "undefined" state similar to if no PUTFH had been done. This way the client would need to construct the COMPOUND as: PUTFH, SECINFO_NO_NAME, PUTFH, OPEN(by-FH) and therefore the second PUTFH would receive the WRONGSEC error if appropriate. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 14:30: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 1IpqbW-0005Ne-O5; Wed, 07 Nov 2007 14:30:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqbV-0005Ly-Cx for nfsv4@ietf.org; Wed, 07 Nov 2007 14:30:21 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpqbR-0006C4-TY for nfsv4@ietf.org; Wed, 07 Nov 2007 14:30:21 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA7JUH2r013189 for ; Wed, 7 Nov 2007 19:30:17 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR500H01GM74O00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 07 Nov 2007 12:30:17 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-138-155.dsl.austtx.sbcglobal.net [71.145.138.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR500DI3I66B3B0@mail-amer.sun.com> for nfsv4@ietf.org; Wed, 07 Nov 2007 12:30:06 -0700 (MST) Date: Wed, 07 Nov 2007 13:30:35 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Re: should we allow LAYOUTCOMMIT for reads In-reply-to: <309403.46319.qm@web38103.mail.mud.yahoo.com> To: NFSv4 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: <309403.46319.qm@web38103.mail.mud.yahoo.com> X-Spam-Score: -1.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 Nov 7, 2007, at 1:13 PM, Mike Eisler wrote: > > --- Benny Halevy wrote: > >> On Nov. 07, 2007, 20:40 +0200, Spencer Shepler >> wrote: >>> If the only purpose of the access time field in layoutcommit is to >>> allow the client the ability to update it (no release of >> allocations >>> or other side -effects), wouldn't SETATTR be sufficient for the >> client? >>> Or is there concern about appropriate access in setting that >> attribute >>> where a layout based update of access time would be better? >> >> explicit setattr won't work the same way if multiple clients are >> reading the file concurrently as it may set the access time >> backwards. > > > enum time_how4 { > SET_TO_SERVER_TIME4 = 0, > SET_TO_CLIENT_TIME4 = 1 > }; > > settime4 > > union settime4 switch (time_how4 set_it) { > case SET_TO_CLIENT_TIME4: > nfstime4 time; > default: > void; > }; > > The client can set set_it to SET_TO_SERVER_TIME4 when > it issues the SETATTR. > > As I recall saying in the pNFS review, LAYOUTCOMMIT seems to > be replicating functionality we already have. The client may also use NVERIFY if there is a specific value that it desires to compare against. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 14:38: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 1IpqjD-00060W-Dy; Wed, 07 Nov 2007 14:38:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqjB-0005va-M6 for nfsv4@ietf.org; Wed, 07 Nov 2007 14:38:17 -0500 Received: from web38114.mail.mud.yahoo.com ([209.191.124.141]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ipqj8-0006Wz-Av for nfsv4@ietf.org; Wed, 07 Nov 2007 14:38:17 -0500 Received: (qmail 62328 invoked by uid 60001); 7 Nov 2007 19:38:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=onqL51Kx9JUd2nDxOcvGuK+ifSBSEw5XD39Y2aLJJ1GYkOjDAciuAciGz+WjaYkYVta3uCxTDY+J+hKEm9/dT5r8PqfruJ6d1567pPKnm4YHrZNstK/7Pkbzgq3NuezZIUTr46GpdEiqTlFa0PjvEmROb0wkI4xscfoRXE9NHGs=; X-YMail-OSG: reFLwrQVM1lvM2Jo2PUerazE6jSKur_a1dynxv2.lnJtdyvsaIYwOEQYq6YgSbMOcXTWELjx.A-- Received: from [198.95.226.230] by web38114.mail.mud.yahoo.com via HTTP; Wed, 07 Nov 2007 11:38:13 PST Date: Wed, 7 Nov 2007 11:38:13 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] PUTFH+SECINFO_NO_NAME+OPEN(fh) issue To: Spencer Shepler , NFSv4 In-Reply-To: <918404C9-8863-4354-A781-8AEDA2744735@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <807461.62320.qm@web38114.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Spencer Shepler wrote: > I would amend your suggestion slightly such that a saved > filehandle is not consumed and therefore the SECINFO_NO_NAME > leaves the current filehandle in an "undefined" state similar > to if no PUTFH had been done. I do like the idea that the use of SECINFO* causes the current filehandle to be cleared. This completely, simply, and unambiguously solves the problem Jeff raised. I too would rather the server not use the saved filehandle when the current filehandle is cleared by SECINFO*. While this changes the implementation of current and saved filehandles on the server from a simple stack to two separate registers, that's complexity tradeoff that is easy to accept. > > This way the client would need to construct the > COMPOUND as: > PUTFH, SECINFO_NO_NAME, PUTFH, OPEN(by-FH) > > and therefore the second PUTFH would receive > the WRONGSEC error if appropriate. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 14:40: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 1IpqlG-0008Cj-0g; Wed, 07 Nov 2007 14:40:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqlF-0008CJ-0P for nfsv4@ietf.org; Wed, 07 Nov 2007 14:40:25 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpqlE-00060s-M7 for nfsv4@ietf.org; Wed, 07 Nov 2007 14:40:24 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA7JeNWX028998 for ; Wed, 7 Nov 2007 19:40:23 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR500M01HF3EQ00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 07 Nov 2007 12:40:23 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-138-155.dsl.austtx.sbcglobal.net [71.145.138.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR500FAWIJHZND0@mail-amer.sun.com> for nfsv4@ietf.org; Wed, 07 Nov 2007 12:40:05 -0700 (MST) Date: Wed, 07 Nov 2007 13:40:35 -0600 From: Spencer Shepler To: NFSv4 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: 7aefe408d50e9c7c47615841cb314bed Subject: [nfsv4] Call for agenda items for Vancouver 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 Please let me know what and how long you would like for agenda items for Vancouver IETF meeting. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 14:47: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 1IpqsB-0007Ii-6w; Wed, 07 Nov 2007 14:47:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqsA-0007IY-NY for nfsv4@ietf.org; Wed, 07 Nov 2007 14:47:34 -0500 Received: from web38103.mail.mud.yahoo.com ([209.191.124.130]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ipqs6-0006sW-JL for nfsv4@ietf.org; Wed, 07 Nov 2007 14:47:34 -0500 Received: (qmail 59790 invoked by uid 60001); 7 Nov 2007 19:47:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=57T/jat4Qj5D1pEqo2gAxEBoYJfhuxey4tSWtbwKSjuctgnQvUZLrugRzjh4g7BJB8VOi+AmUgxLL5XQMmIYt/9G+uQYdIXzip8Es6NPi60r17i+9aF5mqOJXpuiZ4TfQLD+oB3gMccMXrGtnzsGfpytaVOsQWSsIlNLn16kgY4=; X-YMail-OSG: FaNf7D0VM1nkjCDOi9b7xsIx62pqUxIjapUXHcTck5w_dfF5mu2pXpLe2ThQy3.6oNzgfnjFdA-- Received: from [198.95.226.230] by web38103.mail.mud.yahoo.com via HTTP; Wed, 07 Nov 2007 11:47:30 PST Date: Wed, 7 Nov 2007 11:47:30 -0800 (PST) From: Mike Eisler To: nfsv4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <155640.59579.qm@web38103.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [nfsv4] issue 164 : Can a replier send a reply on a connection other than the one the requester sent the request on? X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I think the answer should be no. I propose adding the following text to the specification: When sending a reply, the replier MUST send the reply to the same full network address (e.g. if using an IP-based transport, the source port of the requester is part of the full network address) that the requester issued the request from. If using a connection-oriented transport, replies MUST be send on the same connection the request was sent from. If a connection is dropped after the replier receives the request but before the replier sends the reply, and if a connection is established with the same source and destination full network address as the dropped connection, then the replier MUST NOT send the reply until the client retries the request. The reason for this prohibition is that the client MAY retry a request over a different connection that is associated with the session. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 14:54: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 1IpqyZ-0007E0-Vx; Wed, 07 Nov 2007 14:54:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqyY-0007D6-PB for nfsv4@ietf.org; Wed, 07 Nov 2007 14:54:10 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpqyY-0006Sr-CY for nfsv4@ietf.org; Wed, 07 Nov 2007 14:54:10 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA7Js9Vb006387 for ; Wed, 7 Nov 2007 19:54:09 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR500201J4HLG00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 07 Nov 2007 12:54:09 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-138-155.dsl.austtx.sbcglobal.net [71.145.138.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR500FM2J9AZND0@mail-amer.sun.com> for nfsv4@ietf.org; Wed, 07 Nov 2007 12:53:35 -0700 (MST) Date: Wed, 07 Nov 2007 13:54:04 -0600 From: Spencer Shepler Subject: Re: [nfsv4] issue 164 : Can a replier send a reply on a connection other than the one the requester sent the request on? In-reply-to: <155640.59579.qm@web38103.mail.mud.yahoo.com> To: NFSv4 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: <155640.59579.qm@web38103.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Agreed. On Nov 7, 2007, at 1:47 PM, Mike Eisler wrote: > I think the answer should be no. I propose adding the following > text to the specification: > > > When sending a reply, the replier MUST send the reply to > the same full network address (e.g. if using an IP-based > transport, the source port of the requester is part of > the full network address) that the requester issued the > request from. If using a connection-oriented transport, > replies MUST be send on the same connection the request > was sent from. If a connection is dropped after the > replier receives the request but before the replier > sends the reply, and if a connection is established > with the same source and destination full network > address as the dropped connection, then the replier > MUST NOT send the reply until the client retries the > request. The reason for this prohibition is that the > client MAY retry a request over a different connection > that is associated with the session. > > > > > > > _______________________________________________ > 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 Nov 07 15:00: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 1Ipr4f-0007VG-9j; Wed, 07 Nov 2007 15:00:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipr4d-0007MH-Fl for nfsv4@ietf.org; Wed, 07 Nov 2007 15:00:27 -0500 Received: from web38110.mail.mud.yahoo.com ([209.191.124.137]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ipr4c-0006kj-W7 for nfsv4@ietf.org; Wed, 07 Nov 2007 15:00:27 -0500 Received: (qmail 72170 invoked by uid 60001); 7 Nov 2007 20:00:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=6M9S3C9QWjHMkz69xWeacievXR7p4mqgXarCdLe+ZsSj2uE4iwGsYILWmpoLTZgUGCou/8NSno0nXh0v53o5hL9+IaQhBME2x+20S9hw7ya3dUNsg/HfmIOFt9tgbiRNQhGl1K9hQL11+L9vkclmEAFURMgkRPa6Q3/EFkuOKCo=; X-YMail-OSG: iGvqejkVM1mSYnIf9zQk5Kmut0XV.VT_0JQQGJSoCQknzzCHChfe0xzwQ.diKukE0_rV5TdjIObkeCLlP5EmdFydsDkwCw.jdWcvZh.RebXnpjHVjj0- Received: from [198.95.226.230] by web38110.mail.mud.yahoo.com via HTTP; Wed, 07 Nov 2007 12:00:24 PST Date: Wed, 7 Nov 2007 12:00:24 -0800 (PST) From: Mike Eisler To: nfsv4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <438577.47550.qm@web38110.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [nfsv4] Issue 165: should we adopt a convention for so_major_ids ? X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue165 Benny wrote for this issue: I think that the rfc should recommend a naming convention that will help to prevent so_major_id collisions, especially when using servers from different vendors. For example, iscsi (rfc3720) specifies iqn and eui formats, the former requires a registered domain name, the latter a IEEE EUI-64 world-wide unique name ----------------------------- So three questions: - do we want to RECOMMEND a format for so_major_id? - do we want to mandate a format for so_major_id? - should the mandated or recommended format be a DNS FQDN? My answers are: no, yes, yes. Discussion welcome. If no consensus observed, then the issue will be deferred (to NFSv4.2). _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 15:17: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 1IprLB-0004iW-Uh; Wed, 07 Nov 2007 15:17:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IprL9-0004Vj-SG for nfsv4@ietf.org; Wed, 07 Nov 2007 15:17:31 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IprKp-0007dI-T2 for nfsv4@ietf.org; Wed, 07 Nov 2007 15:17:31 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IprKo-0000e3-JW; Wed, 07 Nov 2007 15:17:10 -0500 Date: Wed, 7 Nov 2007 15:17:10 -0500 To: "Noveck, Dave" Subject: Re: [nfsv4] PUTFH+SECINFO_NO_NAME+OPEN(fh) issue Message-ID: <20071107201710.GB29728@fieldses.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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, Nov 07, 2007 at 10:58:34AM -0500, Noveck, Dave wrote: > It isn't clear how to fix this. Two proposals that have > not seemed satisfactory are: > > Mike has proposed that we legislate this case out of > existence and say that the OPEN(fh) (and really > any operation) can return UNSAFE_COMPOUND or a new > error BAD_COMPOUND. > > I've suggested allowing all those ops to return > WRONGSEC. A minor digression: Is it going to be awkward to reconcile the limits on which operations can return WRONGSEC with the ability for administrators to change security requirements at any moment? If somebody sends me a PUTFH, GETATTR, OPEN, and the administrator asks to tighten security on the export just as I'm hanging out in GETATTR waiting for the #%*#$^! ldap server to tell me who uid 2815 is, I might be tempted to return WRONGSEC on the OPEN when I get to it. I dunno. Hm. A paragraph here seems to have been the victim of some sort of minor editing trainwreck: "... Therefore PUTFH must return NFS4ERR_WRONGSEC in case of security tuple on the part of the mismatch. This avoids the complexity adding NFS4ERR_WRONGSEC as an allowable error to every other operation." I think what was intended was something like?: "... Therefore PUTFH must return NFS4ERR_WRONGSEC in the case of a security triple mismatch. This avoids the complexity of adding NFS4ERR_WRONGSEC as an allowable error to every other operation." --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 15:32: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 1IprZX-0001ek-5P; Wed, 07 Nov 2007 15:32:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IprZV-0001eY-Jx for nfsv4@ietf.org; Wed, 07 Nov 2007 15:32:21 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IprZV-0008IC-2Y for nfsv4@ietf.org; Wed, 07 Nov 2007 15:32:21 -0500 X-IronPort-AV: E=Sophos;i="4.21,386,1188802800"; d="scan'208";a="120402004" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 07 Nov 2007 12:31:50 -0800 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 lA7KVn1F022787; Wed, 7 Nov 2007 12:31:50 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 12:31:50 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 12:31:49 -0800 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] PUTFH+SECINFO_NO_NAME+OPEN(fh) issue Date: Wed, 7 Nov 2007 15:31:48 -0500 Message-ID: In-Reply-To: <20071107201710.GB29728@fieldses.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] PUTFH+SECINFO_NO_NAME+OPEN(fh) issue Thread-Index: Acghe1zdA0YFI5zzTCmofWvaaE725QAAKq7A From: "Noveck, Dave" To: "J. Bruce Fields" X-OriginalArrivalTime: 07 Nov 2007 20:31:49.0378 (UTC) FILETIME=[392A9620:01C8217D] X-Spam-Score: -4.0 (----) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 somebody sends me a PUTFH, GETATTR, OPEN, and the administrator asks > to tighten security on the export just as I'm hanging out in GETATTR > waiting for the #%*#$^! ldap server to tell me who uid 2815 is, I might > be tempted to return WRONGSEC on the OPEN when I get to it. I dunno. I think the spec is telling you to seriously resist the temptation. Of course, if Mephistopheles promises you unimaginable wealth just for violating the v4.1 spec, you'll have to make your own decision. Seriously, I think the logic of the spec is that the implementation, at the point of PUTFH or crossing into a part of the namespace with new security restrictions, checks at that time whether your current security flavor is acceptable. From a performance point of view=20 doing anything else is a problem anyway. I know there are people whose concern for security is such that=20 that would not be acceptable. I think if you are dealing with them,=20 you will have to return DELAY and when the PUTFH is done as part of the follow-up, give him WRONGSEC then. -----Original Message----- From: J. Bruce Fields [mailto:bfields@fieldses.org]=20 Sent: Wednesday, November 07, 2007 3:17 PM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: Re: [nfsv4] PUTFH+SECINFO_NO_NAME+OPEN(fh) issue On Wed, Nov 07, 2007 at 10:58:34AM -0500, Noveck, Dave wrote: > It isn't clear how to fix this. Two proposals that have=20 > not seemed satisfactory are: >=20 > Mike has proposed that we legislate this case out of > existence and say that the OPEN(fh) (and really > any operation) can return UNSAFE_COMPOUND or a new=20 > error BAD_COMPOUND. >=20 > I've suggested allowing all those ops to return=20 > WRONGSEC. A minor digression: Is it going to be awkward to reconcile the limits on which operations can return WRONGSEC with the ability for administrators to change security requirements at any moment? If somebody sends me a PUTFH, GETATTR, OPEN, and the administrator asks to tighten security on the export just as I'm hanging out in GETATTR waiting for the #%*#$^! ldap server to tell me who uid 2815 is, I might be tempted to return WRONGSEC on the OPEN when I get to it. I dunno. Hm. A paragraph here seems to have been the victim of some sort of minor editing trainwreck: "... Therefore PUTFH must return NFS4ERR_WRONGSEC in case of security tuple on the part of the mismatch. This avoids the complexity adding NFS4ERR_WRONGSEC as an allowable error to every other operation." I think what was intended was something like?: "... Therefore PUTFH must return NFS4ERR_WRONGSEC in the case of a security triple mismatch. This avoids the complexity of adding NFS4ERR_WRONGSEC as an allowable error to every other operation." --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 15:44: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 1IprlK-0005Me-BU; Wed, 07 Nov 2007 15:44:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IprlJ-0005LA-QH for nfsv4@ietf.org; Wed, 07 Nov 2007 15:44:33 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IprlG-00013U-Jm for nfsv4@ietf.org; Wed, 07 Nov 2007 15:44:33 -0500 X-IronPort-AV: E=Sophos;i="4.21,386,1188802800"; d="scan'208";a="120405869" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 07 Nov 2007 12:44:28 -0800 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 lA7KiSuR015164; Wed, 7 Nov 2007 12:44:28 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 12:44:28 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 12:44:27 -0800 Received: from tmt.netapp.com ([10.30.32.39]) by exnane01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Nov 2007 15:44:26 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 07 Nov 2007 15:44:33 -0500 To: email2mre-ietf@yahoo.com From: "Talpey, Thomas" Subject: Re: [nfsv4] issue 164 : Can a replier send a reply on a connection other than the one the requester sent the request on? In-Reply-To: <155640.59579.qm@web38103.mail.mud.yahoo.com> References: <155640.59579.qm@web38103.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: X-OriginalArrivalTime: 07 Nov 2007 20:44:26.0186 (UTC) FILETIME=[FC4252A0:01C8217E] X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 At 02:47 PM 11/7/2007, Mike Eisler wrote: >I think the answer should be no. I propose adding the following Definitely no. >text to the specification: > > > When sending a reply, the replier MUST send the reply to > the same full network address (e.g. if using an IP-based > transport, the source port of the requester is part of > the full network address) that the requester issued the > request from. If using a connection-oriented transport, > replies MUST be send on the same connection the request "sent" > was sent from. If a connection is dropped after the "received" > replier receives the request but before the replier > sends the reply, and if a connection is established > with the same source and destination full network > address as the dropped connection, then the replier > MUST NOT send the reply until the client retries the > request. The reason for this prohibition is that the > client MAY retry a request over a different connection > that is associated with the session. "than" (not "that"), but see comment: There's more in this than is covered in the requirement of those last two sentences. The issue is that the new test _requires_ the server to detect this, which is a problem. Yes, an unsolicited reply on the new connection breaks RPC semantics, blows the newly reallocated slot table, and may break the connection if it's over RDMA. But, it's a big reach to forbid it from happening altogether since it implies a merging of the RPC and transport layers. I think the language here needs to be SHOULD NOT, and it needs to be clear that the client SHOULD drop any such unsolicited reply. We could go so far as to recommend that the client disconnect and back off, if it should happen. The server clearly must never buffer an actual reply for sending when the client reconnects. Servers only speak when directly spoken to. Besides this is what the reply cache is all about. Tom. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 15:53: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 1Iprtz-0004wA-NB; Wed, 07 Nov 2007 15:53:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iprty-0004se-0Z for nfsv4@ietf.org; Wed, 07 Nov 2007 15:53:30 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iprtt-0001Nj-FO for nfsv4@ietf.org; Wed, 07 Nov 2007 15:53:29 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA7KrOBp007076 for ; Wed, 7 Nov 2007 20:53:24 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR500J01LGQM900@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 07 Nov 2007 13:53:24 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-138-155.dsl.austtx.sbcglobal.net [71.145.138.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR500K07M0YM000@mail-amer.sun.com>; Wed, 07 Nov 2007 13:53:22 -0700 (MST) Date: Wed, 07 Nov 2007 14:53:52 -0600 From: Spencer Shepler Subject: Re: [nfsv4] issue 164 : Can a replier send a reply on a connection other than the one the requester sent the request on? In-reply-to: To: "Talpey, Thomas" 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: <155640.59579.qm@web38103.mail.mud.yahoo.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Nov 7, 2007, at 2:44 PM, Talpey, Thomas wrote: > At 02:47 PM 11/7/2007, Mike Eisler wrote: >> I think the answer should be no. I propose adding the following > > Definitely no. > >> text to the specification: >> >> >> When sending a reply, the replier MUST send the reply to >> the same full network address (e.g. if using an IP-based >> transport, the source port of the requester is part of >> the full network address) that the requester issued the >> request from. If using a connection-oriented transport, >> replies MUST be send on the same connection the request > > "sent" > >> was sent from. If a connection is dropped after the > > "received" > >> replier receives the request but before the replier >> sends the reply, and if a connection is established >> with the same source and destination full network >> address as the dropped connection, then the replier >> MUST NOT send the reply until the client retries the >> request. The reason for this prohibition is that the >> client MAY retry a request over a different connection >> that is associated with the session. > > "than" (not "that"), but see comment: > > There's more in this than is covered in the requirement of > those last two sentences. The issue is that the new test > _requires_ the server to detect this, which is a problem. > Yes, an unsolicited reply on the new connection breaks > RPC semantics, blows the newly reallocated slot table, > and may break the connection if it's over RDMA. But, it's > a big reach to forbid it from happening altogether since it > implies a merging of the RPC and transport layers. > > I think the language here needs to be SHOULD NOT, and I agree with Mike's proposal in that it should be a "MUST NOT". Spencer > it needs to be clear that the client SHOULD drop any such > unsolicited reply. We could go so far as to recommend that > the client disconnect and back off, if it should happen. > > The server clearly must never buffer an actual reply for > sending when the client reconnects. Servers only speak > when directly spoken to. Besides this is what the reply > cache is all about. > > Tom. > > _______________________________________________ > 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 Nov 07 16:20: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 1IpsKS-0001RN-52; Wed, 07 Nov 2007 16:20:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpsKQ-0001Qz-NN for nfsv4@ietf.org; Wed, 07 Nov 2007 16:20:50 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpsKM-0002vV-6P for nfsv4@ietf.org; Wed, 07 Nov 2007 16:20:50 -0500 Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IpsKK-0004zL-2e; Wed, 07 Nov 2007 22:20:44 +0100 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 1IpsKJ-00009l-Fx; Wed, 07 Nov 2007 22:20:43 +0100 Received: from dh189.citi.umich.edu ([141.211.133.189]) by mail-mx6.uio.no with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IpsKJ-00009d-2b; Wed, 07 Nov 2007 22:20:43 +0100 Subject: Re: [nfsv4] issue 164 : Can a replier send a reply on a connection other than the one the requester sent the request on? From: Trond Myklebust To: "Talpey, Thomas" In-Reply-To: References: <155640.59579.qm@web38103.mail.mud.yahoo.com> Content-Type: text/plain Date: Wed, 07 Nov 2007 16:22:59 -0500 Message-Id: <1194470579.7504.38.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=0.1, required=12.0, autolearn=disabled, AWL=0.090) X-UiO-Scanned: 3BD916126F04C3ABC6111852F413239E093B1323 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 1 maxlevel 200 minaction 2 bait 0 mail/h: 335 total 4990490 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Wed, 2007-11-07 at 15:44 -0500, Talpey, Thomas wrote: > I think the language here needs to be SHOULD NOT, and > it needs to be clear that the client SHOULD drop any such > unsolicited reply. We could go so far as to recommend that > the client disconnect and back off, if it should happen. Why would backing off help? What scenario are we looking at where unsolicited replies might occur despite the MUST that Mike is proposing? Cheers Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 16:32:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpsVG-0003eI-73; Wed, 07 Nov 2007 16:32:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpsVF-0003eC-9f for nfsv4@ietf.org; Wed, 07 Nov 2007 16:32:01 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpsVE-0002po-U4 for nfsv4@ietf.org; Wed, 07 Nov 2007 16:32:01 -0500 X-IronPort-AV: E=Sophos;i="4.21,386,1188802800"; d="scan'208";a="120418896" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 07 Nov 2007 13:31:45 -0800 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 lA7LVj4S001667; Wed, 7 Nov 2007 13:31:45 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 13:31:43 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 13:31:43 -0800 Received: from tmt.netapp.com ([10.30.32.39]) by exnane01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Nov 2007 16:31:41 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 07 Nov 2007 16:31:18 -0500 To: Trond Myklebust From: "Talpey, Thomas" Subject: Re: [nfsv4] issue 164 : Can a replier send a reply on a connection other than the one the requester sent the request on? In-Reply-To: <1194470579.7504.38.camel@heimdal.trondhjem.org> References: <155640.59579.qm@web38103.mail.mud.yahoo.com> <1194470579.7504.38.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: X-OriginalArrivalTime: 07 Nov 2007 21:31:41.0342 (UTC) FILETIME=[9624CBE0:01C82185] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 At 04:22 PM 11/7/2007, Trond Myklebust wrote: > >On Wed, 2007-11-07 at 15:44 -0500, Talpey, Thomas wrote: > >> I think the language here needs to be SHOULD NOT, and >> it needs to be clear that the client SHOULD drop any such >> unsolicited reply. We could go so far as to recommend that >> the client disconnect and back off, if it should happen. > >Why would backing off help? What scenario are we looking at where >unsolicited replies might occur despite the MUST that Mike is proposing? It's only advisable in the SHOULD case, and then only if unsolicited replies are received. If server implementors are happy that this MUST can be implemented, then I'm fine with it. A similar requirement was in a version of my original sessions proposal, but it was removed after implementation experience. Most existing servers do not check the state of the socket before sending their reply, and they certainly don't monitor the connection while processing. Tom. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 16:36: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 1IpsZq-0005G4-7k; Wed, 07 Nov 2007 16:36:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpsZo-0005Fo-Tp for nfsv4@ietf.org; Wed, 07 Nov 2007 16:36:44 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpsZo-00031c-Ho for nfsv4@ietf.org; Wed, 07 Nov 2007 16:36:44 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id lA7LaTNP015816; Wed, 7 Nov 2007 16:36:29 -0500 Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [172.16.52.154]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id lA7LaSQN017510; Wed, 7 Nov 2007 16:36:28 -0500 Received: from [172.16.80.198] (IDENT:U2FsdGVkX1/p0W6R0JeJx5b5R4F6xuZIMALxeOtjt1E@nyday.boston.redhat.com [172.16.80.198]) by lacrosse.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id lA7LaSxQ021956; Wed, 7 Nov 2007 16:36:28 -0500 Message-ID: <47322FDB.1060806@redhat.com> Date: Wed, 07 Nov 2007 16:36:27 -0500 From: Peter Staubach User-Agent: Thunderbird 1.5.0.12 (X11/20071018) MIME-Version: 1.0 To: "Talpey, Thomas" Subject: Re: [nfsv4] issue 164 : Can a replier send a reply on a connection other than the one the requester sent the request on? References: <155640.59579.qm@web38103.mail.mud.yahoo.com> <1194470579.7504.38.camel@heimdal.trondhjem.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Talpey, Thomas wrote: > At 04:22 PM 11/7/2007, Trond Myklebust wrote: > >> On Wed, 2007-11-07 at 15:44 -0500, Talpey, Thomas wrote: >> >> >>> I think the language here needs to be SHOULD NOT, and >>> it needs to be clear that the client SHOULD drop any such >>> unsolicited reply. We could go so far as to recommend that >>> the client disconnect and back off, if it should happen. >>> >> Why would backing off help? What scenario are we looking at where >> unsolicited replies might occur despite the MUST that Mike is proposing? >> > > It's only advisable in the SHOULD case, and then only if unsolicited > replies are received. > > If server implementors are happy that this MUST can be implemented, > then I'm fine with it. A similar requirement was in a version of my original > sessions proposal, but it was removed after implementation experience. > Most existing servers do not check the state of the socket before > sending their reply, and they certainly don't monitor the connection > while processing. I am curious what, more precisely, the implementation experience was. The server should just send off the response and ignore any errors that come back from the transport that indicated that it couldn't send the response for any reason other than things like local memory shortage. Isn't the transport generally responsible for dropping any undeliverable data due to broken connections and such? Thanx... ps _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 07 19:15: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 1Ipv2x-00072I-Vi; Wed, 07 Nov 2007 19:14:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipv2w-000705-Bb for nfsv4@ietf.org; Wed, 07 Nov 2007 19:14:58 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipv2v-00009Z-RP for nfsv4@ietf.org; Wed, 07 Nov 2007 19:14:58 -0500 X-IronPort-AV: E=Sophos;i="4.21,387,1188802800"; d="scan'208";a="120457513" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 07 Nov 2007 16:14:55 -0800 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 lA80EsCo017355; Wed, 7 Nov 2007 16:14:54 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 16:14:54 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 16:14:54 -0800 Received: from tmt.netapp.com ([10.30.32.45]) by exnane01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 7 Nov 2007 19:14:52 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 07 Nov 2007 19:11:55 -0500 To: Peter Staubach From: "Talpey, Thomas" Subject: Re: [nfsv4] issue 164 : Can a replier send a reply on a connection other than the one the requester sent the request on? In-Reply-To: <47322FDB.1060806@redhat.com> References: <155640.59579.qm@web38103.mail.mud.yahoo.com> <1194470579.7504.38.camel@heimdal.trondhjem.org> <47322FDB.1060806@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: X-OriginalArrivalTime: 08 Nov 2007 00:14:52.0936 (UTC) FILETIME=[62637880:01C8219C] X-Spam-Score: -4.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 At 04:36 PM 11/7/2007, Peter Staubach wrote: >Talpey, Thomas wrote: >> At 04:22 PM 11/7/2007, Trond Myklebust wrote: >> If server implementors are happy that this MUST can be implemented, >> then I'm fine with it. A similar requirement was in a version of my original >> sessions proposal, but it was removed after implementation experience. >> Most existing servers do not check the state of the socket before >> sending their reply, and they certainly don't monitor the connection >> while processing. > >I am curious what, more precisely, the implementation experience was. >The server should just send off the response and ignore any errors >that come back from the transport that indicated that it couldn't >send the response for any reason other than things like local memory >shortage. Isn't the transport generally responsible for dropping >any undeliverable data due to broken connections and such? Sure. The problem isn't actually sending on a broken connection. That's the good case - the reply isn't going anywhere and there is no issue of misdirecting it. The issue is when there *is* a connection, but it's the wrong one. When implementing to sessions, the server implementations so far have all referenced the session from the in-progress request. This is very convenient, as the session contains all the server context needed to execute the request, including the reply cache, the RPC endpoint, and the clientid. The thing about the session is that it's an NFS layer object, which references an RPC object, which in turn contains the TCP connection. If that TCP connection changes, there's no existing API in most systems to signal that to NFS - all the upper layer can do is send and hopefully get an error. To fix this, either the local RPC has to change, or some kind of exposure of the socket, and a reference, needs to be taken. There were other issues in the early sessions spec related to this. You may recall it had channel objects, and a binding operation for connections. These ops basically "registered" the TCP socket with NFS. But this was hard for both implementations, and even harder for them to propagate state. So it was modified to what you see today. Changing the server requirement to a MUST is a good goal, and frankly I agree with it, in principle. But it will have implications. As a SHOULD, it is a strong recommendation, but implementations can still have some freedom to evolve to it. BTW, either way this is going to be a devilishly hard condition to test for. Maybe even harder than testing the reply cache. Tom. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From ArmandominervaBrewer@oyez.org Wed Nov 07 21:13:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpwtN-0004tN-CE; Wed, 07 Nov 2007 21:13:13 -0500 Received: from cpe-68-175-13-104.hvc.res.rr.com ([68.175.13.104] helo=maryelizabeth.hvc.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpwtM-0003rJ-TY; Wed, 07 Nov 2007 21:13:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host35281196.oyez.org (8.13.1/8.13.1) with SMTP id DRbjP3Rk57.679627.gG9.jE0.3712609077505 for ; Wed, 7 Nov 2007 21:12:37 +0500 Message-ID: From: "Tyrone Holland" To: Subject: Your life Date: Wed, 7 Nov 2007 21:12:37 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_FD83_01C821AC.E2E57840" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_FD83_01C821AC.E2E57840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_FD83_01C821AC.E2E57840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_FD83_01C821AC.E2E57840-- From nfsv4-bounces@ietf.org Thu Nov 08 02:24:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq1kk-00054l-L6; Thu, 08 Nov 2007 02:24:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq1kk-00054A-2Q for nfsv4@ietf.org; Thu, 08 Nov 2007 02:24:38 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq1kj-0003al-FL for nfsv4@ietf.org; Thu, 08 Nov 2007 02:24:37 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA87OaBV002693 for ; Thu, 8 Nov 2007 07:24:36 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR600801F6ZL500@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 08 Nov 2007 00:24:36 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR60069OF8SM840@mail-amer.sun.com> for nfsv4@ietf.org; Thu, 08 Nov 2007 00:24:29 -0700 (MST) Date: Thu, 08 Nov 2007 01:24:58 -0600 From: Spencer Shepler To: NFSv4 Message-id: <0D547683-ACE1-4CE1-A46C-6E7BC2B48F1F@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: -1.0 (-) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Subject: [nfsv4] deviceid4 => major/minor 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 discussed recently, there is a desire to allow for the separation of the deviceid stateid space such that a logical set of deviceids may be grouped and then managed or recalled without disruption to other groupings. The most straightforward modification, as suggested, is to change the current deviceid definition from: typedef uint64_t deviceid4; to: struct deviceid4 { uint64_t did_major; uint64_t did_minor; }; Along with this change the deviceid stateid space would change such that there is a unique deviceid stateid associated with each deviceid4.did_major used by the server. As a quick reminder: Deviceid stateids represent a delegation of the deviceid mapping to the client. Upon receipt of results from GETDEVICEINFO/GETDEVICELIST, the client holds a deviceid delegation for the returned mapping(s). When the mapping is no longer needed or is recalled by the server, the client will use DELEGRETURN to signify completion. Note that this requires a valid filehandle to be returned/updated by GETDEVICELIST/GETDEVICELIST. The server may recall the deviceid mappings with the CB_RECALL operation. If supported and the client desires, interest in notifications of changes in the deviceid mappings may be provided with the CB_NOTIFY operation. FREE_STATEID and TEST_STATEID may be used as with other stateid types. -- If there aren't any obvious flaws with this approach, I will make the changes to be included in the next update to the draft. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 03:44: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 1Iq2zz-00061k-5J; Thu, 08 Nov 2007 03:44:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq2zx-0005uG-Cg for nfsv4@ietf.org; Thu, 08 Nov 2007 03:44:25 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq2zw-0006CI-M2 for nfsv4@ietf.org; Thu, 08 Nov 2007 03:44:25 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA88iNoh016508 for ; Thu, 8 Nov 2007 08:44:23 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR600I01ITCAJ00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 08 Nov 2007 01:44:23 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-138-155.dsl.austtx.sbcglobal.net [71.145.138.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR6006CVIXWM840@mail-amer.sun.com> for nfsv4@ietf.org; Thu, 08 Nov 2007 01:44:21 -0700 (MST) Date: Thu, 08 Nov 2007 02:44:51 -0600 From: Spencer Shepler To: NFSv4 Message-id: <4624A550-302B-40A0-9430-6F38EB1249BD@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.5 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Subject: [nfsv4] Operations in NFSv4.1 (mandatory / optional) 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 the next I-D, a table will be added to summarize the operations in the context of being mandatory or optional. I have attached those tables to solicit any feedback prior to the next submission of the I-D. Spencer Operations: Operations +----------------------+-----+---------------------- +---------------+ | Operation | No. | Feature / | Defined in | | | | Disposition | | +----------------------+-----+---------------------- +---------------+ | ACCESS | 3 | MAND | Section 18.1 | | BACKCHANNEL_CTL | 40 | MAND | Section 18.33 | | BIND_CONN_TO_SESSION | 41 | MAND | Section 18.34 | | CLOSE | 4 | MAND | Section 18.2 | | COMMIT | 5 | MAND | Section 18.3 | | CREATE | 6 | MAND | Section 18.4 | | CREATE_SESSION | 43 | MAND | Section 18.36 | | DELEGPURGE | 7 | FDELG / MAND | Section 18.5 | | DELEGRETURN | 8 | FDELG, DDELG, pNFS / | Section 18.6 | | | | MAND | | | DESTROY_CLIENTID | 57 | MAND | Section 18.50 | | DESTROY_SESSION | 44 | MAND | Section 18.37 | | EXCHANGE_ID | 42 | MAND | Section 18.35 | | FREE_STATEID | 45 | MAND | Section 18.38 | | GETATTR | 9 | MAND | Section 18.7 | | GETDEVICEINFO | 47 | pNFS / MAND | Section 18.40 | | GETDEVICELIST | 48 | pNFS / OPT | Section 18.41 | | GETFH | 10 | MAND | Section 18.8 | | GET_DIR_DELEGATION | 46 | DDELG / MAND | Section 18.39 | | LAYOUTCOMMIT | 49 | pNFS / MAND | Section 18.42 | | LAYOUTGET | 50 | pNFS / MAND | Section 18.43 | | LAYOUTRETURN | 51 | pNFS / MAND | Section 18.44 | | LINK | 11 | OPT | Section 18.9 | | LOCK | 12 | MAND | Section 18.10 | | LOCKT | 13 | MAND | Section 18.11 | | LOCKU | 14 | MAND | Section 18.12 | | LOOKUP | 15 | MAND | Section 18.13 | | LOOKUPP | 16 | MAND | Section 18.14 | | NVERIFY | 17 | MAND | Section 18.15 | | OPEN | 18 | MAND | Section 18.16 | | OPENATTR | 19 | MAND | Section 18.17 | | OPEN_CONFIRM | 20 | MNI | N/ A | | OPEN_DOWNGRADE | 21 | MAND | Section 18.18 | | PUTFH | 22 | MAND | Section 18.19 | | PUTPUBFH | 23 | MAND | Section 18.20 | | PUTROOTFH | 24 | MAND | Section 18.21 | | READ | 25 | MAND | Section 18.22 | | READDIR | 26 | MAND | Section 18.23 | | READLINK | 27 | OPT | Section 18.24 | | RECLAIM_COMPLETE | 58 | MAND | Section 18.51 | | RELEASE_LOCKOWNER | 39 | MNI | N/ A | | REMOVE | 28 | MAND | Section 18.25 | | RENAME | 29 | MAND | Section 18.26 | | RENEW | 30 | MNI | N/ A | | RESTOREFH | 31 | MAND | Section 18.27 | | SAVEFH | 32 | MAND | Section 18.28 | | SECINFO | 33 | MAND | Section 18.29 | | SECINFO_NO_NAME | 52 | MAND | Section 18.45 | | SEQUENCE | 53 | MAND | Section 18.46 | | SETATTR | 34 | MAND | Section 18.30 | | SET_CLIENTID | 35 | MNI | N/ A | | SET_CLIENTID_CONFIRM | 35 | MNI | N/ A | | SET_SSV | 54 | MAND | Section 18.47 | | TEST_STATEID | 55 | MAND | Section 18.48 | | VERIFY | 37 | MAND | Section 18.31 | | WANT_DELEGATION | 56 | OPT | Section 18.49 | | WRITE | 38 | MAND | Section 18.32 | +----------------------+-----+---------------------- +---------------+ Callback Operations: Operations +-------------------------+-----+------------------- +---------------+ | Operation | No. | Feature / | Defined in | | | | Disposition | | +-------------------------+-----+------------------- +---------------+ | CB_GETATTR | 3 | FDELG / MAND | Section 20.1 | | CB_LAYOUTRECALL | 5 | pNFS / MAND | Section 20.3 | | CB_NOTIFY | 6 | DDELG / MAND | Section 20.4 | | CB_NOTIFY_LOCK | 13 | OPT | Section 20.11 | | CB_PUSH_DELEG | 7 | MAND | Section 20.5 | | CB_RECALL | 4 | FDELG, DDELG, | Section 20.2 | | | | pNFS / MAND | | | CB_RECALL_ANY | 8 | FDELG, DDELG / | Section 20.6 | | | | MAND | | | CB_RECALL_SLOT | 10 | MAND | Section 20.8 | | CB_RECALLABLE_OBJ_AVAIL | 9 | DDELG, pNFS / | Section 20.7 | | | | MAND | | | CB_SEQUENCE | 11 | MAND | Section 20.9 | | CB_WANTS_CANCELLED | 12 | DDELG / MAND | Section 20.10 | +-------------------------+-----+------------------- +---------------+ _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 03:55:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3AK-0008D8-1G; Thu, 08 Nov 2007 03:55:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3AJ-0008A1-1S for nfsv4@ietf.org; Thu, 08 Nov 2007 03:55:07 -0500 Received: from web38105.mail.mud.yahoo.com ([209.191.124.132]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iq3AI-0006Tu-Ec for nfsv4@ietf.org; Thu, 08 Nov 2007 03:55:06 -0500 Received: (qmail 24652 invoked by uid 60001); 8 Nov 2007 08:55:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=xLBVnukm+C/I1B+f8eEWHCYARE6Pnj6tfm1mY3iQDGMbgpqgIk9qzfrR6Ym6lb+rNwJZXJH57MCTVkftRVYxQBNGf/qAkUWAazG653xphGEKaqDIantx1jWDQfjAXyeyjsTJXvThhX38xK/jHaZZ5+9kkGP2OI81AMpIfNOaiQU=; X-YMail-OSG: 4PWr8mYVM1lO7UEeEoc.oHIEBrSh.Zd3hrl7ORrnafg21P.nEMstElYLamBUSZV6exGGM4H4wC8p86peeeUGjcEby3cVBmADXakF4V0XefxVbKuNVSI- Received: from [198.95.226.230] by web38105.mail.mud.yahoo.com via HTTP; Thu, 08 Nov 2007 00:55:05 PST Date: Thu, 8 Nov 2007 00:55:05 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] Layout Range. To: NFSv4 In-Reply-To: <47209AEB.6010907@panasas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <839994.23701.qm@web38105.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I see consensus for changing LAYOUTGET to return an array of patterns. --- Benny Halevy wrote: > On Oct. 24, 2007, 23:37 +0200, Garth Goodson > wrote: > > > > Robert Gordon wrote: > >> On Oct 24, 2007, at 11:21 AM, Garth Goodson wrote: > >> > >>> Right. LAYOUTGET was designed to return a single range starting > >>> at the offset returned covering the length returned. I believe > >>> it is stated that the returned layout must overlap by at least > >>> loga_minlength bytes (which must be at least 1) the requested > range. > >>> If the minlength requirement can not be met in a single layout an > >>> error is returned and the client is currently responsible for > splitting > >>> that range and retrying. > >> I think that error would be NFS4ERR_LAYOUTTRYLATER, however we > >> do not indicate it this is a transient issue or if the client > >> needs to split the range and try again. > >> > > TRYLATER is a transient error and I think should not be returned if > a > > range needs to be split due to striping issues, rather than some > type of > > locking issue over a portion of the range. > > > >>> If there are different striping patterns these should be returned > >>> via multiple layoutgets in separate layouts. > >> It would seem easier to make LAYOUTGET4resok.logr_layout an array, > >> as mike suggested. > >> > > > > I have no objection to returning an array, however I believe that a > > > client will still have to handle the corner case of not retrieving > the > > entire range at once (even if multiple layouts are returned), since > > > there could be other factors; e.g., max_count is too small to > return all > > layouts that cover that range. > > Agreed. > > Benny > > > > > -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 Thu Nov 08 06:44:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq5oM-0005s7-CM; Thu, 08 Nov 2007 06:44:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq5oJ-0005nj-Cw for nfsv4@ietf.org; Thu, 08 Nov 2007 06:44:35 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq5oI-0003KZ-Gr for nfsv4@ietf.org; Thu, 08 Nov 2007 06:44:35 -0500 X-IronPort-AV: E=Sophos;i="4.21,388,1188802800"; d="scan'208";a="120573929" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 08 Nov 2007 03:44:33 -0800 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 lA8BiXsU017082; Thu, 8 Nov 2007 03:44:33 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 03:44:33 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 03:44:33 -0800 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] Operations in NFSv4.1 (mandatory / optional) Date: Thu, 8 Nov 2007 06:43:57 -0500 Message-ID: In-Reply-To: <4624A550-302B-40A0-9430-6F38EB1249BD@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Operations in NFSv4.1 (mandatory / optional) Thread-Index: Acgh4/0q/zkzTliZSJ+8i20NBoWy7wAGFubQ From: "Noveck, Dave" To: "Spencer Shepler" , "NFSv4" X-OriginalArrivalTime: 08 Nov 2007 11:44:33.0018 (UTC) FILETIME=[BAD6E5A0:01C821FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 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 Looks OK to me. I assume that the text will explain that when something is listed as both "MAND" and part of an optional feature (e.g. pNFS), it is optional in the sense that NFS4ERR_NOTSUPP can and will be returned if that optional feature is not implemented.=20 -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Thursday, November 08, 2007 3:45 AM To: NFSv4 Subject: [nfsv4] Operations in NFSv4.1 (mandatory / optional) In the next I-D, a table will be added to summarize the operations in the context of being mandatory or optional. I have attached those tables to solicit any feedback prior to the next submission of the I-D. Spencer Operations: Operations +----------------------+-----+----------------------=20 +---------------+ | Operation | No. | Feature / | Defined =20 in | | | | Disposition =20 | | +----------------------+-----+----------------------=20 +---------------+ | ACCESS | 3 | MAND | Section =20 18.1 | | BACKCHANNEL_CTL | 40 | MAND | Section =20 18.33 | | BIND_CONN_TO_SESSION | 41 | MAND | Section =20 18.34 | | CLOSE | 4 | MAND | Section =20 18.2 | | COMMIT | 5 | MAND | Section =20 18.3 | | CREATE | 6 | MAND | Section =20 18.4 | | CREATE_SESSION | 43 | MAND | Section =20 18.36 | | DELEGPURGE | 7 | FDELG / MAND | Section =20 18.5 | | DELEGRETURN | 8 | FDELG, DDELG, pNFS / | Section =20 18.6 | | | | MAND =20 | | | DESTROY_CLIENTID | 57 | MAND | Section =20 18.50 | | DESTROY_SESSION | 44 | MAND | Section =20 18.37 | | EXCHANGE_ID | 42 | MAND | Section =20 18.35 | | FREE_STATEID | 45 | MAND | Section =20 18.38 | | GETATTR | 9 | MAND | Section =20 18.7 | | GETDEVICEINFO | 47 | pNFS / MAND | Section =20 18.40 | | GETDEVICELIST | 48 | pNFS / OPT | Section =20 18.41 | | GETFH | 10 | MAND | Section =20 18.8 | | GET_DIR_DELEGATION | 46 | DDELG / MAND | Section =20 18.39 | | LAYOUTCOMMIT | 49 | pNFS / MAND | Section =20 18.42 | | LAYOUTGET | 50 | pNFS / MAND | Section =20 18.43 | | LAYOUTRETURN | 51 | pNFS / MAND | Section =20 18.44 | | LINK | 11 | OPT | Section =20 18.9 | | LOCK | 12 | MAND | Section =20 18.10 | | LOCKT | 13 | MAND | Section =20 18.11 | | LOCKU | 14 | MAND | Section =20 18.12 | | LOOKUP | 15 | MAND | Section =20 18.13 | | LOOKUPP | 16 | MAND | Section =20 18.14 | | NVERIFY | 17 | MAND | Section =20 18.15 | | OPEN | 18 | MAND | Section =20 18.16 | | OPENATTR | 19 | MAND | Section =20 18.17 | | OPEN_CONFIRM | 20 | MNI | N/=20 A | | OPEN_DOWNGRADE | 21 | MAND | Section =20 18.18 | | PUTFH | 22 | MAND | Section =20 18.19 | | PUTPUBFH | 23 | MAND | Section =20 18.20 | | PUTROOTFH | 24 | MAND | Section =20 18.21 | | READ | 25 | MAND | Section =20 18.22 | | READDIR | 26 | MAND | Section =20 18.23 | | READLINK | 27 | OPT | Section =20 18.24 | | RECLAIM_COMPLETE | 58 | MAND | Section =20 18.51 | | RELEASE_LOCKOWNER | 39 | MNI | N/=20 A | | REMOVE | 28 | MAND | Section =20 18.25 | | RENAME | 29 | MAND | Section =20 18.26 | | RENEW | 30 | MNI | N/=20 A | | RESTOREFH | 31 | MAND | Section =20 18.27 | | SAVEFH | 32 | MAND | Section =20 18.28 | | SECINFO | 33 | MAND | Section =20 18.29 | | SECINFO_NO_NAME | 52 | MAND | Section =20 18.45 | | SEQUENCE | 53 | MAND | Section =20 18.46 | | SETATTR | 34 | MAND | Section =20 18.30 | | SET_CLIENTID | 35 | MNI | N/=20 A | | SET_CLIENTID_CONFIRM | 35 | MNI | N/=20 A | | SET_SSV | 54 | MAND | Section =20 18.47 | | TEST_STATEID | 55 | MAND | Section =20 18.48 | | VERIFY | 37 | MAND | Section =20 18.31 | | WANT_DELEGATION | 56 | OPT | Section =20 18.49 | | WRITE | 38 | MAND | Section =20 18.32 | +----------------------+-----+----------------------=20 +---------------+ Callback Operations: Operations +-------------------------+-----+-------------------=20 +---------------+ | Operation | No. | Feature / | Defined =20 in | | | | Disposition =20 | | +-------------------------+-----+-------------------=20 +---------------+ | CB_GETATTR | 3 | FDELG / MAND | Section =20 20.1 | | CB_LAYOUTRECALL | 5 | pNFS / MAND | Section =20 20.3 | | CB_NOTIFY | 6 | DDELG / MAND | Section =20 20.4 | | CB_NOTIFY_LOCK | 13 | OPT | Section =20 20.11 | | CB_PUSH_DELEG | 7 | MAND | Section =20 20.5 | | CB_RECALL | 4 | FDELG, DDELG, | Section =20 20.2 | | | | pNFS / MAND =20 | | | CB_RECALL_ANY | 8 | FDELG, DDELG / | Section =20 20.6 | | | | MAND =20 | | | CB_RECALL_SLOT | 10 | MAND | Section =20 20.8 | | CB_RECALLABLE_OBJ_AVAIL | 9 | DDELG, pNFS / | Section =20 20.7 | | | | MAND =20 | | | CB_SEQUENCE | 11 | MAND | Section =20 20.9 | | CB_WANTS_CANCELLED | 12 | DDELG / MAND | Section =20 20.10 | +-------------------------+-----+-------------------=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 Nov 08 07:59: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 1Iq6ys-0001H2-GB; Thu, 08 Nov 2007 07:59:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq6yr-0001Fj-0W for nfsv4@ietf.org; Thu, 08 Nov 2007 07:59:33 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq6yn-000484-Vj for nfsv4@ietf.org; Thu, 08 Nov 2007 07:59:32 -0500 X-IronPort-AV: E=Sophos;i="4.21,389,1188802800"; d="scan'208";a="120586446" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 08 Nov 2007 04:59:29 -0800 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 lA8CxS4B000406; Thu, 8 Nov 2007 04:59:29 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 04:59:29 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 04:59:28 -0800 Received: from tmt.netapp.com ([10.30.32.34]) by exnane01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Nov 2007 07:59:26 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 08 Nov 2007 07:59:18 -0500 To: Spencer Shepler From: "Talpey, Thomas" Subject: Re: [nfsv4] Operations in NFSv4.1 (mandatory / optional) In-Reply-To: <4624A550-302B-40A0-9430-6F38EB1249BD@sun.com> References: <4624A550-302B-40A0-9430-6F38EB1249BD@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: X-OriginalArrivalTime: 08 Nov 2007 12:59:26.0986 (UTC) FILETIME=[3173FEA0:01C82207] X-Spam-Score: -4.0 (----) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 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 At 03:44 AM 11/8/2007, Spencer Shepler wrote: > >In the next I-D, a table will be added to summarize >the operations in the context of being mandatory or optional. > >I have attached those tables to solicit any feedback prior >to the next submission of the I-D. I'm a little concerned about the wording with respect to client implementations. If I write an NFSv4.1 ROM boot client (ok call me crazy :-) ) surely it's not mandatory that I code in WRITE support. In other words, I think these are mandatory to the server, for the most part, and some of the callback ops to the client. Perhaps a second column is in order? It's kind of going there now, with the "FDELG", "pNFS" etc qualifiers. Or if this is too obvious, I'm fine with shutting up. Just putting my best spec hat on. Tom. > >Spencer > > Operations: > > Operations > > +----------------------+-----+---------------------- >+---------------+ > | Operation | No. | Feature / | Defined >in | > | | | Disposition >| | > +----------------------+-----+---------------------- >+---------------+ > | ACCESS | 3 | MAND | Section >18.1 | > | BACKCHANNEL_CTL | 40 | MAND | Section >18.33 | > | BIND_CONN_TO_SESSION | 41 | MAND | Section >18.34 | > | CLOSE | 4 | MAND | Section >18.2 | > | COMMIT | 5 | MAND | Section >18.3 | > | CREATE | 6 | MAND | Section >18.4 | > | CREATE_SESSION | 43 | MAND | Section >18.36 | > | DELEGPURGE | 7 | FDELG / MAND | Section >18.5 | > | DELEGRETURN | 8 | FDELG, DDELG, pNFS / | Section >18.6 | > | | | MAND >| | > | DESTROY_CLIENTID | 57 | MAND | Section >18.50 | > | DESTROY_SESSION | 44 | MAND | Section >18.37 | > | EXCHANGE_ID | 42 | MAND | Section >18.35 | > | FREE_STATEID | 45 | MAND | Section >18.38 | > | GETATTR | 9 | MAND | Section >18.7 | > | GETDEVICEINFO | 47 | pNFS / MAND | Section >18.40 | > | GETDEVICELIST | 48 | pNFS / OPT | Section >18.41 | > | GETFH | 10 | MAND | Section >18.8 | > | GET_DIR_DELEGATION | 46 | DDELG / MAND | Section >18.39 | > | LAYOUTCOMMIT | 49 | pNFS / MAND | Section >18.42 | > | LAYOUTGET | 50 | pNFS / MAND | Section >18.43 | > | LAYOUTRETURN | 51 | pNFS / MAND | Section >18.44 | > | LINK | 11 | OPT | Section >18.9 | > | LOCK | 12 | MAND | Section >18.10 | > | LOCKT | 13 | MAND | Section >18.11 | > | LOCKU | 14 | MAND | Section >18.12 | > | LOOKUP | 15 | MAND | Section >18.13 | > | LOOKUPP | 16 | MAND | Section >18.14 | > | NVERIFY | 17 | MAND | Section >18.15 | > | OPEN | 18 | MAND | Section >18.16 | > | OPENATTR | 19 | MAND | Section >18.17 | > | OPEN_CONFIRM | 20 | MNI | N/ >A | > | OPEN_DOWNGRADE | 21 | MAND | Section >18.18 | > | PUTFH | 22 | MAND | Section >18.19 | > | PUTPUBFH | 23 | MAND | Section >18.20 | > | PUTROOTFH | 24 | MAND | Section >18.21 | > | READ | 25 | MAND | Section >18.22 | > | READDIR | 26 | MAND | Section >18.23 | > | READLINK | 27 | OPT | Section >18.24 | > | RECLAIM_COMPLETE | 58 | MAND | Section >18.51 | > | RELEASE_LOCKOWNER | 39 | MNI | N/ >A | > | REMOVE | 28 | MAND | Section >18.25 | > | RENAME | 29 | MAND | Section >18.26 | > | RENEW | 30 | MNI | N/ >A | > | RESTOREFH | 31 | MAND | Section >18.27 | > | SAVEFH | 32 | MAND | Section >18.28 | > | SECINFO | 33 | MAND | Section >18.29 | > | SECINFO_NO_NAME | 52 | MAND | Section >18.45 | > | SEQUENCE | 53 | MAND | Section >18.46 | > | SETATTR | 34 | MAND | Section >18.30 | > | SET_CLIENTID | 35 | MNI | N/ >A | > | SET_CLIENTID_CONFIRM | 35 | MNI | N/ >A | > | SET_SSV | 54 | MAND | Section >18.47 | > | TEST_STATEID | 55 | MAND | Section >18.48 | > | VERIFY | 37 | MAND | Section >18.31 | > | WANT_DELEGATION | 56 | OPT | Section >18.49 | > | WRITE | 38 | MAND | Section >18.32 | > +----------------------+-----+---------------------- >+---------------+ > > Callback Operations: > Operations > > +-------------------------+-----+------------------- >+---------------+ > | Operation | No. | Feature / | Defined >in | > | | | Disposition >| | > +-------------------------+-----+------------------- >+---------------+ > | CB_GETATTR | 3 | FDELG / MAND | Section >20.1 | > | CB_LAYOUTRECALL | 5 | pNFS / MAND | Section >20.3 | > | CB_NOTIFY | 6 | DDELG / MAND | Section >20.4 | > | CB_NOTIFY_LOCK | 13 | OPT | Section >20.11 | > | CB_PUSH_DELEG | 7 | MAND | Section >20.5 | > | CB_RECALL | 4 | FDELG, DDELG, | Section >20.2 | > | | | pNFS / MAND >| | > | CB_RECALL_ANY | 8 | FDELG, DDELG / | Section >20.6 | > | | | MAND >| | > | CB_RECALL_SLOT | 10 | MAND | Section >20.8 | > | CB_RECALLABLE_OBJ_AVAIL | 9 | DDELG, pNFS / | Section >20.7 | > | | | MAND >| | > | CB_SEQUENCE | 11 | MAND | Section >20.9 | > | CB_WANTS_CANCELLED | 12 | DDELG / MAND | Section >20.10 | > +-------------------------+-----+------------------- >+---------------+ > > >_______________________________________________ >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 Nov 08 09:56: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 1Iq8oE-00022A-LX; Thu, 08 Nov 2007 09:56:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq8oD-00021m-Jy for nfsv4@ietf.org; Thu, 08 Nov 2007 09:56:41 -0500 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 1Iq8oC-0000ld-Qj for nfsv4@ietf.org; Thu, 08 Nov 2007 09:56:41 -0500 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 lA8Eud9v007026; Thu, 8 Nov 2007 09:56:39 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 8 Nov 2007 09:56:39 -0500 Received: from fs1.bhalevy.com ([172.17.133.38]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 09:56:38 -0500 Message-ID: <4733239C.3010603@panasas.com> Date: Thu, 08 Nov 2007 16:56:28 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: [nfsv4] Operations in NFSv4.1 (mandatory / optional) References: <4624A550-302B-40A0-9430-6F38EB1249BD@sun.com> In-Reply-To: <4624A550-302B-40A0-9430-6F38EB1249BD@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 14:56:38.0651 (UTC) FILETIME=[90A6ECB0:01C82217] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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 The list looks good overall. I'd just add CB_RECALL_ANY and CB_WANTS_CANCELLED to pNFS / MAND [btw, isn't CANCELLED supposed to be spelled with one 'l'?] Benny On Nov. 08, 2007, 10:44 +0200, Spencer Shepler wrote: > In the next I-D, a table will be added to summarize > the operations in the context of being mandatory or optional. > > I have attached those tables to solicit any feedback prior > to the next submission of the I-D. > > Spencer > > Operations: > > Operations > > +----------------------+-----+---------------------- > +---------------+ > | Operation | No. | Feature / | Defined > in | > | | | Disposition > | | > +----------------------+-----+---------------------- > +---------------+ > | ACCESS | 3 | MAND | Section > 18.1 | > | BACKCHANNEL_CTL | 40 | MAND | Section > 18.33 | > | BIND_CONN_TO_SESSION | 41 | MAND | Section > 18.34 | > | CLOSE | 4 | MAND | Section > 18.2 | > | COMMIT | 5 | MAND | Section > 18.3 | > | CREATE | 6 | MAND | Section > 18.4 | > | CREATE_SESSION | 43 | MAND | Section > 18.36 | > | DELEGPURGE | 7 | FDELG / MAND | Section > 18.5 | > | DELEGRETURN | 8 | FDELG, DDELG, pNFS / | Section > 18.6 | > | | | MAND > | | > | DESTROY_CLIENTID | 57 | MAND | Section > 18.50 | > | DESTROY_SESSION | 44 | MAND | Section > 18.37 | > | EXCHANGE_ID | 42 | MAND | Section > 18.35 | > | FREE_STATEID | 45 | MAND | Section > 18.38 | > | GETATTR | 9 | MAND | Section > 18.7 | > | GETDEVICEINFO | 47 | pNFS / MAND | Section > 18.40 | > | GETDEVICELIST | 48 | pNFS / OPT | Section > 18.41 | > | GETFH | 10 | MAND | Section > 18.8 | > | GET_DIR_DELEGATION | 46 | DDELG / MAND | Section > 18.39 | > | LAYOUTCOMMIT | 49 | pNFS / MAND | Section > 18.42 | > | LAYOUTGET | 50 | pNFS / MAND | Section > 18.43 | > | LAYOUTRETURN | 51 | pNFS / MAND | Section > 18.44 | > | LINK | 11 | OPT | Section > 18.9 | > | LOCK | 12 | MAND | Section > 18.10 | > | LOCKT | 13 | MAND | Section > 18.11 | > | LOCKU | 14 | MAND | Section > 18.12 | > | LOOKUP | 15 | MAND | Section > 18.13 | > | LOOKUPP | 16 | MAND | Section > 18.14 | > | NVERIFY | 17 | MAND | Section > 18.15 | > | OPEN | 18 | MAND | Section > 18.16 | > | OPENATTR | 19 | MAND | Section > 18.17 | > | OPEN_CONFIRM | 20 | MNI | N/ > A | > | OPEN_DOWNGRADE | 21 | MAND | Section > 18.18 | > | PUTFH | 22 | MAND | Section > 18.19 | > | PUTPUBFH | 23 | MAND | Section > 18.20 | > | PUTROOTFH | 24 | MAND | Section > 18.21 | > | READ | 25 | MAND | Section > 18.22 | > | READDIR | 26 | MAND | Section > 18.23 | > | READLINK | 27 | OPT | Section > 18.24 | > | RECLAIM_COMPLETE | 58 | MAND | Section > 18.51 | > | RELEASE_LOCKOWNER | 39 | MNI | N/ > A | > | REMOVE | 28 | MAND | Section > 18.25 | > | RENAME | 29 | MAND | Section > 18.26 | > | RENEW | 30 | MNI | N/ > A | > | RESTOREFH | 31 | MAND | Section > 18.27 | > | SAVEFH | 32 | MAND | Section > 18.28 | > | SECINFO | 33 | MAND | Section > 18.29 | > | SECINFO_NO_NAME | 52 | MAND | Section > 18.45 | > | SEQUENCE | 53 | MAND | Section > 18.46 | > | SETATTR | 34 | MAND | Section > 18.30 | > | SET_CLIENTID | 35 | MNI | N/ > A | > | SET_CLIENTID_CONFIRM | 35 | MNI | N/ > A | > | SET_SSV | 54 | MAND | Section > 18.47 | > | TEST_STATEID | 55 | MAND | Section > 18.48 | > | VERIFY | 37 | MAND | Section > 18.31 | > | WANT_DELEGATION | 56 | OPT | Section > 18.49 | > | WRITE | 38 | MAND | Section > 18.32 | > +----------------------+-----+---------------------- > +---------------+ > > Callback Operations: > Operations > > +-------------------------+-----+------------------- > +---------------+ > | Operation | No. | Feature / | Defined > in | > | | | Disposition > | | > +-------------------------+-----+------------------- > +---------------+ > | CB_GETATTR | 3 | FDELG / MAND | Section > 20.1 | > | CB_LAYOUTRECALL | 5 | pNFS / MAND | Section > 20.3 | > | CB_NOTIFY | 6 | DDELG / MAND | Section > 20.4 | > | CB_NOTIFY_LOCK | 13 | OPT | Section > 20.11 | > | CB_PUSH_DELEG | 7 | MAND | Section > 20.5 | > | CB_RECALL | 4 | FDELG, DDELG, | Section > 20.2 | > | | | pNFS / MAND > | | > | CB_RECALL_ANY | 8 | FDELG, DDELG / | Section > 20.6 | > | | | MAND > | | > | CB_RECALL_SLOT | 10 | MAND | Section > 20.8 | > | CB_RECALLABLE_OBJ_AVAIL | 9 | DDELG, pNFS / | Section > 20.7 | > | | | MAND > | | > | CB_SEQUENCE | 11 | MAND | Section > 20.9 | > | CB_WANTS_CANCELLED | 12 | DDELG / MAND | Section > 20.10 | > +-------------------------+-----+------------------- > +---------------+ > > > _______________________________________________ > 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 Nov 08 10:02: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 1Iq8tq-0000J9-9o; Thu, 08 Nov 2007 10:02:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq8to-0000HY-OB for nfsv4@ietf.org; Thu, 08 Nov 2007 10:02:28 -0500 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 1Iq8tl-0007sv-9J for nfsv4@ietf.org; Thu, 08 Nov 2007 10:02:28 -0500 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 lA8F2O5a007212; Thu, 8 Nov 2007 10:02:24 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 8 Nov 2007 10:02:24 -0500 Received: from fs1.bhalevy.com ([172.17.133.38]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 10:02:24 -0500 Message-ID: <473324F8.8020907@panasas.com> Date: Thu, 08 Nov 2007 17:02:16 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: email2mre-ietf@yahoo.com Subject: Re: [nfsv4] Issue 165: should we adopt a convention for so_major_ids ? References: <438577.47550.qm@web38110.mail.mud.yahoo.com> In-Reply-To: <438577.47550.qm@web38110.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 15:02:24.0801 (UTC) FILETIME=[5EF93910:01C82218] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Nov. 07, 2007, 22:00 +0200, Mike Eisler wrote: > http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue165 > > Benny wrote for this issue: > > I think that the rfc should recommend a naming convention that will > help to > prevent so_major_id collisions, especially when using servers from > different > vendors. For example, iscsi (rfc3720) specifies iqn and eui formats, > the former > requires a registered domain name, the latter a IEEE EUI-64 world-wide > unique name > > ----------------------------- > > So three questions: > > - do we want to RECOMMEND a format for so_major_id? > - do we want to mandate a format for so_major_id? > - should the mandated or recommended format be a DNS FQDN? > > My answers are: > no, yes, yes. > Agreed. > Discussion welcome. If no consensus observed, then the issue will > be deferred (to NFSv4.2). > > > > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 -- Benny Halevy Software Architect Tel/Fax: +972-3-647-8340 Mobile: +972-54-802-8340 US: +1-412-203-3187 bhalevy@panasas.com Panasas, Inc. Leader in Parallel Storage www.panasas.com _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 10:23: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 1Iq9EI-0008E9-ON; Thu, 08 Nov 2007 10:23:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9EH-0008A1-Da for nfsv4@ietf.org; Thu, 08 Nov 2007 10:23:37 -0500 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 1Iq9EE-0000AA-1y for nfsv4@ietf.org; Thu, 08 Nov 2007 10:23:37 -0500 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 lA8FNXGP007772; Thu, 8 Nov 2007 10:23:33 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 8 Nov 2007 10:23:33 -0500 Received: from fs1.bhalevy.com ([172.17.133.38]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 10:23:32 -0500 Message-ID: <473329EA.5030104@panasas.com> Date: Thu, 08 Nov 2007 17:23:22 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: email2mre-ietf@yahoo.com Subject: Re: [nfsv4] Re: should we allow LAYOUTCOMMIT for reads References: <309403.46319.qm@web38103.mail.mud.yahoo.com> In-Reply-To: <309403.46319.qm@web38103.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 15:23:32.0614 (UTC) FILETIME=[52A62260:01C8221B] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Spencer Shepler , Brent Welch , "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 Nov. 07, 2007, 21:13 +0200, Mike Eisler wrote: > --- Benny Halevy wrote: > >> On Nov. 07, 2007, 20:40 +0200, Spencer Shepler >> wrote: >>> If the only purpose of the access time field in layoutcommit is to >>> allow the client the ability to update it (no release of >> allocations >>> or other side -effects), wouldn't SETATTR be sufficient for the >> client? >>> Or is there concern about appropriate access in setting that >> attribute >>> where a layout based update of access time would be better? >> explicit setattr won't work the same way if multiple clients are >> reading the file concurrently as it may set the access time >> backwards. > > > enum time_how4 { > SET_TO_SERVER_TIME4 = 0, > SET_TO_CLIENT_TIME4 = 1 > }; > > settime4 > > union settime4 switch (time_how4 set_it) { > case SET_TO_CLIENT_TIME4: > nfstime4 time; > default: > void; > }; > > The client can set set_it to SET_TO_SERVER_TIME4 when > it issues the SETATTR. OK. Then that leaves us only with our requirement for layout-type specific payload in LAYOUTRETURN. There shouldn't be any problem with adding that, right? > > As I recall saying in the pNFS review, LAYOUTCOMMIT seems to > be replicating functionality we already have. > >> The intention of the LAYOUTCOMMIT hint was to only set the >> access_time >> on the file if the client's reported access_time is later than the >> current access_time (and not in the future in which case the current >> time >> should be used) > > That seems over engineered. Accurate access_time has never > been something NFS (and probably every other networked file system) > could guarantee. > >> We have customers that demand atime support so I would say that > > What precisely are they demanding? > > That every read() from the client's cache update the atime? > > I get that all the time from customers and QA engineers, and > I tell them they can use direct I/O to the server if that's > what they think they need. > > And I would tell the customer that perfectly accurate atime is > something that won't be provided with pNFS. We eliminated > GETATTR from the set of operations a file-based data server can > support for a reason. > > I can't be specific about the requirements but they don't require a high level of accuracy. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 10:41: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 1Iq9Vv-0004we-Ta; Thu, 08 Nov 2007 10:41:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq9Vu-0004ue-De for nfsv4@ietf.org; Thu, 08 Nov 2007 10:41:50 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq9Vr-0000vu-WA for nfsv4@ietf.org; Thu, 08 Nov 2007 10:41:50 -0500 X-IronPort-AV: E=Sophos;i="4.21,389,1188802800"; d="scan'208";a="120627788" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 08 Nov 2007 07:41:20 -0800 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 lA8Ff8m3011480; Thu, 8 Nov 2007 07:41:19 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 07:41:14 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 07:41:14 -0800 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] Operations in NFSv4.1 (mandatory / optional) Date: Thu, 8 Nov 2007 10:41:12 -0500 Message-ID: In-Reply-To: <4733239C.3010603@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Operations in NFSv4.1 (mandatory / optional) Thread-Index: AcgiF/s2bOTfMAl1S1i2XwEFbgW65AABaLsQ From: "Noveck, Dave" To: "Benny Halevy" , "Spencer Shepler" X-OriginalArrivalTime: 08 Nov 2007 15:41:14.0122 (UTC) FILETIME=[CB5B66A0:01C8221D] X-Spam-Score: -4.0 (----) X-Scan-Signature: a492040269d440726bfd84680622cee7 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 > [btw, isn't CANCELLED supposed to be spelled with one 'l'?] In Britain and Canada. US spelling is with two. -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Thursday, November 08, 2007 9:56 AM To: Spencer Shepler Cc: NFSv4 Subject: Re: [nfsv4] Operations in NFSv4.1 (mandatory / optional) The list looks good overall. I'd just add CB_RECALL_ANY and CB_WANTS_CANCELLED to pNFS / MAND [btw, isn't CANCELLED supposed to be spelled with one 'l'?] Benny On Nov. 08, 2007, 10:44 +0200, Spencer Shepler wrote: > In the next I-D, a table will be added to summarize > the operations in the context of being mandatory or optional. >=20 > I have attached those tables to solicit any feedback prior > to the next submission of the I-D. >=20 > Spencer >=20 > Operations: >=20 > Operations >=20 > +----------------------+-----+----------------------=20 > +---------------+ > | Operation | No. | Feature / | Defined =20 > in | > | | | Disposition =20 > | | > +----------------------+-----+----------------------=20 > +---------------+ > | ACCESS | 3 | MAND | Section =20 > 18.1 | > | BACKCHANNEL_CTL | 40 | MAND | Section =20 > 18.33 | > | BIND_CONN_TO_SESSION | 41 | MAND | Section =20 > 18.34 | > | CLOSE | 4 | MAND | Section =20 > 18.2 | > | COMMIT | 5 | MAND | Section =20 > 18.3 | > | CREATE | 6 | MAND | Section =20 > 18.4 | > | CREATE_SESSION | 43 | MAND | Section =20 > 18.36 | > | DELEGPURGE | 7 | FDELG / MAND | Section =20 > 18.5 | > | DELEGRETURN | 8 | FDELG, DDELG, pNFS / | Section =20 > 18.6 | > | | | MAND =20 > | | > | DESTROY_CLIENTID | 57 | MAND | Section =20 > 18.50 | > | DESTROY_SESSION | 44 | MAND | Section =20 > 18.37 | > | EXCHANGE_ID | 42 | MAND | Section =20 > 18.35 | > | FREE_STATEID | 45 | MAND | Section =20 > 18.38 | > | GETATTR | 9 | MAND | Section =20 > 18.7 | > | GETDEVICEINFO | 47 | pNFS / MAND | Section =20 > 18.40 | > | GETDEVICELIST | 48 | pNFS / OPT | Section =20 > 18.41 | > | GETFH | 10 | MAND | Section =20 > 18.8 | > | GET_DIR_DELEGATION | 46 | DDELG / MAND | Section =20 > 18.39 | > | LAYOUTCOMMIT | 49 | pNFS / MAND | Section =20 > 18.42 | > | LAYOUTGET | 50 | pNFS / MAND | Section =20 > 18.43 | > | LAYOUTRETURN | 51 | pNFS / MAND | Section =20 > 18.44 | > | LINK | 11 | OPT | Section =20 > 18.9 | > | LOCK | 12 | MAND | Section =20 > 18.10 | > | LOCKT | 13 | MAND | Section =20 > 18.11 | > | LOCKU | 14 | MAND | Section =20 > 18.12 | > | LOOKUP | 15 | MAND | Section =20 > 18.13 | > | LOOKUPP | 16 | MAND | Section =20 > 18.14 | > | NVERIFY | 17 | MAND | Section =20 > 18.15 | > | OPEN | 18 | MAND | Section =20 > 18.16 | > | OPENATTR | 19 | MAND | Section =20 > 18.17 | > | OPEN_CONFIRM | 20 | MNI | N/=20 > A | > | OPEN_DOWNGRADE | 21 | MAND | Section =20 > 18.18 | > | PUTFH | 22 | MAND | Section =20 > 18.19 | > | PUTPUBFH | 23 | MAND | Section =20 > 18.20 | > | PUTROOTFH | 24 | MAND | Section =20 > 18.21 | > | READ | 25 | MAND | Section =20 > 18.22 | > | READDIR | 26 | MAND | Section =20 > 18.23 | > | READLINK | 27 | OPT | Section =20 > 18.24 | > | RECLAIM_COMPLETE | 58 | MAND | Section =20 > 18.51 | > | RELEASE_LOCKOWNER | 39 | MNI | N/=20 > A | > | REMOVE | 28 | MAND | Section =20 > 18.25 | > | RENAME | 29 | MAND | Section =20 > 18.26 | > | RENEW | 30 | MNI | N/=20 > A | > | RESTOREFH | 31 | MAND | Section =20 > 18.27 | > | SAVEFH | 32 | MAND | Section =20 > 18.28 | > | SECINFO | 33 | MAND | Section =20 > 18.29 | > | SECINFO_NO_NAME | 52 | MAND | Section =20 > 18.45 | > | SEQUENCE | 53 | MAND | Section =20 > 18.46 | > | SETATTR | 34 | MAND | Section =20 > 18.30 | > | SET_CLIENTID | 35 | MNI | N/=20 > A | > | SET_CLIENTID_CONFIRM | 35 | MNI | N/=20 > A | > | SET_SSV | 54 | MAND | Section =20 > 18.47 | > | TEST_STATEID | 55 | MAND | Section =20 > 18.48 | > | VERIFY | 37 | MAND | Section =20 > 18.31 | > | WANT_DELEGATION | 56 | OPT | Section =20 > 18.49 | > | WRITE | 38 | MAND | Section =20 > 18.32 | > +----------------------+-----+----------------------=20 > +---------------+ >=20 > Callback Operations: > Operations >=20 > +-------------------------+-----+-------------------=20 > +---------------+ > | Operation | No. | Feature / | Defined =20 > in | > | | | Disposition =20 > | | > +-------------------------+-----+-------------------=20 > +---------------+ > | CB_GETATTR | 3 | FDELG / MAND | Section =20 > 20.1 | > | CB_LAYOUTRECALL | 5 | pNFS / MAND | Section =20 > 20.3 | > | CB_NOTIFY | 6 | DDELG / MAND | Section =20 > 20.4 | > | CB_NOTIFY_LOCK | 13 | OPT | Section =20 > 20.11 | > | CB_PUSH_DELEG | 7 | MAND | Section =20 > 20.5 | > | CB_RECALL | 4 | FDELG, DDELG, | Section =20 > 20.2 | > | | | pNFS / MAND =20 > | | > | CB_RECALL_ANY | 8 | FDELG, DDELG / | Section =20 > 20.6 | > | | | MAND =20 > | | > | CB_RECALL_SLOT | 10 | MAND | Section =20 > 20.8 | > | CB_RECALLABLE_OBJ_AVAIL | 9 | DDELG, pNFS / | Section =20 > 20.7 | > | | | MAND =20 > | | > | CB_SEQUENCE | 11 | MAND | Section =20 > 20.9 | > | CB_WANTS_CANCELLED | 12 | DDELG / MAND | Section =20 > 20.10 | > +-------------------------+-----+-------------------=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 Thu Nov 08 11:59: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 1IqAif-0002KM-ES; Thu, 08 Nov 2007 11:59:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAie-0002JZ-Dw for nfsv4@ietf.org; Thu, 08 Nov 2007 11:59:04 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqAid-0005OK-AP for nfsv4@ietf.org; Thu, 08 Nov 2007 11:59:04 -0500 X-IronPort-AV: E=Sophos;i="4.21,390,1188802800"; d="scan'208";a="120651608" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 08 Nov 2007 08:58:32 -0800 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 lA8GwVJ2009743; Thu, 8 Nov 2007 08:58:31 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 08:58:31 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 08:58:31 -0800 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] Proposed resolutions for some pnfs-related[[Comment]]sections Date: Thu, 8 Nov 2007 11:58:29 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections Thread-Index: Acgf9mmYWUvpHOL8RcaHcQ9JwYMG7AAAIosAAIlO1EA= From: "Noveck, Dave" To: "Noveck, Dave" , "Robert Gordon" X-OriginalArrivalTime: 08 Nov 2007 16:58:31.0635 (UTC) FILETIME=[9787BA30:01C82228] X-Spam-Score: -4.0 (----) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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 > > A server could be implemented in such a way that the stateid conveys > > the fact that the IO is intended for the data-server persona... =20 > > couldn't it ? > > Yes it could. Actually it can't. This is a consequence of the global stateid model for=20 the file layout. Sigh! So, given that, here is my second attempt at addressing this: Clients accessing data on an NFSv4.1 data server MUST issue only the NULL procedure and COMPOUND procedures whose operations are taken only from two restricted subsets of the operations defined as valid NFSv4.1=20 operations. Clients MUST use the filehandle contained=20 within the layout when accessing data on NFSv4.1 data=20 servers.=20 The first of these operation subsets consist of session management operations where the current filehandle is not relevant. This subset consists=20 of the BACKCHANNEL_CTL, BIND_CONN_TO_SESSION, CREATE_SESSION, DESTROY_CLIENTID, DESTROY_SESSION, EXCHANGE_ID, SECINFO_NO_NAME, SET_SSV, and SEQUENCE operations. The client may use these operations in order to set up and maintain the appropriate client IDs and sessions involved in communication with the data server. Henceforth these will be referred to as data-server housekeeping operations. The second subset consists of COMMIT, READ, WRITE, PUTFH,=20 and SECINFO_NO_NAME. These operations must be used with a current filehandle taken from the=20 layout. In the case of PUTFH, the new current filehandle must be one taken from the layout. Henceforth, these will be referred to as data-server IO operatons. As described in ,=20 a client MUST NOT issue an I/O to a data server for which it does not hold a valid layout; the data server MUST reject such an I/O. Unless the server has a concurrent non-data-server personality, i.e. EXCHANGE_ID results returned=20 (EXCHGID4_FLAG_USE_PNFS_DS | EXCHGID4_FLAG_USE_PNFS_MDS)=20 or (EXCHGID4_FLAG_USE_PNFS_DS | EXCHGID4_FLAG_USE_NON_PNFS),=20 see , any use of operations other than those specified in the two=20 subsets above MUST return NFS4ERR_NOTSUPP to the client. When the server has concurrent data server and=20 non-data-server personalities, each COMPOUND sent by the=20 client MUST be constructed so that it appropriate to one of the two personalities, and must not contain operations directed to a mix of those=20 personalities. The server MUST enforce this. To understand the constraints, operations within a COMPOUND are divided into the following three classes:=20 An operation which is ambiguous regarding its personality assignment. These include all of the data-server housekeeping operations. Additionally, if the server has assigned filehandles so that the ones defined by the layout are the same as those used by the meta-data=20 server, all operations in the second class are within this group unless a stateid used is incompatible with a data-server personality in that it is a special stateid or has a non-zero seqid field. An operation which is referable to the data server personality. These are data-server IO operations where the filehandle is one that can only be validly directed to the data-server personality. An operation which is referable to the non-data-server personality. These include all COMPOUND operations that are neither data-server housekeeping nor data-server IO=20 operations plus data-server IO operations where the=20 current fh (or the one to be made the current fh in the case of PUTFH) is one that is only valid on the metadata server or where a stateid is used that is incompatible=20 with the data server, i.e. is a spcial stateid or has a non-zero seqid value. When a COMPOUND first executes an operation from class 3 above, it acts as a normal COMPOUND on any other server and the=20 data server personality ceases to be relevant.=20 There are no special restrictions on the=20 operations in the COMPOUND to limit then to those for a data server. When a PUTFH is done, filehandles derived from the layout are not valid. If their format is not normally acceptable, then NFS4ERR_BADHANDLE MUST result. Similarly, current filehandles for other operations do not accept filehandles derived from layouts and not=20 normally usable on metadata-server and using these will result in NFS4ERR_STALE.=20 When a COMPOUND first executes an operation from class 2, which would be PUTFH where the filehandle is one from a layout, the COMPOUND henceforth is interpreted with respect to the data server personality.=20 Operations outside the two classes discussed above MUST result in NFS4ERR_NOTSUPP. Filehandles are validated using the rules of the data server, resulting in NFS4ERR_BADHANDLE and/or NFS4ERR_STALE even when they would not normally do so when addressed to the non-data-server personality. Stateids must obey the rules of the data server in that any use of special stateids or stateids with non-zero seqid values must=20 result in NFS4ERR_BAD_STATEID. =09 Until the server first executes an operation from class 2 or class 3, the client MUST not depend on the operation=20 being executed by either the data-server or the non-data-server personality. The server MUST pick one personality consistently for a given COMPOUND, with the only possible transition being=20 a single one when the first operation from class 2 or class 3 is executed. Because of the complexity induced by assigning filehandles so they can be used on both a data server and a metadata server, it is recommended that where the same server can have both=20 personalities, the server assign filehandles within layouts so=20 that separate filehandles are applied to both personalities. This makes unambiguous the server for which a given request is intended. -----Original Message----- From: Noveck, Dave=20 Sent: Monday, November 05, 2007 5:02 PM To: 'Robert Gordon' Cc: Muntz, Daniel; nfsv4@ietf.org Subject: RE: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections Yes it could. In fact, there are reasons that they pretty well have to be distinguishable. An MDS-based stateid can reply on the cleintid (gotten from the sessionid) for uniqueness there the DS stateids which are going to be interpreted by DS's with other sessions don't have that ability. I think I'm going to try to come with attempt-2 to deal with this issue. One complexity is that there are some DS ops that don't have=20 stateids. -----Original Message----- From: Robert Gordon [mailto:Robert.Gordon@Sun.COM]=20 Sent: Monday, November 05, 2007 4:54 PM To: Noveck, Dave Cc: Muntz, Daniel; nfsv4@ietf.org Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections On Nov 5, 2007, at 3:35 PM, Noveck, Dave wrote: >> Is there a case where it makes sense to complicate the meaning of >> "MDS FH" vs. "DS FH" by allowing this special case? > > It's the server that has the complexity when he receives an FH and > has to distinguish which one it is (when it may not be disguishable), > and thus which personality a given oepration is being directed at. A server could be implemented in such a way that the stateid conveys the fact that the IO is intended for the data-server persona... =20 couldn't it ? Robert.. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 12:14: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 1IqAxh-0008Js-S4; Thu, 08 Nov 2007 12:14:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAxg-0008JI-Q5 for nfsv4@ietf.org; Thu, 08 Nov 2007 12:14:36 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqAxc-0004AI-9H for nfsv4@ietf.org; Thu, 08 Nov 2007 12:14:36 -0500 Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IqAxZ-0005yO-IA; Thu, 08 Nov 2007 18:14:29 +0100 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx9.uio.no) by mail-mx9.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IqAxZ-0006K0-8U; Thu, 08 Nov 2007 18:14:29 +0100 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx9.uio.no with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IqAxY-0006Jj-Qc; Thu, 08 Nov 2007 18:14:29 +0100 Subject: Re: [nfsv4] Operations in NFSv4.1 (mandatory / optional) From: Trond Myklebust To: Spencer Shepler In-Reply-To: <4624A550-302B-40A0-9430-6F38EB1249BD@sun.com> References: <4624A550-302B-40A0-9430-6F38EB1249BD@sun.com> Content-Type: text/plain Date: Thu, 08 Nov 2007 12:17:05 -0500 Message-Id: <1194542225.7655.23.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.148) X-UiO-Scanned: 0BE013BA5F265148FEEB6A91A57CA2E415C40441 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 201 total 5011771 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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, 2007-11-08 at 02:44 -0600, Spencer Shepler wrote: > In the next I-D, a table will be added to summarize > the operations in the context of being mandatory or optional. > > I have attached those tables to solicit any feedback prior > to the next submission of the I-D. OPENATTR should not be marked as mandatory. It depends on the filesystem support. SECINFO_NO_NAME does not need to mandatory unless the server returns NFS4ERR_WRONGSEC on LOOKUPP calls. CB_PUSH_DELEG is conditional on the WANT_DELEGATION feature, it is not mandatory. Cheers Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 12:48: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 1IqBUG-0003Nz-9q; Thu, 08 Nov 2007 12:48:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBUF-0003NO-7L for nfsv4@ietf.org; Thu, 08 Nov 2007 12:48:15 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqBUE-000796-KM for nfsv4@ietf.org; Thu, 08 Nov 2007 12:48:15 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA8HmDYS028918 for ; Thu, 8 Nov 2007 17:48:13 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR700M0173LW200@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 08 Nov 2007 10:48:13 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-138-155.dsl.austtx.sbcglobal.net [71.145.138.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR7006IP847M890@mail-amer.sun.com>; Thu, 08 Nov 2007 10:48:08 -0700 (MST) Date: Thu, 08 Nov 2007 11:48:22 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Re: should we allow LAYOUTCOMMIT for reads In-reply-to: <473329EA.5030104@panasas.com> To: Benny Halevy 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: <309403.46319.qm@web38103.mail.mud.yahoo.com> <473329EA.5030104@panasas.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: email2mre-ietf@yahoo.com, Brent Welch , "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 Nov 8, 2007, at 9:23 AM, Benny Halevy wrote: > On Nov. 07, 2007, 21:13 +0200, Mike Eisler ietf@yahoo.com> wrote: >> --- Benny Halevy wrote: >> >>> On Nov. 07, 2007, 20:40 +0200, Spencer Shepler >>> wrote: >>>> If the only purpose of the access time field in layoutcommit is to >>>> allow the client the ability to update it (no release of >>> allocations >>>> or other side -effects), wouldn't SETATTR be sufficient for the >>> client? >>>> Or is there concern about appropriate access in setting that >>> attribute >>>> where a layout based update of access time would be better? >>> explicit setattr won't work the same way if multiple clients are >>> reading the file concurrently as it may set the access time >>> backwards. >> >> >> enum time_how4 { >> SET_TO_SERVER_TIME4 = 0, >> SET_TO_CLIENT_TIME4 = 1 >> }; >> >> settime4 >> >> union settime4 switch (time_how4 set_it) { >> case SET_TO_CLIENT_TIME4: >> nfstime4 time; >> default: >> void; >> }; >> >> The client can set set_it to SET_TO_SERVER_TIME4 when >> it issues the SETATTR. > > OK. Then that leaves us only with our requirement for > layout-type specific payload in LAYOUTRETURN. > There shouldn't be any problem with adding that, right? So it appears from the objects I-D that the information being transferred to the server on LAYOUTCOMMIT is the error list. Is there a reason that this needs to move from LAYOUTCOMMIT to LAYOUTRETURN or why the client would use LAYOUTCOMMIT in the case of WRITEs vs. LAYOUTRETURN for READs? Obviously, I am in need of clarity about how layout type specific data will be used on LAYOUTRETURN, etc. > >> >> As I recall saying in the pNFS review, LAYOUTCOMMIT seems to >> be replicating functionality we already have. >> >>> The intention of the LAYOUTCOMMIT hint was to only set the >>> access_time >>> on the file if the client's reported access_time is later than the >>> current access_time (and not in the future in which case the current >>> time >>> should be used) >> >> That seems over engineered. Accurate access_time has never >> been something NFS (and probably every other networked file system) >> could guarantee. >> >>> We have customers that demand atime support so I would say that >> >> What precisely are they demanding? >> >> That every read() from the client's cache update the atime? >> >> I get that all the time from customers and QA engineers, and >> I tell them they can use direct I/O to the server if that's >> what they think they need. >> >> And I would tell the customer that perfectly accurate atime is >> something that won't be provided with pNFS. We eliminated >> GETATTR from the set of operations a file-based data server can >> support for a reason. >> >> > > I can't be specific about the requirements but they don't require a > high level of accuracy. You can't be specific because you don't know the requirements or are unable to share them? Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 14:10: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 1IqClw-0000vD-N2; Thu, 08 Nov 2007 14:10:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqCls-0000oK-4Q for nfsv4@ietf.org; Thu, 08 Nov 2007 14:10:34 -0500 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 1IqClr-0001lR-FP for nfsv4@ietf.org; Thu, 08 Nov 2007 14:10:31 -0500 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 lA8JAOP1013208; Thu, 8 Nov 2007 14:10:24 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 8 Nov 2007 14:10:24 -0500 Received: from fs1.bhalevy.com ([172.17.133.38]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 14:10:24 -0500 Message-ID: <47335F1C.7010509@panasas.com> Date: Thu, 08 Nov 2007 21:10:20 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: [nfsv4] Re: should we allow LAYOUTCOMMIT for reads References: <309403.46319.qm@web38103.mail.mud.yahoo.com> <473329EA.5030104@panasas.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 19:10:24.0400 (UTC) FILETIME=[03E7D900:01C8223B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: email2mre-ietf@yahoo.com, Brent Welch , "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 Nov. 08, 2007, 19:48 +0200, Spencer Shepler wrote: > On Nov 8, 2007, at 9:23 AM, Benny Halevy wrote: > >> On Nov. 07, 2007, 21:13 +0200, Mike Eisler > ietf@yahoo.com> wrote: >>> --- Benny Halevy wrote: >>> >>>> On Nov. 07, 2007, 20:40 +0200, Spencer Shepler >>>> wrote: >>>>> If the only purpose of the access time field in layoutcommit is to >>>>> allow the client the ability to update it (no release of >>>> allocations >>>>> or other side -effects), wouldn't SETATTR be sufficient for the >>>> client? >>>>> Or is there concern about appropriate access in setting that >>>> attribute >>>>> where a layout based update of access time would be better? >>>> explicit setattr won't work the same way if multiple clients are >>>> reading the file concurrently as it may set the access time >>>> backwards. >>> >>> enum time_how4 { >>> SET_TO_SERVER_TIME4 = 0, >>> SET_TO_CLIENT_TIME4 = 1 >>> }; >>> >>> settime4 >>> >>> union settime4 switch (time_how4 set_it) { >>> case SET_TO_CLIENT_TIME4: >>> nfstime4 time; >>> default: >>> void; >>> }; >>> >>> The client can set set_it to SET_TO_SERVER_TIME4 when >>> it issues the SETATTR. >> OK. Then that leaves us only with our requirement for >> layout-type specific payload in LAYOUTRETURN. >> There shouldn't be any problem with adding that, right? > > So it appears from the objects I-D that the information > being transferred to the server on LAYOUTCOMMIT is the error > list. Is there a reason that this needs to move from LAYOUTCOMMIT > to LAYOUTRETURN or why the client would use LAYOUTCOMMIT in the > case of WRITEs vs. LAYOUTRETURN for READs? Obviously, I am > in need of clarity about how layout type specific data will be > used on LAYOUTRETURN, etc. lou_body is currently defined as follows in pnfs-obj-04: struct pnfs_osd_layoutupdate4 { pnfs_osd_deltaspaceused4 delta_space_used; pnfs_osd_ioerr4 ioerr<>; }; My plan is to keep only delta_space_used in pnfs_osd_layoutupdate4 for usage at LAYOUTCOMMIT time and move the ioerr to the LAYOUTRETURN args which may be used both for reads or writes. The idea is that if the client hit an I/O error it is going to return the layout anyway and will report the error details in the process. Benny > >>> As I recall saying in the pNFS review, LAYOUTCOMMIT seems to >>> be replicating functionality we already have. >>> >>>> The intention of the LAYOUTCOMMIT hint was to only set the >>>> access_time >>>> on the file if the client's reported access_time is later than the >>>> current access_time (and not in the future in which case the current >>>> time >>>> should be used) >>> That seems over engineered. Accurate access_time has never >>> been something NFS (and probably every other networked file system) >>> could guarantee. >>> >>>> We have customers that demand atime support so I would say that >>> What precisely are they demanding? >>> >>> That every read() from the client's cache update the atime? >>> >>> I get that all the time from customers and QA engineers, and >>> I tell them they can use direct I/O to the server if that's >>> what they think they need. >>> >>> And I would tell the customer that perfectly accurate atime is >>> something that won't be provided with pNFS. We eliminated >>> GETATTR from the set of operations a file-based data server can >>> support for a reason. >>> >>> >> I can't be specific about the requirements but they don't require a >> high level of accuracy. > > You can't be specific because you don't know the requirements or > are unable to share them? > > Spencer > -- Benny Halevy Software Architect Tel/Fax: +972-3-647-8340 Mobile: +972-54-802-8340 US: +1-412-203-3187 bhalevy@panasas.com Panasas, Inc. Leader in Parallel Storage www.panasas.com _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 14:36: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 1IqDBO-0000dT-TN; Thu, 08 Nov 2007 14:36:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqDBN-0000dC-LE for nfsv4@ietf.org; Thu, 08 Nov 2007 14:36:53 -0500 Received: from rv-out-0910.google.com ([209.85.198.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqDBK-0000rF-QD for nfsv4@ietf.org; Thu, 08 Nov 2007 14:36:53 -0500 Received: by rv-out-0910.google.com with SMTP id l15so223030rvb for ; Thu, 08 Nov 2007 11:36:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=JVjXIG4qfM9XN/jADgsmTWv4Hfp32ePtQEzNLn1PWGQ=; b=LiwP8BNteH1kthAmHPdXKLzu7CRD5xBuLJU+HaySPGZlU+HgsXsHJzylR5mAPOEnQ1SSrU/74VNzIEZcBm2dMQr8VOUfVYPR6o7j81nl6QsVzvknmqShksIpdjyzNtYUDtZA7acYMbhj0GKPLig7yC+ZcaDRCf9mOZs6fUH3eVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Gv4bDWbpPplZIIaUBCFL15UyQr2vB2599JaKNuAQPBErYIJ+D1654dvk8Qg18hya6obkC1dcWaYu0Fg+u1h3UHAEyPLVCadNPY+s/8qG9G+lbnabIJOYXPrPtGxRkL37rkfD0kjJmGEFysjIdquWhmQ8OMQ+EFjad7uzDJekxrM= Received: by 10.141.79.12 with SMTP id g12mr478346rvl.1194550609210; Thu, 08 Nov 2007 11:36:49 -0800 (PST) Received: from ?9.1.75.183? ( [198.4.83.52]) by mx.google.com with ESMTPS id p13sm1091172roh.2007.11.08.11.36.48 (version=SSLv3 cipher=RC4-MD5); Thu, 08 Nov 2007 11:36:48 -0800 (PST) Message-ID: <47336554.9000606@gmail.com> Date: Thu, 08 Nov 2007 11:36:52 -0800 From: Dean Hildebrand User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: email2mre-ietf@yahoo.com Subject: Re: [nfsv4] Layout Range. References: <839994.23701.qm@web38105.mail.mud.yahoo.com> In-Reply-To: <839994.23701.qm@web38105.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 Mike Eisler wrote: > I see consensus for changing LAYOUTGET to return an array of patterns. > > Sounds like a good feature for NFSv4.2. (or .3 or .4 or ...) I believe we need real world experience with pNFS before we start guessing about how people might use it and what "may" give better performance and what "may" be useful. I would prefer to see an implementation of this (and many other things) before we start extending an already pork barreled minor extension. Dean > --- Benny Halevy wrote: > > >> On Oct. 24, 2007, 23:37 +0200, Garth Goodson >> wrote: >> >>> Robert Gordon wrote: >>> >>>> On Oct 24, 2007, at 11:21 AM, Garth Goodson wrote: >>>> >>>> >>>>> Right. LAYOUTGET was designed to return a single range starting >>>>> at the offset returned covering the length returned. I believe >>>>> it is stated that the returned layout must overlap by at least >>>>> loga_minlength bytes (which must be at least 1) the requested >>>>> >> range. >> >>>>> If the minlength requirement can not be met in a single layout an >>>>> error is returned and the client is currently responsible for >>>>> >> splitting >> >>>>> that range and retrying. >>>>> >>>> I think that error would be NFS4ERR_LAYOUTTRYLATER, however we >>>> do not indicate it this is a transient issue or if the client >>>> needs to split the range and try again. >>>> >>>> >>> TRYLATER is a transient error and I think should not be returned if >>> >> a >> >>> range needs to be split due to striping issues, rather than some >>> >> type of >> >>> locking issue over a portion of the range. >>> >>> >>>>> If there are different striping patterns these should be returned >>>>> via multiple layoutgets in separate layouts. >>>>> >>>> It would seem easier to make LAYOUTGET4resok.logr_layout an array, >>>> as mike suggested. >>>> >>>> >>> I have no objection to returning an array, however I believe that a >>> >>> client will still have to handle the corner case of not retrieving >>> >> the >> >>> entire range at once (even if multiple layouts are returned), since >>> >>> there could be other factors; e.g., max_count is too small to >>> >> return all >> >>> layouts that cover that range. >>> >> Agreed. >> >> Benny >> >> >>> -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 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 14:45: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 1IqDK5-0005a0-7q; Thu, 08 Nov 2007 14:45:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqDK3-0005Yc-12 for nfsv4@ietf.org; Thu, 08 Nov 2007 14:45:51 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqDK2-0002me-DI for nfsv4@ietf.org; Thu, 08 Nov 2007 14:45:50 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA8Jjnnd004815 for ; Thu, 8 Nov 2007 19:45:49 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR700501CNPE900@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 08 Nov 2007 12:45:49 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-138-155.dsl.austtx.sbcglobal.net [71.145.138.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR7006UKDKBM8B0@mail-amer.sun.com>; Thu, 08 Nov 2007 12:45:48 -0700 (MST) Date: Thu, 08 Nov 2007 13:46:18 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Re: should we allow LAYOUTCOMMIT for reads In-reply-to: <47335F1C.7010509@panasas.com> To: Benny Halevy 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: <309403.46319.qm@web38103.mail.mud.yahoo.com> <473329EA.5030104@panasas.com> <47335F1C.7010509@panasas.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: email2mre-ietf@yahoo.com, Brent Welch , "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 Nov 8, 2007, at 1:10 PM, Benny Halevy wrote: > On Nov. 08, 2007, 19:48 +0200, Spencer Shepler > wrote: >> On Nov 8, 2007, at 9:23 AM, Benny Halevy wrote: >> >>> On Nov. 07, 2007, 21:13 +0200, Mike Eisler >> ietf@yahoo.com> wrote: >>>> --- Benny Halevy wrote: >>>> >>>>> On Nov. 07, 2007, 20:40 +0200, Spencer Shepler >>>>> wrote: >>>>>> If the only purpose of the access time field in layoutcommit >>>>>> is to >>>>>> allow the client the ability to update it (no release of >>>>> allocations >>>>>> or other side -effects), wouldn't SETATTR be sufficient for the >>>>> client? >>>>>> Or is there concern about appropriate access in setting that >>>>> attribute >>>>>> where a layout based update of access time would be better? >>>>> explicit setattr won't work the same way if multiple clients are >>>>> reading the file concurrently as it may set the access time >>>>> backwards. >>>> >>>> enum time_how4 { >>>> SET_TO_SERVER_TIME4 = 0, >>>> SET_TO_CLIENT_TIME4 = 1 >>>> }; >>>> >>>> settime4 >>>> >>>> union settime4 switch (time_how4 set_it) { >>>> case SET_TO_CLIENT_TIME4: >>>> nfstime4 time; >>>> default: >>>> void; >>>> }; >>>> >>>> The client can set set_it to SET_TO_SERVER_TIME4 when >>>> it issues the SETATTR. >>> OK. Then that leaves us only with our requirement for >>> layout-type specific payload in LAYOUTRETURN. >>> There shouldn't be any problem with adding that, right? >> >> So it appears from the objects I-D that the information >> being transferred to the server on LAYOUTCOMMIT is the error >> list. Is there a reason that this needs to move from LAYOUTCOMMIT >> to LAYOUTRETURN or why the client would use LAYOUTCOMMIT in the >> case of WRITEs vs. LAYOUTRETURN for READs? Obviously, I am >> in need of clarity about how layout type specific data will be >> used on LAYOUTRETURN, etc. > > lou_body is currently defined as follows in pnfs-obj-04: > > struct pnfs_osd_layoutupdate4 { > pnfs_osd_deltaspaceused4 delta_space_used; > pnfs_osd_ioerr4 ioerr<>; > }; > > My plan is to keep only delta_space_used in pnfs_osd_layoutupdate4 > for usage at LAYOUTCOMMIT time and move the ioerr to the LAYOUTRETURN > args which may be used both for reads or writes. > > The idea is that if the client hit an I/O error it is going to return > the layout anyway and will report the error details in the process. Okay, thanks for the clarification. It seems reasonable if we are moving the errors to the LAYOUTRETURN and thus the layout is being returned in tandem. Better place for it. I will work up a set of diffs and post them before inclusion in the I-D. This will include the removal of the loca_time_access field from LAYOUTCOMMIT. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 15:11: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 1IqDiz-0000Vf-R9; Thu, 08 Nov 2007 15:11:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqDiz-0000VZ-BQ for nfsv4@ietf.org; Thu, 08 Nov 2007 15:11:37 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqDiy-0003ez-G8 for nfsv4@ietf.org; Thu, 08 Nov 2007 15:11:37 -0500 X-IronPort-AV: E=Sophos;i="4.21,391,1188802800"; d="scan'208";a="120704850" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 08 Nov 2007 12:11:20 -0800 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 lA8KBJCv014275 for ; Thu, 8 Nov 2007 12:11:20 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 12:11:19 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 12:11:19 -0800 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: Thu, 8 Nov 2007 15:11:18 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for relative to MDS COMMIT Thread-Index: AcgiQ4W3lKpItymcQKymPGWVJlYkNg== From: "Noveck, Dave" To: X-OriginalArrivalTime: 08 Nov 2007 20:11:19.0595 (UTC) FILETIME=[869257B0:01C82243] X-Spam-Score: -4.0 (----) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [nfsv4] Proposal for relative to MDS COMMIT 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 proposing replacing the following, The flag NFL4_UFLG_COMMIT_THRU_MDS in the field nfl_util of the file layout (data type nfsv4_1_file_layout4) or the field nflh_util of the layout hint (data type nfsv4_1_file_layouthint4) is an indication from the metadata server to the client of the preferred way of performing COMMIT. If this field is TRUE, the client SHOULD send COMMIT to the metadata server instead of sending it to the same data server to which the associated WRITEs were sent. If nfl_util & NFL4_UFLG_COMMIT_THRU_MDS is TRUE, then in order to maintain the current NFSv4.1 commit and recovery model, the data servers MUST return a common writeverf verifier in all WRITE responses for a given file layout, and the metadata server's COMMIT implementation must return the same writeverf. The value of the writeverf verifier MUST be changed at the metadata server or any data server that is referenced in the layout, whenever there is a server event that can possibly lead to loss of uncommitted data. The scope of the verifier can be for a file or for the entire pNFS server. It might be more difficult for the server to maintain the verifier at the file level but the benefit is that only events that impact a given file will require recovery action. Trond comments: The whole section needs justification: there is no discussion anywhere of why a server implementor might prefer to receive COMMIT requests through the MDS. Why couldn't such a server simply perform an implicit COMMIT on LAYOUTCOMMIT since the latter has persistence guarantees anyway on the metadata? Marc Eshel to propose text. The justification for this arises from implementation considerations. As=20 long as the justification is sound, I don't think that is an issue. with: The file layout provides two alternate means of providing for the=20 commit of data written through data servers. The flag=20 NFL4_UFLG_COMMIT_THRU_MDS in the field nfl_util of the file layout (data type nfsv4_1_file_layout4) or the field nflh_util of the layout hint (data type nfsv4_1_file_layouthint4) is an indication from the metadata server to the client of the preferred way of performing COMMIT, either by sending the COMMIT to the data server or the metadata server. These two methods of dealing with the issue=20 correspond to broad styles of implementation for a pNFS server supporting the files layout type. When the flag is false, COMMIT operations are to be done to the data server to which the corresponding writes were done. This approach is most useful when striping of files is implemented as part of pNFS server, with the individual data servers each implementing=20 their own file systems. When the flag is true, COMMIT operations are done to the metadata server, rather than to the individual data servers. This approach=20 is most useful when the pNFS server is implemented on top of a=20 clustered file system. In such an implementation, sending COMMIT's to multiple data servers may result in repeated writes of metadata blocks as each individual COMMIT is executed, to the detriment of write performance. Sending a single COMMIT to the metadata server can provide more efficiency when there exists a clustered file=20 system capable of implementing such a co-ordinated COMMIT. If nfl_util & NFL4_UFLG_COMMIT_THRU_MDS is TRUE, then in order to maintain the current NFSv4.1 commit and recovery model, the data servers MUST return a common writeverf verifier in all WRITE responses for a given file layout, and the metadata server's COMMIT implementation must return the same writeverf. The value of the writeverf verifier MUST be changed at the metadata server or any data server that is referenced in the layout, whenever there is a server event that can possibly lead to loss of uncommitted data. The scope of the verifier can be for a file or for the entire pNFS server. It might be more difficult for the server to maintain the verifier at the file level but the benefit is that only events that impact a given file will require recovery action. =20 > Trond comments: > The whole section needs justification: there is no discussion anywhere > of why a server implementor might prefer to receive COMMIT requests through > the MDS.=20 I hope I've done that. > Why couldn't such a server simply perform an implicit COMMIT > on LAYOUTCOMMIT since the latter has persistence guarantees anyway on > the metadata? What happens if the data server goes down between the write and the=20 LAYOUTCOMMIT? COMMIT has the apparatus to deal with that. That's what it was designed for. =20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 15:42: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 1IqEDH-0000Dk-RC; Thu, 08 Nov 2007 15:42:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqEDH-0000DG-Dc for nfsv4@ietf.org; Thu, 08 Nov 2007 15:42:55 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqEDG-0004J2-ME for nfsv4@ietf.org; Thu, 08 Nov 2007 15:42:54 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA8Kgrqt007280 for ; Thu, 8 Nov 2007 20:42:53 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR700C01FPA8W00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Thu, 08 Nov 2007 13:42:53 -0700 (MST) Received: from jeeves.macrbg.com ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR700MJNG7HUR30@mail-amer.sun.com>; Thu, 08 Nov 2007 13:42:53 -0700 (MST) Date: Thu, 08 Nov 2007 14:42:52 -0600 From: Robert Gordon Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections In-reply-to: To: "Noveck, Dave" Message-id: <5147E031-6048-4576-9461-B4ED38431557@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.912) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: -1.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 On Nov 8, 2007, at 10:58 AM, Noveck, Dave wrote: > Clients MUST use the filehandle contained > within the layout when accessing data on NFSv4.1 data > servers. does this mean there is a corresponding change to remove this :- 14.3 File Layout Data Types. [snip] 4. nfl_fh_list. An array of data server filehandles for each list of data servers in each element of the nflda_multipath_ds_list array. The number of elements in nfl_fh_list depends on whether sparse or dense packing is being used. If sparse packing is being used, the number of elements in nfl_fh_list MUST be of three values: Zero. This means that filehandles used for each data server are the same as the filehandle returned by the OPEN operation from the metadata server. [snip] If not, then my preference would be to leave the sentence as it is now: " Clients MUST use the filehandle described within the layout when accessing data on NFSv4.1 data servers." Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 15:43: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 1IqEDS-0000Po-6K; Thu, 08 Nov 2007 15:43:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqEDQ-0000Ot-Qt for nfsv4@ietf.org; Thu, 08 Nov 2007 15:43:04 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqEDM-0002hA-6b for nfsv4@ietf.org; Thu, 08 Nov 2007 15:43:04 -0500 Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IqEDL-0000tz-Jh; Thu, 08 Nov 2007 21:42:59 +0100 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 1IqEDJ-0001tN-AB; Thu, 08 Nov 2007 21:42:57 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IqEDI-0001tD-Ue; Thu, 08 Nov 2007 21:42:57 +0100 Subject: Re: [nfsv4] Proposal for relative to MDS COMMIT From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Thu, 08 Nov 2007 15:45:39 -0500 Message-Id: <1194554740.7655.45.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.149) X-UiO-Scanned: C9DD5D8CE27DF761739A41781E84293A89F6877A X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 626 total 5014592 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Thu, 2007-11-08 at 15:11 -0500, Noveck, Dave wrote: > > Trond comments: > > The whole section needs justification: there is no discussion anywhere > > of why a server implementor might prefer to receive COMMIT requests > through > > the MDS. > > I hope I've done that. Yup. Looks a lot better. > > Why couldn't such a server simply perform an implicit COMMIT > > on LAYOUTCOMMIT since the latter has persistence guarantees anyway on > > the metadata? > > What happens if the data server goes down between the write and the > LAYOUTCOMMIT? COMMIT has the apparatus to deal with that. That's > what it was designed for. If the data server goes down, then the MDS can (and probably should) recall the layout for that fsid. This will normally trigger the same recovery procedure as a COMMIT would. In fact, for the case where the COMMIT would be sent to the MDS, the client can probably optimise better if the server issues the layout recall by fsid, since the fsid will identify exactly which server went down, and therefore which stripes need rewriting. With COMMIT, you have no info about which DS rebooted, and so the client needs to write all stripes. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 15:43: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 1IqEDr-0000nz-Fb; Thu, 08 Nov 2007 15:43:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqEDq-0000nI-2x for nfsv4@ietf.org; Thu, 08 Nov 2007 15:43:30 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqEDn-0002hp-Oa for nfsv4@ietf.org; Thu, 08 Nov 2007 15:43:30 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA8KhR47011107 for ; Thu, 8 Nov 2007 20:43:27 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR700701FW61600@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 08 Nov 2007 13:43:27 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-138-155.dsl.austtx.sbcglobal.net [71.145.138.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR700K7QG8BM0E0@mail-amer.sun.com> for nfsv4@ietf.org; Thu, 08 Nov 2007 13:43:24 -0700 (MST) Date: Thu, 08 Nov 2007 14:43:55 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Operations in NFSv4.1 (mandatory / optional) In-reply-to: <4624A550-302B-40A0-9430-6F38EB1249BD@sun.com> To: NFSv4 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: <4624A550-302B-40A0-9430-6F38EB1249BD@sun.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 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 Nov 8, 2007, at 2:44 AM, Spencer Shepler wrote: > > In the next I-D, a table will be added to summarize > the operations in the context of being mandatory or optional. > > I have attached those tables to solicit any feedback prior > to the next submission of the I-D. Thanks for the timely comments. I have updated the tables and added some introductory text to address the comments. Let me know if there are any other concerns or corrections. I would like to note that all of the callback operations are optional. This is derived from the text in section 2.10.3: "The backchannel used for callback requests from server to client, and carries CB_COMPOUND requests and responses. Whether there is a backchannel or not is a decision by the client, however many features of NFSv4.1 require a backchannel. NFSv4.1 servers MUST support backchannels." Just wanted to point that out. :-) Spencer --------- 17. Operations: mandatory or optional The following tables summarize the operations of the NFSv4.1 protocol and the corresponding designation of mandatory, optional or mandatory not to implement. The designation of mandatory not to implement is reserved for those operations that were defined in NFSv4.0 and they MUST NOT be implemented in NFSv4.1. These operations are limited to those replaced by the Sessions functionality of NFSv4.1. For the most part, the mandatory or optional designation is for the server implementation. The client is generally required to implement the operations needed for the operating environment for which it servers. For example, a read-only NFSv4.1 client would have no need to implement the WRITE operation and is not required to do so. Since this is a summary of the operations and their designation, there are subtleties that are not presented here. Therefore, if there is a question of the requirements of implementation, the operation descriptions themselves must be consulted along with other relevant explanatory text within this specification. The abbrevations used in the second and third columns of the table are defined as follows. MAND Mandatory to implement OPT Optional to implement MNI Mandatory NOT to implement For the NFSv4.1 features that are optional, the operations that support those features are optional and the server would return NFS4ERR_NOTSUPP in response to the client's use of those operations. If a optional feature is supported, it is possible that a set of operations related to the feature become mandatory to implement. The third column of the table disignates the feature(s) and if the operation is mandatory or optional in the presence of support for the feature. The optional features identified and their abbreviations are as follows: pNFS Parallel NFS FDELG File Delegations DDELG Directory Delegations Operations +----------------------+------------+--------------- +---------------+ | Operation | MAND, OPT, | Feature (MAND | Definition | | | or MNI | or OPT) | | +----------------------+------------+--------------- +---------------+ | ACCESS | MAND | | Section 18.1 | | BACKCHANNEL_CTL | MAND | | Section 18.33 | | BIND_CONN_TO_SESSION | MAND | | Section 18.34 | | CLOSE | MAND | | Section 18.2 | | COMMIT | MAND | | Section 18.3 | | CREATE | MAND | | Section 18.4 | | CREATE_SESSION | MAND | | Section 18.36 | | DELEGPURGE | OPT | FDELG (MAND) | Section 18.5 | | DELEGRETURN | OPT | FDELG, DDELG, | Section 18.6 | | | | pNFS (MAND) | | | DESTROY_CLIENTID | MAND | | Section 18.50 | | DESTROY_SESSION | MAND | | Section 18.37 | | EXCHANGE_ID | MAND | | Section 18.35 | | FREE_STATEID | MAND | | Section 18.38 | | GETATTR | MAND | | Section 18.7 | | GETDEVICEINFO | OPT | pNFS (MAND) | Section 18.40 | | GETDEVICELIST | OPT | pNFS (OPT) | Section 18.41 | | GETFH | MAND | | Section 18.8 | | GET_DIR_DELEGATION | OPT | DDELG (MAND) | Section 18.39 | | LAYOUTCOMMIT | OPT | pNFS (MAND) | Section 18.42 | | LAYOUTGET | OPT | pNFS (MAND) | Section 18.43 | | LAYOUTRETURN | OPT | pNFS (MAND) | Section 18.44 | | LINK | OPT | | Section 18.9 | | LOCK | MAND | | Section 18.10 | | LOCKT | MAND | | Section 18.11 | | LOCKU | MAND | | Section 18.12 | | LOOKUP | MAND | | Section 18.13 | | LOOKUPP | MAND | | Section 18.14 | | NVERIFY | MAND | | Section 18.15 | | OPEN | MAND | | Section 18.16 | | OPENATTR | OPT | | Section 18.17 | | OPEN_CONFIRM | MNI | | N/ A | | OPEN_DOWNGRADE | MAND | | Section 18.18 | | PUTFH | MAND | | Section 18.19 | | PUTPUBFH | MAND | | Section 18.20 | | PUTROOTFH | MAND | | Section 18.21 | | READ | MAND | | Section 18.22 | | READDIR | MAND | | Section 18.23 | | READLINK | OPT | | Section 18.24 | | RECLAIM_COMPLETE | MAND | | Section 18.51 | | RELEASE_LOCKOWNER | MNI | | N/ A | | REMOVE | MAND | | Section 18.25 | | RENAME | MAND | | Section 18.26 | | RENEW | MNI | | N/ A | | RESTOREFH | MAND | | Section 18.27 | | SAVEFH | MAND | | Section 18.28 | | SECINFO | MAND | | Section 18.29 | | SECINFO_NO_NAME | OPT (**) | | Section 18.45 | | SEQUENCE | MAND | | Section 18.46 | | SETATTR | MAND | | Section 18.30 | | SET_CLIENTID | MNI | | N/ A | | SET_CLIENTID_CONFIRM | MNI | | N/ A | | SET_SSV | MAND | | Section 18.47 | | TEST_STATEID | MAND | | Section 18.48 | | VERIFY | MAND | | Section 18.31 | | WANT_DELEGATION | OPT | | Section 18.49 | | WRITE | MAND | | Section 18.32 | +----------------------+------------+--------------- +---------------+ Callback Operations: Callback Operations +-------------------------+-----+------------------- +---------------+ | Operation | No. | Feature / | Defined in | | | | Disposition | | +-------------------------+-----+------------------- +---------------+ | CB_GETATTR | OPT | FDELG (MAND) | Section 20.1 | | CB_LAYOUTRECALL | OPT | pNFS (MAND) | Section 20.3 | | CB_NOTIFY | OPT | DDELG, pNFS | Section 20.4 | | | | (MAND) | | | CB_NOTIFY_LOCK | OPT | | Section 20.11 | | CB_PUSH_DELEG | OPT | FDELG, DDELG | Section 20.5 | | | | (OPT) | | | CB_RECALL | OPT | FDELG, DDELG, | Section 20.2 | | | | pNFS (MAND) | | | CB_RECALL_ANY | OPT | FDELG, DDELG, | Section 20.6 | | | | pNFS (MAND) | | | CB_RECALL_SLOT | OPT | FDELG, DDELG, | Section 20.8 | | | | pNFS (MAND) | | | CB_RECALLABLE_OBJ_AVAIL | OPT | DDELG, pNFS | Section 20.7 | | | | (MAND) | | | CB_SEQUENCE | OPT | FDELG, DDELG, | Section 20.9 | | | | pNFS (MAND) | | | CB_WANTS_CANCELLED | OPT | FDELG, DDELG, | Section 20.10 | | | | pNFS (MAND) | | +-------------------------+-----+------------------- +---------------+ _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 16:28: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 1IqEvf-0002EA-9H; Thu, 08 Nov 2007 16:28:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqEvd-0002Df-71 for nfsv4@ietf.org; Thu, 08 Nov 2007 16:28:45 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqEva-00049X-Gv for nfsv4@ietf.org; Thu, 08 Nov 2007 16:28:45 -0500 X-IronPort-AV: E=Sophos;i="4.21,391,1188802800"; d="scan'208";a="120727628" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 08 Nov 2007 13:28:11 -0800 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 lA8LS3IX011621; Thu, 8 Nov 2007 13:28:09 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 13:28:07 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 13:28:06 -0800 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] Proposal for relative to MDS COMMIT Date: Thu, 8 Nov 2007 16:28:05 -0500 Message-ID: In-Reply-To: <1194554740.7655.45.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposal for relative to MDS COMMIT Thread-Index: AcgiSBdlfhbPT0e2QrWqSxifa4p/wQAAdYaA From: "Noveck, Dave" To: "Trond Myklebust" X-OriginalArrivalTime: 08 Nov 2007 21:28:06.0652 (UTC) FILETIME=[409773C0:01C8224E] X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 > > What happens if the data server goes down between the write and the=20 > > LAYOUTCOMMIT? COMMIT has the apparatus to deal with that. That's > > what it was designed for. > If the data server goes down, then the MDS can (and probably should) > recall the layout for that fsid. This will normally trigger the same > recovery procedure as a COMMIT would. My head is hurting. So you do the LAYOUTCOMMIT, and if you had not done a COMMIT to the DS's before (in which case this would work but your performance would suck), the MDS would note the DS went down and return DELAY. Then it would do a layout recall and then you would do the COMMITs to the various DS's and would followup with rewrites on those you needed to. Now you are going to do the LAYOUTRETURNs but you have to the LAYOUTCOMMIT before you do the LAYOUTRETURN. Now what is making my head hurt is dealing with all the possiblities of various failures at this point. What happens if another DS fails at this point. You can't recall the LAYOUT any more. It is already recalled. Maybe there is a way around this, and the issue of preventing the DSs from being too agressive in doing COMMITs, i.e. doing them at all when there is nothing specific prompting them. But I don't see us tying this up and putting a pretty bow on it in time for a draft for the next IETF meeting. It seems to me that this option is reasonable and can be reasonably explained in the spec, and while I won't say that you cannot figure out how to avoid it, I don't know that you can do that either. My preferance would be to explain it as suggested and give the people who believe that it can be dispensed with and should be dispensed with=20 the option for arguing for that as part of last call. -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Thursday, November 08, 2007 3:46 PM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: Re: [nfsv4] Proposal for relative to MDS COMMIT On Thu, 2007-11-08 at 15:11 -0500, Noveck, Dave wrote: > > Trond comments: > > The whole section needs justification: there is no discussion anywhere > > of why a server implementor might prefer to receive COMMIT requests > through > > the MDS.=20 >=20 > I hope I've done that. Yup. Looks a lot better. > > Why couldn't such a server simply perform an implicit COMMIT > > on LAYOUTCOMMIT since the latter has persistence guarantees anyway on > > the metadata? >=20 > What happens if the data server goes down between the write and the=20 > LAYOUTCOMMIT? COMMIT has the apparatus to deal with that. That's > what it was designed for. If the data server goes down, then the MDS can (and probably should) recall the layout for that fsid. This will normally trigger the same recovery procedure as a COMMIT would. In fact, for the case where the COMMIT would be sent to the MDS, the client can probably optimise better if the server issues the layout recall by fsid, since the fsid will identify exactly which server went down, and therefore which stripes need rewriting. With COMMIT, you have no info about which DS rebooted, and so the client needs to write all stripes. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 16:40: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 1IqF6V-0003NB-JT; Thu, 08 Nov 2007 16:39:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqF6U-0003MH-5F for nfsv4@ietf.org; Thu, 08 Nov 2007 16:39:58 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqF6T-00063p-EH for nfsv4@ietf.org; Thu, 08 Nov 2007 16:39:57 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA8LduCi020847 for ; Thu, 8 Nov 2007 21:39:56 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR700E01HN9RW00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 08 Nov 2007 14:39:56 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-138-155.dsl.austtx.sbcglobal.net [71.145.138.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR700JX2IUC3C00@mail-amer.sun.com>; Thu, 08 Nov 2007 14:39:49 -0700 (MST) Date: Thu, 08 Nov 2007 15:40:19 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Re: should we allow LAYOUTCOMMIT for reads In-reply-to: To: NFSv4 Message-id: <829B1460-6B01-46D5-AB4D-B5F06B9DD6BE@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 References: <309403.46319.qm@web38103.mail.mud.yahoo.com> <473329EA.5030104@panasas.com> <47335F1C.7010509@panasas.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Benny Halevy , Brent Welch 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 Nov 8, 2007, at 1:46 PM, Spencer Shepler wrote: > > I will work up a set of diffs and post them before inclusion in > the I-D. This will include the removal of the loca_time_access > field from LAYOUTCOMMIT. Okay, here is what I have. Remove loca_time_access as noted by the "diff" notation below: 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; }; For LAYOUTRETURN, I have added the layouttype4 specific data to the "layoutreturn4" struct. struct LAYOUTRETURN4args { /* CURRENT_FH: file */ bool lora_reclaim; layoutreturn_stateid lora_recallstateid; layouttype4 lora_layout_type; layoutiomode4 lora_iomode; layoutreturn4 lora_layoutreturn; }; This is only done in the "file" case. The FSID and ALL cases of layoutreturn4 will not have layout specific data. struct layoutreturn_file4 { offset4 lrf_offset; length4 lrf_length; stateid4 lrf_stateid; +% /* layouttype4 specific data */ + opaque lrf_body<>; }; union layoutreturn4 switch(layoutreturn_type4 lr_returntype) { case LAYOUTRETURN4_FILE: layoutreturn_file4 lr_layout; default: void; }; Unless there are objections, this will show up in the next I-D. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 16:50: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 1IqFGz-0000Hl-Hl; Thu, 08 Nov 2007 16:50:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFGx-0000HQ-Ph for nfsv4@ietf.org; Thu, 08 Nov 2007 16:50:47 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqFGv-0004nZ-C3 for nfsv4@ietf.org; Thu, 08 Nov 2007 16:50:47 -0500 X-IronPort-AV: E=Sophos;i="4.21,391,1188802800"; d="scan'208";a="120734064" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 08 Nov 2007 13:50:44 -0800 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 lA8Loid7018938; Thu, 8 Nov 2007 13:50:44 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 13:50:44 -0800 Received: from exsvl03.hq.netapp.com ([10.56.8.64]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 13:50:43 -0800 Received: from [10.34.24.132] ([10.34.24.132]) by exsvl03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 13:50:43 -0800 Message-ID: <473384B3.6060103@netapp.com> Date: Thu, 08 Nov 2007 13:50:43 -0800 From: Garth Goodson User-Agent: Icedove 1.5.0.12 (X11/20070730) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: [nfsv4] deviceid4 => major/minor References: <0D547683-ACE1-4CE1-A46C-6E7BC2B48F1F@sun.com> In-Reply-To: <0D547683-ACE1-4CE1-A46C-6E7BC2B48F1F@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 21:50:43.0852 (UTC) FILETIME=[698BBCC0:01C82251] X-Spam-Score: -4.0 (----) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Spencer Shepler wrote: > > As discussed recently, there is a desire to allow for the > separation of the deviceid stateid space such that a logical > set of deviceids may be grouped and then managed or recalled > without disruption to other groupings. > > The most straightforward modification, as suggested, is to > change the current deviceid definition from: > typedef uint64_t deviceid4; > > to: > > struct deviceid4 { > uint64_t did_major; > uint64_t did_minor; > }; > > Along with this change the deviceid stateid space would > change such that there is a unique deviceid stateid > associated with each deviceid4.did_major used by the server. > How many deviceid stateid are returned by GETDEVICELIST? If just one deviceid stateid per result (as it is now) then I guess all have to have the same did_major. In this case, how does the client then do a GETDEVICELIST for devices with other did_majors (assuming they can exist)? -Garth > As a quick reminder: > > Deviceid stateids represent a delegation of the deviceid > mapping to the client. > > Upon receipt of results from GETDEVICEINFO/GETDEVICELIST, the > client holds a deviceid delegation for the returned mapping(s). > > When the mapping is no longer needed or is recalled by the server, > the client will use DELEGRETURN to signify completion. Note that > this requires a valid filehandle to be returned/updated by > GETDEVICELIST/GETDEVICELIST. > > The server may recall the deviceid mappings with the CB_RECALL > operation. > > If supported and the client desires, interest in notifications > of changes in the deviceid mappings may be provided with the > CB_NOTIFY operation. > > FREE_STATEID and TEST_STATEID may be used as with other > stateid types. > > -- > > If there aren't any obvious flaws with this approach, > I will make the changes to be included in the next update > to the draft. > > 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 Nov 08 16:53: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 1IqFJv-0002r8-2G; Thu, 08 Nov 2007 16:53:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFJt-0002qZ-BP for nfsv4@ietf.org; Thu, 08 Nov 2007 16:53:49 -0500 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqFJs-0006Y2-H6 for nfsv4@ietf.org; Thu, 08 Nov 2007 16:53:49 -0500 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IqFJr-0000Kf-Bz; Thu, 08 Nov 2007 22:53:47 +0100 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 1IqFJq-0002P5-U5; Thu, 08 Nov 2007 22:53:47 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IqFJq-0002Oz-HL; Thu, 08 Nov 2007 22:53:46 +0100 Subject: RE: [nfsv4] Proposal for relative to MDS COMMIT From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Thu, 08 Nov 2007 16:56:32 -0500 Message-Id: <1194558992.7655.70.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.107) X-UiO-Scanned: 565FC78742CF653F9150CDD34FCDDB0318D8561F X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 541 total 5015323 max/h 8345 blacklist 0 greylist 0 ratelimit 0 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 On Thu, 2007-11-08 at 16:28 -0500, Noveck, Dave wrote: > > > What happens if the data server goes down between the write and the > > > LAYOUTCOMMIT? COMMIT has the apparatus to deal with that. That's > > > what it was designed for. > > > If the data server goes down, then the MDS can (and probably should) > > recall the layout for that fsid. This will normally trigger the same > > recovery procedure as a COMMIT would. > > My head is hurting. > > So you do the LAYOUTCOMMIT, and if you had not done a COMMIT to the DS's > before (in which case this would work but your performance would suck), > the MDS would note the DS went down and return DELAY. Then it would do > a layout recall and then you would do the COMMITs to the various DS's > and would followup with rewrites on those you needed to. Bear in mind that we are only talking about the case of COMMIT-to-MDS. However, I see that I was confused. I didn't really mean a recall of the fsid, but of the deviceID. Are we, or are we not going to support recalling deviceIDs? There was some discussion about doing this, since Marc in particular wanted the ability to invalidate a deviceID without recalling the layout (the client would presumably re-issue a GETDEVICEINFO request and get directed to a new DS) but I've lost track of the status of that request. Trond > Now you are going to do the LAYOUTRETURNs but you have to the > LAYOUTCOMMIT > before you do the LAYOUTRETURN. Now what is making my head hurt is > dealing > with all the possiblities of various failures at this point. What > happens > if another DS fails at this point. You can't recall the LAYOUT any > more. > It is already recalled. > > Maybe there is a way around this, and the issue of preventing the > DSs from being too agressive in doing COMMITs, i.e. doing them at all > when there is nothing specific prompting them. But I don't see us > tying this up and putting a pretty bow on it in time for a draft for > the next IETF meeting. > > It seems to me that this option is reasonable and can be reasonably > explained in the spec, and while I won't say that you cannot figure > out how to avoid it, I don't know that you can do that either. > > My preferance would be to explain it as suggested and give the people > who believe that it can be dispensed with and should be dispensed with > the option for arguing for that as part of last call. > > -----Original Message----- > From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] > Sent: Thursday, November 08, 2007 3:46 PM > To: Noveck, Dave > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] Proposal for relative to MDS COMMIT > > > On Thu, 2007-11-08 at 15:11 -0500, Noveck, Dave wrote: > > > Trond comments: > > > The whole section needs justification: there is no discussion > anywhere > > > of why a server implementor might prefer to receive COMMIT requests > > through > > > the MDS. > > > > I hope I've done that. > > Yup. Looks a lot better. > > > > Why couldn't such a server simply perform an implicit COMMIT > > > on LAYOUTCOMMIT since the latter has persistence guarantees anyway > on > > > the metadata? > > > > What happens if the data server goes down between the write and the > > LAYOUTCOMMIT? COMMIT has the apparatus to deal with that. That's > > what it was designed for. > > If the data server goes down, then the MDS can (and probably should) > recall the layout for that fsid. This will normally trigger the same > recovery procedure as a COMMIT would. > > In fact, for the case where the COMMIT would be sent to the MDS, the > client can probably optimise better if the server issues the layout > recall by fsid, since the fsid will identify exactly which server went > down, and therefore which stripes need rewriting. > With COMMIT, you have no info about which DS rebooted, and so the client > needs to write all stripes. > > Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 17:06: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 1IqFVt-0002QR-JX; Thu, 08 Nov 2007 17:06:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqFVp-0002Q9-Rh for nfsv4@ietf.org; Thu, 08 Nov 2007 17:06:09 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqFVp-0006yM-FU for nfsv4@ietf.org; Thu, 08 Nov 2007 17:06:09 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA8M68DX003917 for ; Thu, 8 Nov 2007 22:06:08 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR700701JTR2X00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Thu, 08 Nov 2007 15:06:08 -0700 (MST) Received: from jeeves.macrbg.com ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR70046TK26F990@mail-amer.sun.com>; Thu, 08 Nov 2007 15:06:07 -0700 (MST) Date: Thu, 08 Nov 2007 16:06:06 -0600 From: Robert Gordon Subject: Re: [nfsv4] Proposal for relative to MDS COMMIT In-reply-to: To: "Noveck, Dave" Message-id: <9939951E-38AC-40B5-8288-CA39CC4F3FDB@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.912) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: -1.0 (-) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 Nov 8, 2007, at 3:28 PM, Noveck, Dave wrote: > My preferance would be to explain it as suggested and give the people > who believe that it can be dispensed with and should be dispensed with > the option for arguing for that as part of last call. I prefer your suggested text. Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 20:06: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 1IqIKe-0000vS-HB; Thu, 08 Nov 2007 20:06:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqIKd-0000vA-Hr for nfsv4@ietf.org; Thu, 08 Nov 2007 20:06:47 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqIKa-0003Tq-69 for nfsv4@ietf.org; Thu, 08 Nov 2007 20:06:47 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA916h2F005949 for ; Fri, 9 Nov 2007 01:06:43 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR700F01S4MLN00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 08 Nov 2007 18:06:43 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR700JSESF73C30@mail-amer.sun.com>; Thu, 08 Nov 2007 18:06:43 -0700 (MST) Date: Thu, 08 Nov 2007 19:07:15 -0600 From: Spencer Shepler Subject: Re: [nfsv4] deviceid4 => major/minor In-reply-to: <473384B3.6060103@netapp.com> To: Garth Goodson 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: <0D547683-ACE1-4CE1-A46C-6E7BC2B48F1F@sun.com> <473384B3.6060103@netapp.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Nov 8, 2007, at 3:50 PM, Garth Goodson wrote: > Spencer Shepler wrote: >> As discussed recently, there is a desire to allow for the >> separation of the deviceid stateid space such that a logical >> set of deviceids may be grouped and then managed or recalled >> without disruption to other groupings. >> The most straightforward modification, as suggested, is to >> change the current deviceid definition from: >> typedef uint64_t deviceid4; >> to: >> struct deviceid4 { >> uint64_t did_major; >> uint64_t did_minor; >> }; >> Along with this change the deviceid stateid space would >> change such that there is a unique deviceid stateid >> associated with each deviceid4.did_major used by the server. > > How many deviceid stateid are returned by GETDEVICELIST? > > If just one deviceid stateid per result (as it is now) then I guess > all have to have the same did_major. In this case, how does the > client then do a GETDEVICELIST for devices with other did_majors > (assuming they can exist)? Oversight; my apologies. The stateid would move into the devlist_item4 struct and the changes would look like this: ---- struct devlist_item4 { deviceid4 dli_id; stateid4 dli_stateid; device_addr4 dli_device_addr; }; struct GETDEVICELIST4resok { nfs_cookie4 gdlr_cookie; verifier4 gdlr_cookieverf; device_notification_mask4 gdlr_notification; devlist_item4 gdlr_devinfo_list<>; bool gdlr_eof; }; _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 08 20:08: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 1IqIMX-0002On-W2; Thu, 08 Nov 2007 20:08:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqIMW-0002NU-Fl for nfsv4@ietf.org; Thu, 08 Nov 2007 20:08:44 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqIMV-00063w-Lt for nfsv4@ietf.org; Thu, 08 Nov 2007 20:08:44 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA918gdg016903 for ; Fri, 9 Nov 2007 01:08:42 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR700001SIG8I00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 08 Nov 2007 18:08:42 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR700JT8SIH3C30@mail-amer.sun.com>; Thu, 08 Nov 2007 18:08:42 -0700 (MST) Date: Thu, 08 Nov 2007 19:09:13 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Proposal for relative to MDS COMMIT In-reply-to: <1194558992.7655.70.camel@heimdal.trondhjem.org> To: Trond Myklebust Message-id: <89621119-7FB0-4525-9CF3-83AB0B6628EE@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: <1194558992.7655.70.camel@heimdal.trondhjem.org> 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 On Nov 8, 2007, at 3:56 PM, Trond Myklebust wrote: > > On Thu, 2007-11-08 at 16:28 -0500, Noveck, Dave wrote: >>>> What happens if the data server goes down between the write and the >>>> LAYOUTCOMMIT? COMMIT has the apparatus to deal with that. That's >>>> what it was designed for. >> >>> If the data server goes down, then the MDS can (and probably should) >>> recall the layout for that fsid. This will normally trigger the same >>> recovery procedure as a COMMIT would. >> >> My head is hurting. >> >> So you do the LAYOUTCOMMIT, and if you had not done a COMMIT to >> the DS's >> before (in which case this would work but your performance would >> suck), >> the MDS would note the DS went down and return DELAY. Then it >> would do >> a layout recall and then you would do the COMMITs to the various DS's >> and would followup with rewrites on those you needed to. > > Bear in mind that we are only talking about the case of COMMIT-to-MDS. > > > However, I see that I was confused. I didn't really mean a recall > of the > fsid, but of the deviceID. Are we, or are we not going to support > recalling deviceIDs? > There was some discussion about doing this, since Marc in particular > wanted the ability to invalidate a deviceID without recalling the > layout > (the client would presumably re-issue a GETDEVICEINFO request and get > directed to a new DS) but I've lost track of the status of that > request. Deviceid will have a stateid that is recallable and we are closing on having deviceid split with major/minor such that the client will know the groupings of deviceids under a single stateid. See the recent threads on this topic for more detail. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From JudywertDailey@closer.com Thu Nov 08 20:40:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqIrS-0005Jh-DY; Thu, 08 Nov 2007 20:40:42 -0500 Received: from a181003.n1.vanderbilt.edu ([129.59.181.3] helo=abdulrnm.vanderbilt.edu) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqIrS-00072L-24; Thu, 08 Nov 2007 20:40:42 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host52375576.closer.com (8.13.1/8.13.1) with SMTP id 6p49J0Yl27.700311.taI.oxW.0395696859272 for ; Thu, 8 Nov 2007 19:40:06 +0600 Message-ID: From: "Jane Villa" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_C3D8_01C82271.82C07940-- From BernicereprisalFritz@askmen.com Thu Nov 08 21:31:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqJea-0005L3-6K; Thu, 08 Nov 2007 21:31:28 -0500 Received: from 66-168-184-20.dhcp.gwnt.ga.charter.com ([66.168.184.20] helo=elena.gw.totalweb.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqJeZ-0008U5-RC; Thu, 08 Nov 2007 21:31:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host76250739.askmen.com (8.13.1/8.13.1) with SMTP id ockmziPk01.581893.2LW.y1U.1728708175216 for ; Thu, 8 Nov 2007 21:31:12 +0500 Message-ID: <116f501c82278$a6aa2ed0$6601a8c0@elena> From: "Cathy Wills" To: Subject: Your family Date: Thu, 8 Nov 2007 21:31:12 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_116F1_01C82278.A6AA2ED0" 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: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_116F1_01C82278.A6AA2ED0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_116F1_01C82278.A6AA2ED0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_116F1_01C82278.A6AA2ED0-- From NeldacouncilmenBoykin@flickr.com Fri Nov 09 02:11:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqO1q-0007KC-RE; Fri, 09 Nov 2007 02:11:46 -0500 Received: from [78.187.18.95] (helo=fatih) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqO1q-0007UA-8q; Fri, 09 Nov 2007 02:11:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host54221914.flickr.com (8.13.1/8.13.1) with SMTP id RLzcey4P64.413015.gBb.nZd.0902736421871 for ; Fri, 9 Nov 2007 09:11:18 -0200 Message-ID: <1da3f01c8229f$caabcba0$0802a8c0@fatih> From: "Hilary Corona" To: Subject: Your order approved Date: Fri, 9 Nov 2007 09:11:18 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1DA3B_01C8229F.CAABCBA0" 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: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_1DA3B_01C8229F.CAABCBA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_1DA3B_01C8229F.CAABCBA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1DA3B_01C8229F.CAABCBA0-- From FrancrookBonds@rotax-owner.com Fri Nov 09 03:16:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqP21-0002Wz-V1; Fri, 09 Nov 2007 03:16:02 -0500 Received: from 250.red-83-49-95.dynamicip.rima-tde.net ([83.49.95.250] helo=cf51b6a9c93b458) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqP21-0000oP-Dg; Fri, 09 Nov 2007 03:16:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host61310427.rotax-owner.com (8.13.1/8.13.1) with SMTP id tPp8k0Zk99.144962.ZHX.oM3.9677663114586 for ; Fri, 9 Nov 2007 09:15:21 -0100 Message-ID: <9db5c01c822a8$bc39bdd0$6402a8c0@cf51b6a9c93b458> From: "Alissa Rhoades" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_9DB58_01C822A8.BC39BDD0-- From HerminiainsuppressibleChampagne@switchboard.com Fri Nov 09 04:18:13 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqQ0D-0006ij-5V; Fri, 09 Nov 2007 04:18:13 -0500 Received: from [88.254.198.132] (helo=reis) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqQ0B-0003IX-EG; Fri, 09 Nov 2007 04:18:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host70127326.switchboard.com (8.13.1/8.13.1) with SMTP id 5lncPvnL83.545650.WSP.vvb.4682428413773 for ; Fri, 9 Nov 2007 11:17:24 -0200 Message-ID: From: "Pansy Reagan" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_DCD6_01C822B1.6D1E7ED0-- From DaleempiricWoods@britneyimages.com Fri Nov 09 05:17:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqQvC-0001aT-51; Fri, 09 Nov 2007 05:17:06 -0500 Received: from cpe-74-75-119-33.maine.res.rr.com ([74.75.119.33] helo=your1a4d29f243.maine.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqQvB-000506-Ql; Fri, 09 Nov 2007 05:17:06 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host63906716.britneyimages.com (8.13.1/8.13.1) with SMTP id 06EX1AYl84.302658.uDu.rbq.5502961508543 for ; Fri, 9 Nov 2007 05:17:02 +0500 Message-ID: From: "Jeff Fisher" To: Subject: Your health Date: Fri, 9 Nov 2007 05:17:02 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_C547D_01C822B9.BB837D70" 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: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_C547D_01C822B9.BB837D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_C547D_01C822B9.BB837D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_C547D_01C822B9.BB837D70-- From MorgantwaConley@howstuffworks.com Fri Nov 09 08:43:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqU8s-0005aL-9H; Fri, 09 Nov 2007 08:43:26 -0500 Received: from host200-247-static.73-81-b.business.telecomitalia.it ([81.73.247.200] helo=alfredov491e3a) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqU8r-0002Y3-EJ; Fri, 09 Nov 2007 08:43:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host87773067.howstuffworks.com (8.13.1/8.13.1) with SMTP id VtbpdEAB80.907521.xGx.DDE.5750931310576 for ; Fri, 9 Nov 2007 14:42:30 -0100 Message-ID: From: "Trent Hood" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_F9839_01C822D6.6FAACF30-- From nfsv4-bounces@ietf.org Fri Nov 09 10:26:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqVl3-0002nq-D5; Fri, 09 Nov 2007 10:26:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqVl1-0002ih-Lt for nfsv4@ietf.org; Fri, 09 Nov 2007 10:26:55 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqVl1-0006Hl-9K for nfsv4@ietf.org; Fri, 09 Nov 2007 10:26:55 -0500 X-IronPort-AV: E=Sophos;i="4.21,395,1188802800"; d="scan'208";a="120934485" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 09 Nov 2007 07:26:54 -0800 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 lA9FQqiB002080; Fri, 9 Nov 2007 07:26:52 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 07:26:53 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 07:26:52 -0800 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] Proposed resolutions for some pnfs-related[[Comment]]sections Date: Fri, 9 Nov 2007 10:26:49 -0500 Message-ID: In-Reply-To: <5147E031-6048-4576-9461-B4ED38431557@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections Thread-Index: AcgiR/5ovo7tvyVBRTijLSfExaHuBAAnNUuw From: "Noveck, Dave" To: "Robert Gordon" X-OriginalArrivalTime: 09 Nov 2007 15:26:52.0550 (UTC) FILETIME=[F43BB260:01C822E4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 How about "specified by the layout"?=20 -----Original Message----- From: Robert Gordon [mailto:Robert.Gordon@Sun.COM]=20 Sent: Thursday, November 08, 2007 3:43 PM To: Noveck, Dave Cc: Muntz, Daniel; nfsv4@ietf.org Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections On Nov 8, 2007, at 10:58 AM, Noveck, Dave wrote: > Clients MUST use the filehandle contained within the layout when=20 > accessing data on NFSv4.1 data servers. does this mean there is a corresponding change to remove this :- 14.3 File Layout Data Types. [snip] 4. nfl_fh_list. An array of data server filehandles for each list of data servers in each element of the nflda_multipath_ds_list array. The number of elements in nfl_fh_list depends on whether sparse or dense packing is being used. If sparse packing is being used, the number of elements in nfl_fh_list MUST be of three values: Zero. This means that filehandles used for each data server are the same as the filehandle returned by the OPEN operation from the metadata server. [snip] If not, then my preference would be to leave the sentence as it is now: " Clients MUST use the filehandle described within the layout when accessing data on NFSv4.1 data servers." Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From HuntergulfSolomon@washingtonpost.com Fri Nov 09 10:32:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqVqU-0002Co-J2; Fri, 09 Nov 2007 10:32:34 -0500 Received: from 82.131.183.26.pool.invitel.hu ([82.131.183.26] helo=eg5810d33797c9) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqVqT-0006c1-Jl; Fri, 09 Nov 2007 10:32:34 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host64140381.washingtonpost.com (8.13.1/8.13.1) with SMTP id zeRCW1V696.839383.e9U.oAF.2633199787082 for ; Fri, 9 Nov 2007 16:31:42 -0100 Message-ID: <2afb01c822e5$bc2d4e00$c400a8c0@eg5810d33797c9> From: "Irwin Woodward" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_2AF7_01C822E5.BC2D4E00-- From nfsv4-bounces@ietf.org Fri Nov 09 10:55: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 1IqWD4-0003rK-Vj; Fri, 09 Nov 2007 10:55:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWD3-0003p1-Jd for nfsv4@ietf.org; Fri, 09 Nov 2007 10:55:53 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqWD2-0007gr-FC for nfsv4@ietf.org; Fri, 09 Nov 2007 10:55:53 -0500 X-IronPort-AV: E=Sophos;i="4.21,395,1188802800"; d="scan'208";a="120941716" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 09 Nov 2007 07:55:51 -0800 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 lA9FtpfX011743; Fri, 9 Nov 2007 07:55:51 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 07:55:51 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 07:55:50 -0800 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] Proposal for relative to MDS COMMIT Date: Fri, 9 Nov 2007 10:55:48 -0500 Message-ID: In-Reply-To: <1194558992.7655.70.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Proposal for relative to MDS COMMIT Thread-Index: AcgiUe8s9gtUHMG+RC2mEfzCU7oOEAAlFo8A From: "Noveck, Dave" To: "Trond Myklebust" X-OriginalArrivalTime: 09 Nov 2007 15:55:50.0775 (UTC) FILETIME=[004BC870:01C822E9] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 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 preferance would be to explain it as suggested and give the people=20 > who believe that it can be dispensed with and should be dispensed with > the option for arguing for that as part of last call.=20 In the absence of violent objections, I'm going ahead and putting=20 the text discussed into the spec. > However, I see that I was confused. I didn't really mean a recall of=20 > the fsid, but of the deviceID. Are we, or are we not going to support=20 > recalling deviceIDs? I can't predict the future. The only thing I can do (barely) is to=20 read the current version of the spec based on the CVS repository and in there I don't see any provision for recalling a specific device (and somehow implicitly recalling all layout segment for that device which it seems like you are depending on). > There was some discussion about doing this, since Marc in particular=20 > wanted the ability to invalidate a deviceID without recalling the layout=20 > (the client would presumably re-issue a GETDEVICEINFO request and get=20 > directed to a new DS) but I've lost track of the status of that request. I think that that is the notify. Device maps can also be recalled but there you are recalling all device with a given major id which may be too coarse-grained for what you want (or you may be able to arrange things so it isn't). The effect on=20 existing layouts (whether there is an implicit recall) is not clear at all. One problem is that although by giving device maps stateids, we have implicitly provided a recall mechanism, the text for CB_RECALL=20 only mentions recall of delegations, and so the status and semantics of recalls of device maps isn't very clear. I'm also having trouble with this text: Device ID mappings represent another form of stateid Section 8.2.1. The GETDEVICEINFO and GETDEVICELIST operations each return a device stateid.=20 My assumption is one stateid per major device.=20 Like file delegations, the device stateid is recallable. A recall of the device stateid will remove or invalidate the device ID mappings=20 are "remove" and "invalidate" intended to be synonyms or are these two different things which can be done? as well as lease expiration. =20 Huh? The GETDEVICEINFO and GETDEVICELIST operations update the current filehandle to facilitate the recall of the device stateid.=20 I've already asked about this with regard to text for the ops GETDEVICEINFO and GETDEVICELIST. I still have no clue what is intended. I'm not sure but if look to me like to do what you want the the MDS=20 would have to do layout recalls on each of the individual stripes=20 that the device covered. -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Thursday, November 08, 2007 4:57 PM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: RE: [nfsv4] Proposal for relative to MDS COMMIT On Thu, 2007-11-08 at 16:28 -0500, Noveck, Dave wrote: > > > What happens if the data server goes down between the write and=20 > > > the LAYOUTCOMMIT? COMMIT has the apparatus to deal with that. =20 > > > That's what it was designed for. >=20 > > If the data server goes down, then the MDS can (and probably should) > > recall the layout for that fsid. This will normally trigger the same > > recovery procedure as a COMMIT would. >=20 > My head is hurting. >=20 > So you do the LAYOUTCOMMIT, and if you had not done a COMMIT to the=20 > DS's before (in which case this would work but your performance would=20 > suck), the MDS would note the DS went down and return DELAY. Then it=20 > would do a layout recall and then you would do the COMMITs to the=20 > various DS's and would followup with rewrites on those you needed to. Bear in mind that we are only talking about the case of COMMIT-to-MDS. However, I see that I was confused. I didn't really mean a recall of the fsid, but of the deviceID. Are we, or are we not going to support recalling deviceIDs? There was some discussion about doing this, since Marc in particular wanted the ability to invalidate a deviceID without recalling the layout (the client would presumably re-issue a GETDEVICEINFO request and get directed to a new DS) but I've lost track of the status of that request. Trond > Now you are going to do the LAYOUTRETURNs but you have to the=20 > LAYOUTCOMMIT before you do the LAYOUTRETURN. Now what is making my=20 > head hurt is dealing with all the possiblities of various failures at=20 > this point. What happens if another DS fails at this point. You=20 > can't recall the LAYOUT any more. > It is already recalled. >=20 > Maybe there is a way around this, and the issue of preventing the DSs=20 > from being too agressive in doing COMMITs, i.e. doing them at all when > there is nothing specific prompting them. But I don't see us tying=20 > this up and putting a pretty bow on it in time for a draft for the=20 > next IETF meeting. >=20 > It seems to me that this option is reasonable and can be reasonably=20 > explained in the spec, and while I won't say that you cannot figure=20 > out how to avoid it, I don't know that you can do that either. >=20 > My preferance would be to explain it as suggested and give the people=20 > who believe that it can be dispensed with and should be dispensed with > the option for arguing for that as part of last call. >=20 > -----Original Message----- > From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] > Sent: Thursday, November 08, 2007 3:46 PM > To: Noveck, Dave > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] Proposal for relative to MDS COMMIT >=20 >=20 > On Thu, 2007-11-08 at 15:11 -0500, Noveck, Dave wrote: > > > Trond comments: > > > The whole section needs justification: there is no discussion > anywhere > > > of why a server implementor might prefer to receive COMMIT=20 > > > requests > > through > > > the MDS.=20 > >=20 > > I hope I've done that. >=20 > Yup. Looks a lot better. >=20 > > > Why couldn't such a server simply perform an implicit COMMIT on=20 > > > LAYOUTCOMMIT since the latter has persistence guarantees anyway > on > > > the metadata? > >=20 > > What happens if the data server goes down between the write and the=20 > > LAYOUTCOMMIT? COMMIT has the apparatus to deal with that. That's=20 > > what it was designed for. >=20 > If the data server goes down, then the MDS can (and probably should)=20 > recall the layout for that fsid. This will normally trigger the same=20 > recovery procedure as a COMMIT would. >=20 > In fact, for the case where the COMMIT would be sent to the MDS, the=20 > client can probably optimise better if the server issues the layout=20 > recall by fsid, since the fsid will identify exactly which server went > down, and therefore which stripes need rewriting. > With COMMIT, you have no info about which DS rebooted, and so the=20 > client needs to write all stripes. >=20 > Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 09 12: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 1IqXtR-0000yD-6X; Fri, 09 Nov 2007 12:43:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqXtP-0000xO-NR for nfsv4@ietf.org; Fri, 09 Nov 2007 12:43:43 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqXtP-00046r-B5 for nfsv4@ietf.org; Fri, 09 Nov 2007 12:43:43 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA9HhgP1029804 for ; Fri, 9 Nov 2007 17:43:42 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR900B010UHVN00@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Fri, 09 Nov 2007 10:43:42 -0700 (MST) Received: from jeeves.macrbg.com ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR90094I2JHJLG0@mail-amer.sun.com>; Fri, 09 Nov 2007 10:42:53 -0700 (MST) Date: Fri, 09 Nov 2007 11:42:52 -0600 From: Robert Gordon Subject: Re: [nfsv4] Proposed resolutions for some pnfs-related[[Comment]]sections In-reply-to: To: "Noveck, Dave" Message-id: <7BBE3773-5BA0-4688-A0EE-D6738823B502@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.912) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: -1.0 (-) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Nov 9, 2007, at 9:26 AM, Noveck, Dave wrote: > How about "specified by the layout"? Love it ! :-) Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 09 15:33: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 1IqaXy-0004p0-0r; Fri, 09 Nov 2007 15:33:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqaXx-0004oq-9D for nfsv4@ietf.org; Fri, 09 Nov 2007 15:33:45 -0500 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqaXw-0003XX-V0 for nfsv4@ietf.org; Fri, 09 Nov 2007 15:33:45 -0500 Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IqaXw-0002KS-78 for nfsv4@ietf.org; Fri, 09 Nov 2007 21:33:44 +0100 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 1IqaXv-0003co-Sw for nfsv4@ietf.org; Fri, 09 Nov 2007 21:33:44 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IqaXv-0003ck-G4 for nfsv4@ietf.org; Fri, 09 Nov 2007 21:33:43 +0100 From: Trond Myklebust To: nfsv4@ietf.org Content-Type: text/plain Date: Fri, 09 Nov 2007 15:36:56 -0500 Message-Id: <1194640616.7459.96.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.101) X-UiO-Scanned: 36B7BF869709D743B320D1DD2D76201112134648 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 169 total 5036469 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [nfsv4] Synopsis + OP description missing for RELEASE_LOCKOWNER 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 It appears to have been lost between RFC3530 and draft 15. Cheers Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 09 15:49: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 1Iqan8-00088H-Uo; Fri, 09 Nov 2007 15:49:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqan7-000886-MC for nfsv4@ietf.org; Fri, 09 Nov 2007 15:49:25 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iqan7-0004OH-A3 for nfsv4@ietf.org; Fri, 09 Nov 2007 15:49:25 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA9KnO9x018662 for ; Fri, 9 Nov 2007 20:49:24 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JR900A01AU2ZS00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Fri, 09 Nov 2007 13:49:24 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-138-155.dsl.austtx.sbcglobal.net [71.145.138.155]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JR900J10B60O7D0@mail-amer.sun.com>; Fri, 09 Nov 2007 13:49:12 -0700 (MST) Date: Fri, 09 Nov 2007 14:49:44 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Synopsis + OP description missing for RELEASE_LOCKOWNER In-reply-to: <1194640616.7459.96.camel@heimdal.trondhjem.org> To: Trond Myklebust 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: <1194640616.7459.96.camel@heimdal.trondhjem.org> X-Spam-Score: -1.0 (-) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Nov 9, 2007, at 2:36 PM, Trond Myklebust wrote: > It appears to have been lost between RFC3530 and draft 15. This section: 8.8. Vestigial Locking Infrastructure From V4.0 covers the removal of RELEASE_LOCKOWNER from NFSv4.1. It is now mandatory not to implement and therefore not specified in the draft. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From BethanyruddyLeal@williecrawford.com Fri Nov 09 15:59:17 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqawf-0005cO-EE; Fri, 09 Nov 2007 15:59:17 -0500 Received: from [190.152.30.107] (helo=uno) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqawP-0004lX-KS; Fri, 09 Nov 2007 15:59:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host77940618.williecrawford.com (8.13.1/8.13.1) with SMTP id lU3w68Aa93.169990.c8x.ORY.1115897035192 for ; Fri, 9 Nov 2007 15:58:28 +0500 Message-ID: <46e4501c82313$595d80f0$0a01a8c0@Uno> From: "Robyn Carlisle" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_46E41_01C82313.595D80F0-- From nfsv4-bounces@ietf.org Fri Nov 09 16:01: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 1Iqaz5-0000Ta-Fz; Fri, 09 Nov 2007 16:01:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqaz4-0000SC-6X for nfsv4@ietf.org; Fri, 09 Nov 2007 16:01:46 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iqaz0-0007OR-MX for nfsv4@ietf.org; Fri, 09 Nov 2007 16:01:46 -0500 Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Iqaz0-0007qS-0E; Fri, 09 Nov 2007 22:01:42 +0100 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 1Iqayz-0007ET-OD; Fri, 09 Nov 2007 22:01:41 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Iqayz-0007EK-Bz; Fri, 09 Nov 2007 22:01:41 +0100 Subject: Re: [nfsv4] Synopsis + OP description missing for RELEASE_LOCKOWNER From: Trond Myklebust To: Spencer Shepler In-Reply-To: References: <1194640616.7459.96.camel@heimdal.trondhjem.org> Content-Type: text/plain Date: Fri, 09 Nov 2007 16:04:54 -0500 Message-Id: <1194642294.7459.101.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.137) X-UiO-Scanned: 24D979C34657C95ADE0F825B091F20A31925633A X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 14 total 5036673 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Fri, 2007-11-09 at 14:49 -0600, Spencer Shepler wrote: > On Nov 9, 2007, at 2:36 PM, Trond Myklebust wrote: > > > It appears to have been lost between RFC3530 and draft 15. > > This section: > > 8.8. Vestigial Locking Infrastructure From V4.0 > > covers the removal of RELEASE_LOCKOWNER from NFSv4.1. > It is now mandatory not to implement and therefore not > specified in the draft. Err... So why are we concerned about which error values it should return? Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 09 16:18: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 1IqbF7-0005oe-Pl; Fri, 09 Nov 2007 16:18:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqbF6-0005oO-AC for nfsv4@ietf.org; Fri, 09 Nov 2007 16:18:20 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqbF2-00080v-Tf for nfsv4@ietf.org; Fri, 09 Nov 2007 16:18:20 -0500 X-IronPort-AV: E=Sophos;i="4.21,397,1188802800"; d="scan'208";a="121030326" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 09 Nov 2007 13:18:16 -0800 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 lA9LIETP008530; Fri, 9 Nov 2007 13:18:15 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 13:18:15 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 13:18:15 -0800 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] Synopsis + OP description missing for RELEASE_LOCKOWNER Date: Fri, 9 Nov 2007 16:18:13 -0500 Message-ID: In-Reply-To: <1194642294.7459.101.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Synopsis + OP description missing for RELEASE_LOCKOWNER Thread-Index: AcgjE9mr21+qcM2AQuuZpPasQsJblQAAeRcw From: "Noveck, Dave" To: "Trond Myklebust" , "Spencer Shepler" X-OriginalArrivalTime: 09 Nov 2007 21:18:15.0069 (UTC) FILETIME=[0A64CCD0:01C82316] X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 The short, but not very good answer, is "because it was in the xml=20 table we started with." In my version, I've deleted all the errors for it except NFS4ERR_NOTSUPP which is what I think we should return given it mandatory to not implement. -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Friday, November 09, 2007 4:05 PM To: Spencer Shepler Cc: nfsv4@ietf.org Subject: Re: [nfsv4] Synopsis + OP description missing for RELEASE_LOCKOWNER On Fri, 2007-11-09 at 14:49 -0600, Spencer Shepler wrote: > On Nov 9, 2007, at 2:36 PM, Trond Myklebust wrote: >=20 > > It appears to have been lost between RFC3530 and draft 15. >=20 > This section: >=20 > 8.8. Vestigial Locking Infrastructure From V4.0 >=20 > covers the removal of RELEASE_LOCKOWNER from NFSv4.1. > It is now mandatory not to implement and therefore not > specified in the draft. Err... So why are we concerned about which error values it should return? 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 Fri Nov 09 16: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 1IqbKS-0002Mb-JA; Fri, 09 Nov 2007 16:23:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqbKR-0002Cu-1T for nfsv4@ietf.org; Fri, 09 Nov 2007 16:23:51 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqbKN-0008CW-Gj for nfsv4@ietf.org; Fri, 09 Nov 2007 16:23:51 -0500 Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IqbKL-0004lg-Uq; Fri, 09 Nov 2007 22:23:45 +0100 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 1IqbKL-0008CU-DA; Fri, 09 Nov 2007 22:23:45 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IqbKK-0008CK-V8; Fri, 09 Nov 2007 22:23:45 +0100 Subject: RE: [nfsv4] Synopsis + OP description missing for RELEASE_LOCKOWNER From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Fri, 09 Nov 2007 16:26:59 -0500 Message-Id: <1194643619.7459.109.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.110) X-UiO-Scanned: 2C729876F4695F48616D3596B43A66B206E05CE1 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 215 total 5036874 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 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 On Fri, 2007-11-09 at 16:18 -0500, Noveck, Dave wrote: > The short, but not very good answer, is "because it was in the xml > table we started with." > > In my version, I've deleted all the errors for it except NFS4ERR_NOTSUPP > > which is what I think we should return given it mandatory to not > implement. Agreed > -----Original Message----- > From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] > Sent: Friday, November 09, 2007 4:05 PM > To: Spencer Shepler > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] Synopsis + OP description missing for > RELEASE_LOCKOWNER > > > > On Fri, 2007-11-09 at 14:49 -0600, Spencer Shepler wrote: > > On Nov 9, 2007, at 2:36 PM, Trond Myklebust wrote: > > > > > It appears to have been lost between RFC3530 and draft 15. > > > > This section: > > > > 8.8. Vestigial Locking Infrastructure From V4.0 > > > > covers the removal of RELEASE_LOCKOWNER from NFSv4.1. > > It is now mandatory not to implement and therefore not > > specified in the draft. > > Err... So why are we concerned about which error values it should > return? > > 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 Estrada85@yahoo.com Fri Nov 09 17:34:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqcQV-0000yf-Af for nfsv4-archive@lists.ietf.org; Fri, 09 Nov 2007 17:34:11 -0500 Received: from cpc5-midd3-0-0-cust139.midd.cable.ntl.com ([82.1.164.140] helo=yahoo.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqcQT-0008B3-Kv for nfsv4-archive@lists.ietf.org; Fri, 09 Nov 2007 17:34:11 -0500 Message-ID: <001b01c82320$98746670$026db014@simms> From: "Mia Scallen" To: "nfsv4-archive" Subject: a girl to be yours in here found Date: Fri, 9 Nov 2007 22:33:48 +0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2720.1106 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Looking to meet up with the local bar slut? Well she is looking for you as well. Horny single girls in your area who are looking for no strings attached fun. Hop inside and find yourself a horny little fuck buddy. http://wheredatin.com/ From nfsv4-bounces@ietf.org Fri Nov 09 18:15: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 1Iqd4O-0007ud-Cj; Fri, 09 Nov 2007 18:15:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqd4M-0007u1-Ux for nfsv4@ietf.org; Fri, 09 Nov 2007 18:15:22 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iqd4J-0003CE-N5 for nfsv4@ietf.org; Fri, 09 Nov 2007 18:15:22 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lA9NFJpo026387 for ; Fri, 9 Nov 2007 23:15:19 GMT Received: from leviathan.central.sun.com (leviathan.Central.Sun.COM [129.153.128.98]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lA9NF8T0017627 for ; Fri, 9 Nov 2007 16:15:08 -0700 (MST) Received: from leviathan.central.sun.com (localhost [127.0.0.1]) by leviathan.central.sun.com (8.14.0+Sun/8.14.0) with ESMTP id lA9NF8Xw029307; Fri, 9 Nov 2007 17:15:08 -0600 (CST) Received: (from rmesta@localhost) by leviathan.central.sun.com (8.14.0+Sun/8.14.0/Submit) id lA9NF7BG029306; Fri, 9 Nov 2007 17:15:07 -0600 (CST) X-Authentication-Warning: leviathan.central.sun.com: rmesta set sender to Ricardo.Mesta@Sun.COM using -f Date: Fri, 9 Nov 2007 17:15:07 -0600 From: Rick Mesta To: nfsv4@ietf.org Message-ID: <20071109231507.GB29258@leviathan.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Spam-Score: -1.0 (-) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [nfsv4] DESTROY_SESSION Errors X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rick Mesta List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Hi folks... While working on the server side DESTROY_SESSION implementation (draft-15), I notice the following as the only possible valid return codes for DESTROY_SESSION: DESTROY_SESSION NFS4ERR_BACK_CHAN_BUSY, NFS4ERR_BADSESSION, NFS4ERR_DEADSESSION, NFS4ERR_STALE_CLIENTID However, section 18.37.4 does not specify which of the above should be used in case the cred of the DESTROY_SESSION request does not match the cred of the session being targetted for destruction (of course, depending on state prot flavor). Should there be an additional error here for such case (e.g. NFS4ERR_PERM) ? Thx, rick _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From HaroldcheckmateBailey@peopleenespanol.com Fri Nov 09 21:29:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqg6A-0002Tn-2Y; Fri, 09 Nov 2007 21:29:26 -0500 Received: from pool-72-72-238-195.altnpa.east.verizon.net ([72.72.238.195] helo=harryok54f54y6.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iqg69-0007LW-Px; Fri, 09 Nov 2007 21:29:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host72480797.peopleenespanol.com (8.13.1/8.13.1) with SMTP id B88XZ3xo80.077128.DRg.PWD.6435615238651 for ; Sat, 10 Nov 2007 21:27:37 +0500 Message-ID: <4d9fa01c8240a$7b4dd370$2e01a8c0@harryok54f54y6> From: "Gerald Bell" To: Subject: Your family Date: Sat, 10 Nov 2007 21:27:37 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4D9F6_01C8240A.7B4DD370" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_4D9F6_01C8240A.7B4DD370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_4D9F6_01C8240A.7B4DD370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_4D9F6_01C8240A.7B4DD370-- From nfsv4-bounces@ietf.org Fri Nov 09 21:57: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 1IqgXC-00033h-P6; Fri, 09 Nov 2007 21:57:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqgXA-00031n-Gx for nfsv4@ietf.org; Fri, 09 Nov 2007 21:57:20 -0500 Received: from web38112.mail.mud.yahoo.com ([209.191.124.139]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IqgX8-0000nQ-4k for nfsv4@ietf.org; Fri, 09 Nov 2007 21:57:20 -0500 Received: (qmail 87261 invoked by uid 60001); 10 Nov 2007 02:57:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Te033HZ9Zv6sBsvCHt+G8CVpuhQeemvhxZF6l1vQzNV+/4YpHbytsAXoNp92G1jP5pM5yPZwh7jIchba6IGGUQ9N9pWM+xWQfX2vQv6xq1EgRRWc8fOs4Ml9eV2QWrfLf8c2CdPVjtFlRjNYgt33kgXL73v/59+J3gv97aXcQ1U=; X-YMail-OSG: 0JVJS48VM1mx4MjluNEZ9rxjXhAIhi05Lj8.fQjyCx5BXjrYCKRNHKMp8WVi7zsJmSYZnGQkaCWpLsDhprrFVP1kqFu99L3AQJ0GeVYJhIVI9KojPkw- Received: from [198.95.226.230] by web38112.mail.mud.yahoo.com via HTTP; Fri, 09 Nov 2007 18:57:17 PST Date: Fri, 9 Nov 2007 18:57:17 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] DESTROY_SESSION Errors To: Rick Mesta , nfsv4@ietf.org In-Reply-To: <20071109231507.GB29258@leviathan.central.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <601608.86625.qm@web38112.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I agree that NFS4ERR_PERM is the correct error for Rick's scenario. --- Rick Mesta wrote: > > Hi folks... > > While working on the server side DESTROY_SESSION implementation > (draft-15), I notice the following as the only possible valid > return codes for DESTROY_SESSION: > > DESTROY_SESSION NFS4ERR_BACK_CHAN_BUSY, > NFS4ERR_BADSESSION, > NFS4ERR_DEADSESSION, > NFS4ERR_STALE_CLIENTID > > However, section 18.37.4 does not specify which of the above > should be used in case the cred of the DESTROY_SESSION request > does not match the cred of the session being targetted for > destruction (of course, depending on state prot flavor). > > Should there be an additional error here for such case (e.g. > NFS4ERR_PERM) ? > > Thx, > 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 Fri Nov 09 21:59: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 1IqgZg-0004Hg-RU; Fri, 09 Nov 2007 21:59:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqgZg-0004HZ-Fu for nfsv4@ietf.org; Fri, 09 Nov 2007 21:59:56 -0500 Received: from web38105.mail.mud.yahoo.com ([209.191.124.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IqgZe-0000qB-1G for nfsv4@ietf.org; Fri, 09 Nov 2007 21:59:56 -0500 Received: (qmail 94825 invoked by uid 60001); 10 Nov 2007 02:59:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=uOaXCOdT9Wx7deCtzgdBe2SIFOQwD4YKLtai9BX9wntvk0A7m+sD2H7NJ2VxBkZmu2Fuf0NwDqFObFlw/CR4exCgJXTKvJZwe7wn+iMDMPgt+xeT06JKlhjYShdZQdZot9ou1H2dQ2TEVhM5gT/C7pEwjop55jdq6GP+beVV2VU=; X-YMail-OSG: fRSrqR8VM1mlxEh99YNJIFZoVUuYdjR2mcFo77oayQwuDkaCe6xa4akg8oEe.LyRfF.TV6M6hHhyIdX.sJWoRbYw_rRPSaNpYGZc0Drd7kr8f2KkBqo- Received: from [198.95.226.230] by web38105.mail.mud.yahoo.com via HTTP; Fri, 09 Nov 2007 18:59:53 PST Date: Fri, 9 Nov 2007 18:59:53 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] issue 164 : Can a replier send a reply on a connection other than the one the requester sent the request on? To: nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <559152.94818.qm@web38105.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Talpey, Thomas" wrote: > The problem isn't actually sending on a broken connection. That's > the good case - the reply isn't going anywhere and there is no issue > of misdirecting it. The issue is when there *is* a connection, but > it's > the wrong one. > > When implementing to sessions, the server implementations so far > have all referenced the session from the in-progress request. This is > very convenient, as the session contains all the server context > needed > to execute the request, including the reply cache, the RPC endpoint, > and the clientid. The thing about the session is that it's an NFS > layer > object, which references an RPC object, which in turn contains > the TCP connection. > > If that TCP connection changes, there's no existing API in most > systems > to signal that to NFS - all the upper layer can do is send and There's probably no existing API for implementating sessions either. By specifying this issue as a MUST NOT, that guides the design of the API. Most existing NFS/TCP servers have a link to the connection end point attached to the request so I don't see why this is ahrd. > hopefully > get an error. To fix this, either the local RPC has to change, or > some > kind of exposure of the socket, and a reference, needs to be taken. > > There were other issues in the early sessions spec related to this. > You may recall it had channel objects, and a binding operation for > connections. These ops basically "registered" the TCP socket with > NFS. But this was hard for both implementations, and even harder > for them to propagate state. So it was modified to what you see > today. > > Changing the server requirement to a MUST is a good goal, and frankly > I agree with it, in principle. But it will have implications. As a > SHOULD, > it is a strong recommendation, but implementations can still have > some freedom to evolve to it. > > BTW, either way this is going to be a devilishly hard condition to > test > for. Maybe even harder than testing the reply cache. > > Tom. > > _______________________________________________ > 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 SergiocloutHale@blinddogs.com Fri Nov 09 23:31:00 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqhzo-0008Ld-2J; Fri, 09 Nov 2007 23:31:00 -0500 Received: from 84.122.154.203.dyn.user.ono.com ([84.122.154.203] helo=menchu36f1549c) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iqhzn-0001sF-HG; Fri, 09 Nov 2007 23:30:59 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host28085128.blinddogs.com (8.13.1/8.13.1) with SMTP id iUBBOMCL16.243032.Um1.gG4.6071088542304 for ; Sat, 10 Nov 2007 05:30:58 -0100 Message-ID: <6e7f601c82352$8e346cf0$cb9a7a54@menchu36f1549c> From: "Terrance Gregory" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_6E7F2_01C82352.8E346CF0-- From HarlanjudithMeyers@43people.com Sat Nov 10 01:49:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqk9p-0001oL-Cs; Sat, 10 Nov 2007 01:49:29 -0500 Received: from pool-72-88-247-129.nwrknj.east.verizon.net ([72.88.247.129] helo=goganfamily.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iqk9o-0005Ie-QR; Sat, 10 Nov 2007 01:49:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host56300390.43people.com (8.13.1/8.13.1) with SMTP id jpvppWNe94.881469.ejJ.tkV.4988847185584 for ; Sat, 10 Nov 2007 02:02:06 +0500 Message-ID: <16d84e01c82367$ac02d6d0$2b01a8c0@GoganFamily> From: "Adolfo Christian" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_16D84A_01C82367.AC02D6D0-- From MarionindelicateKatz@notam02.no Sat Nov 10 03:01:33 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqlHZ-0000zo-S7; Sat, 10 Nov 2007 03:01:33 -0500 Received: from host81-143-29-57.in-addr.btopenworld.com ([81.143.29.57] helo=st01.geosstudent.local) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqlHZ-0007CU-BY; Sat, 10 Nov 2007 03:01:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host59954078.notam02.no (8.13.1/8.13.1) with SMTP id 6mJkEKGj29.534981.vKr.RcR.6549639279908 for ; Sat, 10 Nov 2007 08:04:19 +0000 Message-ID: <15806e01c82370$57c27450$1110a8c0@ST01> From: "June Gorman" To: Subject: Your order Date: Sat, 10 Nov 2007 08:04:19 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_15806A_01C82370.57C27450" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_15806A_01C82370.57C27450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_15806A_01C82370.57C27450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_15806A_01C82370.57C27450-- From BorissubmersibleFerrell@willieruff.com Sat Nov 10 04:13:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqmPW-0005xR-OA; Sat, 10 Nov 2007 04:13:50 -0500 Received: from xplr-ts-10-van-72-45-102-62.barrettxplore.com ([72.45.102.62] helo=lastfande4382a.barrettxplore.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqmPU-00011a-0E; Sat, 10 Nov 2007 04:13:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host46035437.willieruff.com (8.13.1/8.13.1) with SMTP id olkNuK4O04.850761.wPq.LXC.6761283488911 for ; Sat, 10 Nov 2007 01:15:02 +0800 Message-ID: <4ee9f01c8237a$4099e970$6601a8c0@lastfande4382a> From: "Lanny Mckay" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_4EE9B_01C8237A.4099E970-- From SheilapontMcghee@harpers.org Sat Nov 10 06:27:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqoVB-0000Op-0j; Sat, 10 Nov 2007 06:27:49 -0500 Received: from cm148109.red.mundo-r.com ([213.60.148.109] helo=intel945pa7a.mundor.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqoVA-0005FG-Kx; Sat, 10 Nov 2007 06:27:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host75923363.harpers.org (8.13.1/8.13.1) with SMTP id dxS7zy0571.162960.MCb.qqi.7051633192579 for ; Sat, 10 Nov 2007 12:27:54 -0100 Message-ID: <55b7301c8238c$cba08f30$6d943cd5@intel945pa7a> From: "Emma Spivey" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_55B6F_01C8238C.CBA08F30-- From LeolaontologyDrummond@williepbennett.com Sat Nov 10 10:37:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqsOk-0006X9-Kz; Sat, 10 Nov 2007 10:37:26 -0500 Received: from pool-71-170-237-151.dllstx.fios.verizon.net ([71.170.237.151] helo=office.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqsOk-00047i-Bh; Sat, 10 Nov 2007 10:37:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host50391473.williepbennett.com (8.13.1/8.13.1) with SMTP id YGE7D3aP95.832945.AEq.1Ss.0530004148406 for ; Sat, 10 Nov 2007 09:29:15 +0600 Message-ID: <189f0101c823af$8ee747f0$0201a8c0@office> From: "Paige Pritchett" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_189EFD_01C823AF.8EE747F0-- From EdwinaallegroMyrick@harpers.org Sat Nov 10 12:23:29 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqu3M-0005W6-UJ; Sat, 10 Nov 2007 12:23:28 -0500 Received: from [77.206.15.213] (helo=yourab6cd29f8e.mshome.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iqu3M-0008GB-30; Sat, 10 Nov 2007 12:23:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host81844386.harpers.org (8.13.1/8.13.1) with SMTP id dcuuANAU45.662672.rr3.Fnj.8986421787747 for ; Sat, 10 Nov 2007 18:23:07 -0100 Message-ID: <57a9801c823be$6b683910$1401a8c0@yourab6cd29f8e> From: "Kaye Presley" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_57A94_01C823BE.6B683910-- From EllissleepyGreer@biggestbook.com Sat Nov 10 13:30:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqv5z-000864-Nw; Sat, 10 Nov 2007 13:30:15 -0500 Received: from c-75-75-154-219.hsd1.pa.comcast.net ([75.75.154.219] helo=d3zkgy11.hsd1.pa.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iqv5z-0002Ee-FM; Sat, 10 Nov 2007 13:30:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host01876417.biggestbook.com (8.13.1/8.13.1) with SMTP id IWygFQ9X19.059577.C7B.iMZ.4237441174137 for ; Fri, 9 Nov 2007 14:32:56 +0500 Message-ID: <3594701c82307$5d124200$6401a8c0@D3ZKGY11> From: "Ismael Christensen" To: Subject: Your order Date: Fri, 9 Nov 2007 14:32:56 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_35943_01C82307.5D124200" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_35943_01C82307.5D124200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_35943_01C82307.5D124200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_35943_01C82307.5D124200-- From Bennett.dragos@bobbecwar.com Sat Nov 10 15:03:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqwYV-0006fG-El for nfsv4-archive@lists.ietf.org; Sat, 10 Nov 2007 15:03:47 -0500 Received: from p549a032e.dip0.t-ipconnect.de ([84.154.3.46]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqwYU-0005jX-PF for nfsv4-archive@lists.ietf.org; Sat, 10 Nov 2007 15:03:47 -0500 Received: by 10.137.103.33 with SMTP id ZVgpqFpvghdgQ; Sat, 10 Nov 2007 21:03:48 +0100 (GMT) Received: by 192.168.82.146 with SMTP id ZRwPClljSdIVkO.4031672890228; Sat, 10 Nov 2007 21:03:46 +0100 (GMT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 10 Nov 2007 21:03:43 +0100 To: nfsv4-archive@lists.ietf.org From: "Bennett dragos" Subject: edneppin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 3.1 (+++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea http://www.rossatel.com/ My peni*s grew 2" after 5 months of use ednehegr ednelets edesemde edlesfji From GonzalomynheerRojas@timemachinego.com Sat Nov 10 15:22:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqwqA-0004NE-Gw; Sat, 10 Nov 2007 15:22:02 -0500 Received: from 246samana71.codetel.net.do ([200.88.71.246] helo=laura.domain.invalid) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iqwq9-0006MA-Px; Sat, 10 Nov 2007 15:22:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host58579586.timemachinego.com (8.13.1/8.13.1) with SMTP id 0IZXoXfK94.415763.uSg.ZPp.8921632198571 for ; Sat, 10 Nov 2007 16:21:18 +0100 Message-ID: <4970a01c823be$277a6430$0200000a@LAURA> From: "Adolph Prince" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_49706_01C823BE.277A6430-- From FreddieparentMckinney@rulers.org Sat Nov 10 16:18:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iqxit-0000nj-Eo; Sat, 10 Nov 2007 16:18:35 -0500 Received: from s0106000d561d7dc5.ok.shawcable.net ([24.67.131.161] helo=user.ok.shawcable.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iqxis-0007pi-7b; Sat, 10 Nov 2007 16:18:35 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host74497074.rulers.org (8.13.1/8.13.1) with SMTP id caTAPCuN92.435984.H3W.dsf.9678313771139 for ; Sat, 10 Nov 2007 13:12:05 -0200 Message-ID: <13676601c8238b$74b6c320$a1834318@user> From: "Marshall Gregory" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_136762_01C8238B.74B6C320-- From nfsv4-bounces@ietf.org Sat Nov 10 17:18: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 1IqyeJ-0007ho-Jv; Sat, 10 Nov 2007 17:17:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqyeI-0007hi-TT for nfsv4@ietf.org; Sat, 10 Nov 2007 17:17:55 -0500 Received: from web38108.mail.mud.yahoo.com ([209.191.124.135]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqyeH-0001Gi-VI for nfsv4@ietf.org; Sat, 10 Nov 2007 17:17:54 -0500 Received: (qmail 48934 invoked by uid 60001); 10 Nov 2007 22:17:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=V7qy0iGeQ5oJoLNPpHkBsHQ4d9Cx2zc4X+N2/op9GIRm/WbM9HlbrUy/NxI8YQyq66gfRijPltC6cu7aXbo2624qUME2OcJWfRuJ45Dtkx9MGq/XE8GFlKmuggd9jwv/h/lNXf0VHfLEDExXDRVKXSyYrnLWiUEMdtekz0/keUE=; X-YMail-OSG: s3TnqAQVM1n962ZoZftLYDRILPR4YB_1IReTSJOcC0xRM.td82iQpbXjZsnNXaV_JiQNqC5HRw-- Received: from [198.95.226.230] by web38108.mail.mud.yahoo.com via HTTP; Sat, 10 Nov 2007 14:17:53 PST Date: Sat, 10 Nov 2007 14:17:53 -0800 (PST) From: Mike Eisler To: nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <261722.48676.qm@web38108.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Subject: [nfsv4] device IDs and stateids X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org I am unnerved by the seemingly unstoppable drive to having zillions of stateids for device ID to device address mappings, and still don't understand why we are going in that direction. The latest I've read is that there will be only one stateid per major device ID. Given that a major device ID has ballooned to 64 bits, that does not comfort me. The current path means that device ID notifications have little, if any, utility, given that delegations for 2^64 different major device IDs can be handed out. What are the requirements? No one has put them down in a concise list list as far as I know. So I will state them, based on what I've read and heard since the we had a pNFS inspection meeting during the Austin bake-a-thon. Requirements: - Server -- Without forcing the client to re-issue GETDEVICELIST, --- be able to invalidate a single device ID's address mappings --- Be able to change a single device ID's address mappings --- Be able to change add a single device ID's address mappings -- Allow recall of layouts by FSID, and possibly other coarse grained objects. My understanding is that for some layout types and/or pNFS server implementations this is critical. - Client -- Do not burden the general pNFS implementation with aspects that specific to a pNFS server or implementation (e.g. the possibility of recall by FSID requires clients to organize layouts by FSID, which is really a kick in the teeth if the server never issues such a recall. -- If there must be a recall by a coarse grained object, don't force the client implementation to understand what that object is. Every time we add a layout type or a pNFS server implementation should not be an occasion to re-write client's generic pNFS layer. - Both client and server -- Minimize the cost implementing these requirements. E.g. do not go down the road of requiring multiple stateids for devices. So here is the outline of what I've proposed before, in more detail this time: - DeviceIDs have a major and minor component. The current consensus that they be the same size and format as the fsid makes sense, since it makes it easier for servers to implement recall by fsid. - Replace layout recall by FSID with layout recall by major device ID. Now the server can organize its data how it sees fit without giving the client information it doesn't need. - Allow servers to indicate that they don't require clients to organize layouts by major device ID by encoding the major device ID such that if did_major & 0x8000000000000000 is FALSE then this is an indication the device ID is to be treated as a flat object and no recall by major device ID will occur. - There is no more than one device stateid per clientID/layout type pair. It is returned by GETDEVICEINFO, and GETDEVICELIST. - enhance GETDEVICELIST to optionally take a major device ID. This will allow the client to obtain all the minor device IDs for a major device ID as well as the address mappings. This is actually the only new thing I've added. - The preferred way device ID mappings are updated is through notification by CB_NOTIFY (or the server can recall the device stateid, and force the client to re-issue GETDEVICELIST/GETDEVICEINFO for all mappings). After CB_NOTIFY is received, the client can issue GETDEVICELIST or GETDEVICEINFO as apporpriate. CB_NOTIFY has x deviceID notifications: -- NOTIFY4_DEVICE_NEW_MAJOR: a new major device ID has been added. If the client cares, it can issue GETDEVICELIST to obtain it. -- NOTIFY4_DEVICE_ADDED_TO_MAJOR: one or more minor devices added to the major device. If the client cares, it can issue GETDEVICELIST to get the current minor devices for the major device. -- NOTIFY4_DEVICE_MAJOR_DELETED: some or all device IDs with the specified major device ID are deleted. If just some device IDs are deleted, the client can use GETDEVICELIST with the major device ID to see what is left. -- NOTIFY4_DEVICE_ID_ADD - full deviceID, as in draft-15 -- NOTIFY4_DEVICE_ID_CHANGE - full deviceID, as in draft-15 -- NOTIFY4_DEVICE_ID_DELETE - full deviceID, as in draft-15 These notifications are asynchronous. It is up to the pNFS server to prevent the use of deleted or updated device IDs. We have at our disposal: - fencing (preferred) - the SLA method that the blocks layout type OPTIONALly specifies (if necessary) For those who argue that recall by a per major-device ID is safer, I see the same race conditions, and the same solutions: fencing and SLA. --- "Noveck, Dave" wrote: > > However, I see that I was confused. I didn't really mean a recall > of > > the fsid, but of the deviceID. Are we, or are we not going to > support > > recalling deviceIDs? > > I can't predict the future. The only thing I can do (barely) is to > read the current version of the spec based on the CVS repository and > in there I don't see any provision for recalling a specific device > (and somehow implicitly recalling all layout segment for that device > which it seems like you are depending on). > > > There was some discussion about doing this, since Marc in > particular > > wanted the ability to invalidate a deviceID without recalling the > layout > > (the client would presumably re-issue a GETDEVICEINFO request and > get > > directed to a new DS) but I've lost track of the status of that > request. > > I think that that is the notify. > > Device maps can also be recalled but there you are recalling all > device > with a given major id which may be too coarse-grained for what you > want > (or you may be able to arrange things so it isn't). The effect on > existing layouts (whether there is an implicit recall) is not clear > at > all. One problem is that although by giving device maps stateids, we > have implicitly provided a recall mechanism, the text for CB_RECALL > only mentions recall of delegations, and so the status and semantics > of recalls of device maps isn't very clear. > > I'm also having trouble with this text: > > Device ID mappings represent another form of stateid > Section 8.2.1. The GETDEVICEINFO and GETDEVICELIST operations > each > return a device stateid. > > My assumption is one stateid per major device. > > Like file delegations, the device stateid > is recallable. A recall of the device stateid will remove or > invalidate the device ID mappings > > are "remove" and "invalidate" intended to be synonyms or are these > two > different things which can be done? > > as well as lease expiration. > > Huh? > > The > GETDEVICEINFO and GETDEVICELIST operations update the current > filehandle to facilitate the recall of the device stateid. > > I've already asked about this with regard to text for the ops > GETDEVICEINFO and GETDEVICELIST. I still have no clue what is > intended. > > I'm not sure but if look to me like to do what you want the the MDS > would have to do layout recalls on each of the individual stripes > that the device covered. > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From KennycowlickSchneider@tattiebogle.net Sun Nov 11 09:09:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrDVS-0003Dt-6B; Sun, 11 Nov 2007 09:09:46 -0500 Received: from 62-97.cablevision.qc.ca ([24.212.62.97] helo=aucunel3pghgg0.cablevision.qc.ca) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrDVR-0001TV-FY; Sun, 11 Nov 2007 09:09:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host50407459.tattiebogle.net (8.13.1/8.13.1) with SMTP id ZLcz5Jle26.048436.PuY.86J.1535897561777 for ; Sun, 11 Nov 2007 09:09:33 +0500 Message-ID: From: "Matt Leonard" To: Subject: Confirmation link Date: Sun, 11 Nov 2007 09:09:33 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_A808E_01C8246C.99BE1BA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_A808E_01C8246C.99BE1BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_A808E_01C8246C.99BE1BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_A808E_01C8246C.99BE1BA0-- From nfsv4-bounces@ietf.org Sun Nov 11 09:57: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 1IrEF2-0002qV-FQ; Sun, 11 Nov 2007 09:56:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrEF1-0002p4-5t for nfsv4@ietf.org; Sun, 11 Nov 2007 09:56:51 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrEEv-0005S8-2V for nfsv4@ietf.org; Sun, 11 Nov 2007 09:56:51 -0500 X-IronPort-AV: E=Sophos;i="4.21,401,1188802800"; d="scan'208";a="121469138" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 11 Nov 2007 06:56:29 -0800 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 lABEuSbU011626; Sun, 11 Nov 2007 06:56:28 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 06:56:29 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 06:56:28 -0800 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 IDs and stateids Date: Sun, 11 Nov 2007 09:56:26 -0500 Message-ID: In-Reply-To: <261722.48676.qm@web38108.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] device IDs and stateids Thread-Index: Acgj58Wu8tncS4rXTUeuW8GQ4NT/2AAhZ8sA From: "Noveck, Dave" To: , X-OriginalArrivalTime: 11 Nov 2007 14:56:28.0569 (UTC) FILETIME=[09E1C890:01C82473] X-Spam-Score: -3.7 (---) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 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 am unnerved by the seemingly unstoppable drive to having=20 > zillions of stateids for device ID to device address mappings,=20 > and still don't understand why we are going in that direction. "zillions" is imprescise.=20 The current proposal is to allow 256 undecillion device ids but note that a given client ID can only have 64 octillion statids. If someone proposes expanding the stateid, I will try to stay calm. I don't promise to succeed however.=20 > The latest I've read is that there will be only one stateid=20 > per major device ID. That's been my assumption but nobody has either confirmed or contradicted that understanding. Some people may be thinking about a stateid for a single device id. > -- Do not burden the general pNFS implementation > with aspects that specific to a pNFS server or > implementation (e.g. the possibility of recall by > FSID requires clients to organize layouts by FSID, > which is really a kick in the teeth if the server > never issues such a recall. The client has to organize his data structure by fsid's for many reasons. He can get a MOVED error, for instance. He has a choice of linking together his file objects or searching by fsid when the event happens but he has to have enough information to do that in any case. =20 > - Replace layout recall by FSID with layout recall by major > device ID. Now the server can organize its data how it > sees fit without giving the client information it doesn't > need. But at a large cost in client complexity. The difference here is that a recall by FSID is the union of a set of recalls by file, i.e. you are recalling the entire layout for some set of=20 files whereas with a recall by device id or major device id, you=20 may be recalling pieces of the layout for one file and different pieces for a different file, etc. Then you have to return them. With a file layout, we have a =20 single compact striping pattern that implies the layout for=20 millions of distinct byte ranges. If you have a way to abbreviate=20 that, you still have the issue of imposing on the client a very=20 complicated state space for what layouts it has. For files, what=20 you would like is either "I have the whole layout" or "I don't=20 have any of the layout" and without this kind of stuff you might=20 be able to get away with it. Also, the logic in the server to=20 determine when the client has returned all of the requested layout=20 ranges doesn't seem very nice. > - Allow servers to indicate that they don't require > clients to organize layouts by major device ID by > encoding the major device ID such that if > > did_major & 0x8000000000000000 is FALSE > > then this is an indication the device ID is to be > treated as a flat object and no recall by major device > ID will occur. Why do we need this? If I want to not have the client deal=20 with multiple major device id's, why don't I just use =20 only one (major id equals zero). The server still has 16=20 quintilion devices to work with. Why isn't that enough? > - There is no more than one device stateid per > clientID/layout type pair. It is returned by > GETDEVICEINFO, and GETDEVICELIST. Works for me but for others the issue is going to be=20 the effect/validity of recall on this stateid. And if it is not usefully recallable, what is the point of=20 giving this a stateid? We also need to resolve the issue cfh with regard to=20 GETDEVICEINFO and GETDEVICELIST. -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Saturday, November 10, 2007 5:18 PM To: nfsv4@ietf.org Subject: [nfsv4] device IDs and stateids I am unnerved by the seemingly unstoppable drive to having zillions of stateids for device ID to device address mappings, and still don't understand why we are going in that direction. The latest I've read is that there will be only one stateid per major device ID. Given that a major device ID has ballooned to 64 bits, that does not comfort me. The current path means that device ID notifications have little, if any, utility, given that delegations for 2^64 different major device IDs can be handed out. What are the requirements? No one has put them down in a concise list list as far as I know. So I will state them, based on what I've read and heard since the we had a pNFS inspection meeting during the Austin bake-a-thon. Requirements: - Server -- Without forcing the client to re-issue GETDEVICELIST, --- be able to invalidate a single device ID's address mappings --- Be able to change a single device ID's address mappings --- Be able to change add a single device ID's address mappings -- Allow recall of layouts by FSID, and possibly other coarse grained objects. My understanding is that for some layout types and/or pNFS server implementations this is critical. - Client -- Do not burden the general pNFS implementation with aspects that specific to a pNFS server or implementation (e.g. the possibility of recall by FSID requires clients to organize layouts by FSID, which is really a kick in the teeth if the server never issues such a recall. -- If there must be a recall by a coarse grained object, don't force the client implementation to understand what that object is. Every time we add a layout type or a pNFS server implementation should not be an occasion to re-write client's generic pNFS layer. - Both client and server -- Minimize the cost implementing these requirements. E.g. do not go down the road of requiring multiple stateids for devices. So here is the outline of what I've proposed before, in more detail this time: - DeviceIDs have a major and minor component. The current consensus that they be the same size and format as the fsid makes sense, since it makes it easier for servers to implement recall by fsid. - Replace layout recall by FSID with layout recall by major device ID. Now the server can organize its data how it sees fit without giving the client information it doesn't need. - Allow servers to indicate that they don't require clients to organize layouts by major device ID by encoding the major device ID such that if did_major & 0x8000000000000000 is FALSE then this is an indication the device ID is to be treated as a flat object and no recall by major device ID will occur. - There is no more than one device stateid per clientID/layout type pair. It is returned by GETDEVICEINFO, and GETDEVICELIST. - enhance GETDEVICELIST to optionally take a major device ID. This will allow the client to obtain all the minor device IDs for a major device ID as well as the address mappings. This is actually the only new thing I've added. - The preferred way device ID mappings are updated is through notification by CB_NOTIFY (or the server can recall the device stateid, and force the client to re-issue GETDEVICELIST/GETDEVICEINFO for all mappings). After CB_NOTIFY is received, the client can issue GETDEVICELIST or GETDEVICEINFO as apporpriate. CB_NOTIFY has x deviceID notifications: -- NOTIFY4_DEVICE_NEW_MAJOR: a new major device ID has been added. If the client cares, it can issue GETDEVICELIST to obtain it. -- NOTIFY4_DEVICE_ADDED_TO_MAJOR: one or more minor devices added to the major device. If the client cares, it can issue GETDEVICELIST to get the current minor devices for the major device. -- NOTIFY4_DEVICE_MAJOR_DELETED: some or all device IDs with the specified major device ID are deleted. If just some device IDs are deleted, the client can use GETDEVICELIST with the major device ID to see what is left. -- NOTIFY4_DEVICE_ID_ADD - full deviceID, as in draft-15 -- NOTIFY4_DEVICE_ID_CHANGE - full deviceID, as in draft-15 -- NOTIFY4_DEVICE_ID_DELETE - full deviceID, as in draft-15 =20 These notifications are asynchronous. It is up to the pNFS server to prevent the use of deleted or updated device IDs. We have at our disposal: - fencing (preferred) - the SLA method that the blocks layout type OPTIONALly specifies (if necessary) For those who argue that recall by a per major-device ID is safer, I see the same race conditions, and the same solutions: fencing and SLA. --- "Noveck, Dave" wrote: > > However, I see that I was confused. I didn't really mean a recall > of > > the fsid, but of the deviceID. Are we, or are we not going to > support > > recalling deviceIDs? >=20 > I can't predict the future. The only thing I can do (barely) is to=20 > read the current version of the spec based on the CVS repository and=20 > in there I don't see any provision for recalling a specific device=20 > (and somehow implicitly recalling all layout segment for that device=20 > which it seems like you are depending on). >=20 > > There was some discussion about doing this, since Marc in > particular > > wanted the ability to invalidate a deviceID without recalling the > layout > > (the client would presumably re-issue a GETDEVICEINFO request and > get > > directed to a new DS) but I've lost track of the status of that > request. >=20 > I think that that is the notify. >=20 > Device maps can also be recalled but there you are recalling all=20 > device with a given major id which may be too coarse-grained for what=20 > you want (or you may be able to arrange things so it isn't). The=20 > effect on existing layouts (whether there is an implicit recall) is=20 > not clear at all. One problem is that although by giving device maps=20 > stateids, we have implicitly provided a recall mechanism, the text for > CB_RECALL only mentions recall of delegations, and so the status and=20 > semantics of recalls of device maps isn't very clear. >=20 > I'm also having trouble with this text: >=20 > Device ID mappings represent another form of stateid > Section 8.2.1. The GETDEVICEINFO and GETDEVICELIST operations each > return a device stateid.=20 >=20 > My assumption is one stateid per major device.=20 >=20 > Like file delegations, the device stateid > is recallable. A recall of the device stateid will remove or > invalidate the device ID mappings >=20 > are "remove" and "invalidate" intended to be synonyms or are these two > different things which can be done? >=20 > as well as lease expiration. =20 >=20 > Huh? >=20 > The > GETDEVICEINFO and GETDEVICELIST operations update the current > filehandle to facilitate the recall of the device stateid.=20 >=20 > I've already asked about this with regard to text for the ops=20 > GETDEVICEINFO and GETDEVICELIST. I still have no clue what is=20 > intended. >=20 > I'm not sure but if look to me like to do what you want the the MDS=20 > would have to do layout recalls on each of the individual stripes that > the device covered. > _______________________________________________ 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 Way660@gems4less.com Sun Nov 11 11:00:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrFE9-00062S-2Y for nfsv4-archive@lists.ietf.org; Sun, 11 Nov 2007 11:00:01 -0500 Received: from cpc4-walt5-0-0-cust833.popl.cable.ntl.com ([82.11.191.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrFE6-0005Nq-Vx for nfsv4-archive@lists.ietf.org; Sun, 11 Nov 2007 11:00:00 -0500 Received: by 10.191.125.139 with SMTP id pPHyoIrOBQzPM; Thu, 2 Jan 2003 03:37:18 -0000 (GMT) Received: by 192.168.217.44 with SMTP id LpkCxxbLyzicfl.3443019275127; Thu, 2 Jan 2003 03:37:16 -0000 (GMT) Message-ID: <000201c2b210$3d167ce0$42bf0b52@foxcom> From: "Way Goravitz" To: Subject: tatsettu Date: Thu, 2 Jan 2003 03:37:13 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C2B210.3D167CE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0009_01C2B210.3D167CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable http://tarpoto.com/ I saw this on tv and just had to get me some.. best thing i have ever = done tavimuut tegalekk tatorily taubfrei ------=_NextPart_000_0009_01C2B210.3D167CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
http://tarpoto.com/
I saw this on tv and just had to get me some.. = best=20 thing i have ever done
tavimuut tegalekk
tatorily taubfrei
------=_NextPart_000_0009_01C2B210.3D167CE0-- From AdolfocanopyMosley@oyez.org Sun Nov 11 11:12:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrFQB-0007ig-UC; Sun, 11 Nov 2007 11:12:27 -0500 Received: from [201.229.177.91] (helo=pc06) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrFQB-0005xE-CD; Sun, 11 Nov 2007 11:12:27 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host80634239.oyez.org (8.13.1/8.13.1) with SMTP id cHSL1OFa81.230631.za9.8aA.7089092939531 for ; Sun, 11 Nov 2007 12:11:41 +0400 Message-ID: <051c01c8247d$9d0bd750$6a00000a@PC06> From: "Curt Cameron" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_0518_01C8247D.9D0BD750-- From EileenlawgiveEmery@ibiblio.org Sun Nov 11 12:41:09 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrGo1-0002xj-IJ; Sun, 11 Nov 2007 12:41:09 -0500 Received: from ntl208h101-96-48.nt.net ([208.101.96.48] helo=jeannot2.dsl.nt.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrGo1-0001TO-74; Sun, 11 Nov 2007 12:41:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host56125670.ibiblio.org (8.13.1/8.13.1) with SMTP id U9JnMRDv38.178153.aHo.seU.6828912238427 for ; Sun, 11 Nov 2007 12:40:21 +0500 Message-ID: <11c5101c82489$f7a8bf50$306065d0@jeannot2> From: "Natalie Lam" To: Subject: Your order approved Date: Sun, 11 Nov 2007 12:40:21 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_11C4D_01C82489.F7A8BF50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_11C4D_01C82489.F7A8BF50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_11C4D_01C82489.F7A8BF50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_11C4D_01C82489.F7A8BF50-- From nfsv4-bounces@ietf.org Sun Nov 11 12:41:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrGo1-0002wh-88; Sun, 11 Nov 2007 12:41:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrGo0-0002uP-ED for nfsv4@ietf.org; Sun, 11 Nov 2007 12:41:08 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrGnu-000373-W4 for nfsv4@ietf.org; Sun, 11 Nov 2007 12:41:08 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lABHexvm009267 for ; Sun, 11 Nov 2007 17:41:00 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRC00201RNLHN00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Sun, 11 Nov 2007 10:40:59 -0700 (MST) Received: from [198.18.100.33] ([12.10.173.2]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRC00D7ARSABE10@mail-amer.sun.com>; Sun, 11 Nov 2007 10:40:59 -0700 (MST) Date: Sun, 11 Nov 2007 11:41:35 -0600 From: Spencer Shepler Subject: Re: [nfsv4] device IDs and 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; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: X-Spam-Score: -1.0 (-) X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0 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 Nov 11, 2007, at 8:56 AM, Noveck, Dave wrote: > >> The latest I've read is that there will be only one stateid >> per major device ID. > > That's been my assumption but nobody has either confirmed or > contradicted that understanding. Some people may be thinking > about a stateid for a single device id. Stateid per deviceid's major. > >> -- Do not burden the general pNFS implementation >> with aspects that specific to a pNFS server or >> implementation (e.g. the possibility of recall by >> FSID requires clients to organize layouts by FSID, >> which is really a kick in the teeth if the server >> never issues such a recall. > > The client has to organize his data structure by fsid's for > many reasons. He can get a MOVED error, for instance. He > has a choice of linking together his file objects or searching > by fsid when the event happens but he has to have enough > information to do that in any case. > >> - Replace layout recall by FSID with layout recall by major >> device ID. Now the server can organize its data how it >> sees fit without giving the client information it doesn't >> need. > > But at a large cost in client complexity. The difference here > is that a recall by FSID is the union of a set of recalls by > file, i.e. you are recalling the entire layout for some set of > files whereas with a recall by device id or major device id, you > may be recalling pieces of the layout for one file and different > pieces for a different file, etc. It seems there is value in allowing for LAYOUTRECALL by fsid in that the layouts may be changing but the deviceid mappings may stay the same. This allows for flexibility (some may argue to much flexbility) and should allow for future server implementations as well as future layout types that may need something like this. Given that the deviceid's stateids have been described as delegations on the mapping, the use of CB_RECALL would be used for recalling the deviceid mappings associated with the stateid and the client would signify their return with DELEGRETURN. >> - Allow servers to indicate that they don't require >> clients to organize layouts by major device ID by >> encoding the major device ID such that if >> >> did_major & 0x8000000000000000 is FALSE >> >> then this is an indication the device ID is to be >> treated as a flat object and no recall by major device >> ID will occur. > > Why do we need this? If I want to not have the client deal > with multiple major device id's, why don't I just use > only one (major id equals zero). The server still has 16 > quintilion devices to work with. Why isn't that enough? I agree that we should not special case this. The client will need to deal, in the general case, of a server that has multiple deviceid.major values and a server that has but a single deviceid.major will be the degenerate case and likely not going to lead to significant optimizations by the client. Spencer >> - There is no more than one device stateid per >> clientID/layout type pair. It is returned by >> GETDEVICEINFO, and GETDEVICELIST. > > Works for me but for others the issue is going to be > the effect/validity of recall on this stateid. And if > it is not usefully recallable, what is the point of > giving this a stateid? > > We also need to resolve the issue cfh with regard to > GETDEVICEINFO and GETDEVICELIST. The issue being that the current filehandle is captured by the client to deal with CB_RECALL and DELEGRETURN processing? To simplify the GETDEVICELIST results, I would suggest that there is a single "deviceid mapping" filehandle that is used by the server that is set as current filehandle for the results. Spencer > > > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > Sent: Saturday, November 10, 2007 5:18 PM > To: nfsv4@ietf.org > Subject: [nfsv4] device IDs and stateids > > I am unnerved by the seemingly unstoppable drive to having zillions of > stateids for device ID to device address mappings, and still don't > understand why we are going in that direction. The latest I've read is > that there will be only one stateid per major device ID. Given that a > major device ID has ballooned to 64 bits, that does not comfort me. > The > current path means that device ID notifications have little, if any, > utility, given that delegations for > 2^64 different major device IDs can be handed out. > > What are the requirements? No one has put them down in a concise list > list as far as I know. So I will state them, based on what I've > read and > heard since the we had a pNFS inspection meeting during the Austin > bake-a-thon. > > Requirements: > > - Server > > -- Without forcing the client to re-issue GETDEVICELIST, > > --- be able to invalidate a single device ID's > address mappings > > --- Be able to change a single device ID's > address mappings > > --- Be able to change add a single device ID's > address mappings > > -- Allow recall of layouts by FSID, and possibly other > coarse grained objects. My understanding is that for > some layout types and/or pNFS server implementations > this is critical. > > - Client > > -- Do not burden the general pNFS implementation > with aspects that specific to a pNFS server or > implementation (e.g. the possibility of recall by > FSID requires clients to organize layouts by FSID, > which is really a kick in the teeth if the server > never issues such a recall. > > -- If there must be a recall by a coarse grained object, > don't force the client implementation to understand what > that object is. Every time we add a layout type or > a pNFS server implementation should not be an occasion > to re-write client's generic pNFS layer. > > - Both client and server > > -- Minimize the cost implementing these requirements. > E.g. do not go down the road of requiring multiple > stateids for devices. > > So here is the outline of what I've proposed before, in more detail > this > time: > > - DeviceIDs have a major and minor component. The current > consensus that they be the same size and format as the > fsid makes sense, since it makes it easier for servers > to implement recall by fsid. > > - Replace layout recall by FSID with layout recall by major > device ID. Now the server can organize its data how it > sees fit without giving the client information it doesn't > need. > > - Allow servers to indicate that they don't require > clients to organize layouts by major device ID by > encoding the major device ID such that if > > did_major & 0x8000000000000000 is FALSE > > then this is an indication the device ID is to be > treated as a flat object and no recall by major device > ID will occur. > > - There is no more than one device stateid per > clientID/layout type pair. It is returned by > GETDEVICEINFO, and GETDEVICELIST. > > - enhance GETDEVICELIST to optionally take a major device > ID. This will allow the client to obtain all the minor > device IDs for a major device ID as well as the address > mappings. This is actually the only new thing I've added. > > - The preferred way device ID mappings are updated is through > notification by CB_NOTIFY (or the server can recall > the device stateid, and force the client to re-issue > GETDEVICELIST/GETDEVICEINFO for all mappings). After > CB_NOTIFY is received, the client can issue GETDEVICELIST > or GETDEVICEINFO as apporpriate. > CB_NOTIFY has x deviceID notifications: > > -- NOTIFY4_DEVICE_NEW_MAJOR: a new major device ID has been > added. If the client cares, it can issue GETDEVICELIST > to obtain it. > > -- NOTIFY4_DEVICE_ADDED_TO_MAJOR: one or more minor > devices added to the major device. If the client cares, > it can issue GETDEVICELIST to get the current minor > devices for the major device. > > -- NOTIFY4_DEVICE_MAJOR_DELETED: some or all device IDs > with the specified major device ID are deleted. If > just some device IDs are deleted, the client can use > GETDEVICELIST with the major device ID to see what > is left. > > -- NOTIFY4_DEVICE_ID_ADD - full deviceID, as in draft-15 > -- NOTIFY4_DEVICE_ID_CHANGE - full deviceID, as in draft-15 > -- NOTIFY4_DEVICE_ID_DELETE - full deviceID, as in draft-15 > > These notifications are asynchronous. It is up to the > pNFS server to prevent the use of deleted or updated > device IDs. We have at our disposal: > > - fencing (preferred) > - the SLA method that the blocks layout type > OPTIONALly specifies (if necessary) > > For those who argue that recall by a per major-device > ID is safer, I see the same race conditions, and the > same solutions: fencing and SLA. > > --- "Noveck, Dave" wrote: > >>> However, I see that I was confused. I didn't really mean a recall >> of >>> the fsid, but of the deviceID. Are we, or are we not going to >> support >>> recalling deviceIDs? >> >> I can't predict the future. The only thing I can do (barely) is to >> read the current version of the spec based on the CVS repository and >> in there I don't see any provision for recalling a specific device >> (and somehow implicitly recalling all layout segment for that device >> which it seems like you are depending on). >> >>> There was some discussion about doing this, since Marc in >> particular >>> wanted the ability to invalidate a deviceID without recalling the >> layout >>> (the client would presumably re-issue a GETDEVICEINFO request and >> get >>> directed to a new DS) but I've lost track of the status of that >> request. >> >> I think that that is the notify. >> >> Device maps can also be recalled but there you are recalling all >> device with a given major id which may be too coarse-grained for what >> you want (or you may be able to arrange things so it isn't). The >> effect on existing layouts (whether there is an implicit recall) is >> not clear at all. One problem is that although by giving device maps >> stateids, we have implicitly provided a recall mechanism, the text >> for > >> CB_RECALL only mentions recall of delegations, and so the status and >> semantics of recalls of device maps isn't very clear. >> >> I'm also having trouble with this text: >> >> Device ID mappings represent another form of stateid >> Section 8.2.1. The GETDEVICEINFO and GETDEVICELIST operations >> each >> return a device stateid. >> >> My assumption is one stateid per major device. >> >> Like file delegations, the device stateid >> is recallable. A recall of the device stateid will remove or >> invalidate the device ID mappings >> >> are "remove" and "invalidate" intended to be synonyms or are these >> two > >> different things which can be done? >> >> as well as lease expiration. >> >> Huh? >> >> The >> GETDEVICEINFO and GETDEVICELIST operations update the current >> filehandle to facilitate the recall of the device stateid. >> >> I've already asked about this with regard to text for the ops >> GETDEVICEINFO and GETDEVICELIST. I still have no clue what is >> intended. >> >> I'm not sure but if look to me like to do what you want the the MDS >> would have to do layout recalls on each of the individual stripes >> that > >> the device covered. >> > > _______________________________________________ > 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 Sun Nov 11 14:24:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrIQI-0003CV-Vk; Sun, 11 Nov 2007 14:24:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrIQH-0003Bl-8x for nfsv4@ietf.org; Sun, 11 Nov 2007 14:24:45 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrIQA-00070Y-N2 for nfsv4@ietf.org; Sun, 11 Nov 2007 14:24:45 -0500 X-IronPort-AV: E=Sophos;i="4.21,402,1188802800"; d="scan'208";a="121514774" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 11 Nov 2007 11:24:23 -0800 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 lABJOMUB012413; Sun, 11 Nov 2007 11:24:22 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 11:24:22 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 11:24:22 -0800 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 IDs and stateids Date: Sun, 11 Nov 2007 14:24:20 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] device IDs and stateids Thread-Index: AcgkiiAmqAIIYu0UQu6Ggo9OBC82lAADR1aw From: "Noveck, Dave" To: "Spencer Shepler" X-OriginalArrivalTime: 11 Nov 2007 19:24:22.0531 (UTC) FILETIME=[76B5BD30:01C82498] X-Spam-Score: -4.0 (----) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae 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 > Given that the deviceid's stateids have been described as=20 > delegations on the mapping, the use of CB_RECALL would be=20 > used for recalling the deviceid mappings associated with the=20 > stateid and the client would signify their return with=20 > DELEGRETURN. That's reasonable but I think we need some text for CB_RECALL to make that explicit. I think some of the confusion about cfh on GETDEVICEINFO and GETDEVICELIST may be related to the fact that device stateis have been described as delegations on the mapping without being terribly clear on details of=20 that analogy/identification. To clarify, what is the effect of DELEGRETURN on layouts that contain the references to recalled device mappings? Am I=20 correct that there is no recall (i.e. requirement to actually do a LAYOUTRETURN), but ... =20 the client is obliged not to use the old mappings the server is obliged not to allow the old mappings to be used. When the clients new mappings for the same device id it may use existing layouts for those device ids. =20 -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Sunday, November 11, 2007 12:42 PM To: Noveck, Dave Cc: email2mre-ietf@yahoo.com; nfsv4@ietf.org Subject: Re: [nfsv4] device IDs and stateids On Nov 11, 2007, at 8:56 AM, Noveck, Dave wrote: > >> The latest I've read is that there will be only one stateid per major >> device ID. > > That's been my assumption but nobody has either confirmed or=20 > contradicted that understanding. Some people may be thinking about a=20 > stateid for a single device id. Stateid per deviceid's major. > >> -- Do not burden the general pNFS implementation >> with aspects that specific to a pNFS server or >> implementation (e.g. the possibility of recall by >> FSID requires clients to organize layouts by FSID, >> which is really a kick in the teeth if the server >> never issues such a recall. > > The client has to organize his data structure by fsid's for many=20 > reasons. He can get a MOVED error, for instance. He has a choice of=20 > linking together his file objects or searching by fsid when the event=20 > happens but he has to have enough information to do that in any case. > >> - Replace layout recall by FSID with layout recall by major >> device ID. Now the server can organize its data how it >> sees fit without giving the client information it doesn't >> need. > > But at a large cost in client complexity. The difference here is that > a recall by FSID is the union of a set of recalls by file, i.e. you=20 > are recalling the entire layout for some set of files whereas with a=20 > recall by device id or major device id, you may be recalling pieces of > the layout for one file and different pieces for a different file,=20 > etc. It seems there is value in allowing for LAYOUTRECALL by fsid in that the layouts may be changing but the deviceid mappings may stay the same. This allows for flexibility (some may argue to much flexbility) and should allow for future server implementations as well as future layout types that may need something like this. Given that the deviceid's stateids have been described as delegations on the mapping, the use of CB_RECALL would be used for recalling the deviceid mappings associated with the stateid and the client would signify their return with DELEGRETURN. >> - Allow servers to indicate that they don't require >> clients to organize layouts by major device ID by >> encoding the major device ID such that if >> >> did_major & 0x8000000000000000 is FALSE >> >> then this is an indication the device ID is to be >> treated as a flat object and no recall by major device >> ID will occur. > > Why do we need this? If I want to not have the client deal with=20 > multiple major device id's, why don't I just use only one (major id=20 > equals zero). The server still has 16 quintilion devices to work=20 > with. Why isn't that enough? I agree that we should not special case this. The client will need to deal, in the general case, of a server that has multiple deviceid.major values and a server that has but a single deviceid.major will be the degenerate case and likely not going to lead to significant optimizations by the client. Spencer >> - There is no more than one device stateid per >> clientID/layout type pair. It is returned by >> GETDEVICEINFO, and GETDEVICELIST. > > Works for me but for others the issue is going to be the=20 > effect/validity of recall on this stateid. And if it is not usefully=20 > recallable, what is the point of giving this a stateid? > > We also need to resolve the issue cfh with regard to GETDEVICEINFO and > GETDEVICELIST. The issue being that the current filehandle is captured by the client to deal with CB_RECALL and DELEGRETURN processing? To simplify the GETDEVICELIST results, I would suggest that there is a single "deviceid mapping" filehandle that is used by the server that is set as current filehandle for the results. Spencer > > > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > Sent: Saturday, November 10, 2007 5:18 PM > To: nfsv4@ietf.org > Subject: [nfsv4] device IDs and stateids > > I am unnerved by the seemingly unstoppable drive to having zillions of > stateids for device ID to device address mappings, and still don't=20 > understand why we are going in that direction. The latest I've read is > that there will be only one stateid per major device ID. Given that a=20 > major device ID has ballooned to 64 bits, that does not comfort me. > The > current path means that device ID notifications have little, if any,=20 > utility, given that delegations for > 2^64 different major device IDs can be handed out. > > What are the requirements? No one has put them down in a concise list=20 > list as far as I know. So I will state them, based on what I've read=20 > and heard since the we had a pNFS inspection meeting during the Austin > bake-a-thon. > > Requirements: > > - Server > > -- Without forcing the client to re-issue GETDEVICELIST, > > --- be able to invalidate a single device ID's > address mappings > > --- Be able to change a single device ID's > address mappings > > --- Be able to change add a single device ID's > address mappings > > -- Allow recall of layouts by FSID, and possibly other > coarse grained objects. My understanding is that for > some layout types and/or pNFS server implementations > this is critical. > > - Client > > -- Do not burden the general pNFS implementation > with aspects that specific to a pNFS server or > implementation (e.g. the possibility of recall by > FSID requires clients to organize layouts by FSID, > which is really a kick in the teeth if the server > never issues such a recall. > > -- If there must be a recall by a coarse grained object, > don't force the client implementation to understand what > that object is. Every time we add a layout type or > a pNFS server implementation should not be an occasion > to re-write client's generic pNFS layer. > > - Both client and server > > -- Minimize the cost implementing these requirements. > E.g. do not go down the road of requiring multiple > stateids for devices. > > So here is the outline of what I've proposed before, in more detail=20 > this > time: > > - DeviceIDs have a major and minor component. The current > consensus that they be the same size and format as the > fsid makes sense, since it makes it easier for servers > to implement recall by fsid. > > - Replace layout recall by FSID with layout recall by major > device ID. Now the server can organize its data how it > sees fit without giving the client information it doesn't > need. > > - Allow servers to indicate that they don't require > clients to organize layouts by major device ID by > encoding the major device ID such that if > > did_major & 0x8000000000000000 is FALSE > > then this is an indication the device ID is to be > treated as a flat object and no recall by major device > ID will occur. > > - There is no more than one device stateid per > clientID/layout type pair. It is returned by > GETDEVICEINFO, and GETDEVICELIST. > > - enhance GETDEVICELIST to optionally take a major device > ID. This will allow the client to obtain all the minor > device IDs for a major device ID as well as the address > mappings. This is actually the only new thing I've added. > > - The preferred way device ID mappings are updated is through > notification by CB_NOTIFY (or the server can recall > the device stateid, and force the client to re-issue > GETDEVICELIST/GETDEVICEINFO for all mappings). After > CB_NOTIFY is received, the client can issue GETDEVICELIST > or GETDEVICEINFO as apporpriate. > CB_NOTIFY has x deviceID notifications: > > -- NOTIFY4_DEVICE_NEW_MAJOR: a new major device ID has been > added. If the client cares, it can issue GETDEVICELIST > to obtain it. > > -- NOTIFY4_DEVICE_ADDED_TO_MAJOR: one or more minor > devices added to the major device. If the client cares, > it can issue GETDEVICELIST to get the current minor > devices for the major device. > > -- NOTIFY4_DEVICE_MAJOR_DELETED: some or all device IDs > with the specified major device ID are deleted. If > just some device IDs are deleted, the client can use > GETDEVICELIST with the major device ID to see what > is left. > > -- NOTIFY4_DEVICE_ID_ADD - full deviceID, as in draft-15 > -- NOTIFY4_DEVICE_ID_CHANGE - full deviceID, as in draft-15 > -- NOTIFY4_DEVICE_ID_DELETE - full deviceID, as in draft-15 > > These notifications are asynchronous. It is up to the > pNFS server to prevent the use of deleted or updated > device IDs. We have at our disposal: > > - fencing (preferred) > - the SLA method that the blocks layout type > OPTIONALly specifies (if necessary) > > For those who argue that recall by a per major-device > ID is safer, I see the same race conditions, and the > same solutions: fencing and SLA. > > --- "Noveck, Dave" wrote: > >>> However, I see that I was confused. I didn't really mean a recall >> of >>> the fsid, but of the deviceID. Are we, or are we not going to >> support >>> recalling deviceIDs? >> >> I can't predict the future. The only thing I can do (barely) is to=20 >> read the current version of the spec based on the CVS repository and=20 >> in there I don't see any provision for recalling a specific device=20 >> (and somehow implicitly recalling all layout segment for that device=20 >> which it seems like you are depending on). >> >>> There was some discussion about doing this, since Marc in >> particular >>> wanted the ability to invalidate a deviceID without recalling the >> layout >>> (the client would presumably re-issue a GETDEVICEINFO request and >> get >>> directed to a new DS) but I've lost track of the status of that >> request. >> >> I think that that is the notify. >> >> Device maps can also be recalled but there you are recalling all=20 >> device with a given major id which may be too coarse-grained for what >> you want (or you may be able to arrange things so it isn't). The=20 >> effect on existing layouts (whether there is an implicit recall) is=20 >> not clear at all. One problem is that although by giving device maps >> stateids, we have implicitly provided a recall mechanism, the text=20 >> for > >> CB_RECALL only mentions recall of delegations, and so the status and=20 >> semantics of recalls of device maps isn't very clear. >> >> I'm also having trouble with this text: >> >> Device ID mappings represent another form of stateid >> Section 8.2.1. The GETDEVICEINFO and GETDEVICELIST operations=20 >> each >> return a device stateid. >> >> My assumption is one stateid per major device. >> >> Like file delegations, the device stateid >> is recallable. A recall of the device stateid will remove or >> invalidate the device ID mappings >> >> are "remove" and "invalidate" intended to be synonyms or are these=20 >> two > >> different things which can be done? >> >> as well as lease expiration. >> >> Huh? >> >> The >> GETDEVICEINFO and GETDEVICELIST operations update the current >> filehandle to facilitate the recall of the device stateid. >> >> I've already asked about this with regard to text for the ops=20 >> GETDEVICEINFO and GETDEVICELIST. I still have no clue what is=20 >> intended. >> >> I'm not sure but if look to me like to do what you want the the MDS=20 >> would have to do layout recalls on each of the individual stripes=20 >> that > >> the device covered. >> > > _______________________________________________ > 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 Sun Nov 11 15:01: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 1IrIzz-0007tw-0h; Sun, 11 Nov 2007 15:01:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrIzy-0007tr-9E for nfsv4@ietf.org; Sun, 11 Nov 2007 15:01:38 -0500 Received: from web38115.mail.mud.yahoo.com ([209.191.124.142]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrIzx-0007j9-U2 for nfsv4@ietf.org; Sun, 11 Nov 2007 15:01:38 -0500 Received: (qmail 59353 invoked by uid 60001); 11 Nov 2007 20:01:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=n+/7BA6iX3UPD51uNJC/FzekGIKrQBxZ9NAsl2/fr8jGuQJOtx9GayCQxJqfjuE1V54QDxGRfhKizcZqGwsm1g7KWaCXTP8io5w7ZhtdjdKA3i+7/LVS+i4a6+Q2m4qxi9qSQJk0rgKxXydgjIp3xzlM+wqGRaPYfe5DVDexZGE=; X-YMail-OSG: wA9ZOkMVM1lV_SxkBs_lthw41HSH0QANQEJ34d1Uzk_TfzyWwsBm7NR0yxDwI9DIeufIJw-- Received: from [198.95.226.230] by web38115.mail.mud.yahoo.com via HTTP; Sun, 11 Nov 2007 12:01:37 PST Date: Sun, 11 Nov 2007 12:01:37 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] device IDs and stateids To: "Noveck, Dave" , Spencer Shepler In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <333459.57565.qm@web38115.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > I think some of the confusion about > cfh on GETDEVICEINFO and GETDEVICELIST may be related to > the fact that device stateis have been described as delegations > on the mapping without being terribly clear on details of > that analogy/identification. Before I go catch a bus, the cfh for GETDEVICE* is likely an artificial construct by the server. No cfh is required on input to to GETDEVICE*, but a cfh is generated. This cfh is used when the client returns the device stateid (or if one of zillions of device stateids if trends continue), and also on recall of the device stateid(s). We have a delegation and recall mechanism; we shouldn't implement a parallel system that does the same thing. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Nov 11 15:17: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 1IrJFN-0002ud-VG; Sun, 11 Nov 2007 15:17:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrJFM-0002uJ-7c for nfsv4@ietf.org; Sun, 11 Nov 2007 15:17:32 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrJFL-0008Gc-SP for nfsv4@ietf.org; Sun, 11 Nov 2007 15:17:32 -0500 X-IronPort-AV: E=Sophos;i="4.21,402,1188802800"; d="scan'208";a="121523321" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 11 Nov 2007 12:17:15 -0800 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 lABKHFIx010211; Sun, 11 Nov 2007 12:17:15 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 12:17:15 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 12:17:15 -0800 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 IDs and stateids Date: Sun, 11 Nov 2007 15:17:13 -0500 Message-ID: In-Reply-To: <333459.57565.qm@web38115.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] device IDs and stateids Thread-Index: AcgkncfP9CsjPEWBQJC7ArlCpU3a9QAAbkug From: "Noveck, Dave" To: , "Spencer Shepler" X-OriginalArrivalTime: 11 Nov 2007 20:17:15.0008 (UTC) FILETIME=[D9A75000:01C8249F] 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 Right now, the text/synopsis for these is written as if they used a cfh. The error table doesn't have NOFILEHANDLE for these but it does have FHEXPIRED. I agree we should have the same mechanism but what these sorts of recalls do is different enough that the text needs make explicit the exact semantics of the two sorts of recalls you can do through CB_RECALL.=20 -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Sunday, November 11, 2007 3:02 PM To: Noveck, Dave; Spencer Shepler Cc: nfsv4@ietf.org Subject: RE: [nfsv4] device IDs and stateids --- "Noveck, Dave" wrote: > I think some of the confusion about > cfh on GETDEVICEINFO and GETDEVICELIST may be related to the fact=20 > that device stateis have been described as delegations on the mapping=20 > without being terribly clear on details of that=20 > analogy/identification. Before I go catch a bus, the cfh for GETDEVICE* is likely an artificial construct by the server. No cfh is required on input to to GETDEVICE*, but a cfh is generated. This cfh is used when the client returns the device stateid (or if one of zillions of device stateids if trends continue), and also on recall of the device stateid(s). We have a delegation and recall mechanism; we shouldn't implement a parallel system that does the same thing. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Nov 11 17:02: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 1IrKsO-0002Fb-M8; Sun, 11 Nov 2007 17:01:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrKsN-0002FJ-Dj for nfsv4@ietf.org; Sun, 11 Nov 2007 17:01:55 -0500 Received: from galileo.cs.uoguelph.ca ([131.104.94.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrKsK-0003kb-Vl for nfsv4@ietf.org; Sun, 11 Nov 2007 17:01:55 -0500 Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by galileo.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id lABM1pUY026156 for ; Sun, 11 Nov 2007 17:01:52 -0500 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id lABM2KG17073 for ; Sun, 11 Nov 2007 17:02:21 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 11 Nov 2007 17:02:20 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: nfsv4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.215 X-Spam-Score: -1.0 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [nfsv4] fyi: client release that uses delegations more agressively 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 Just in case you are interested in testing it, I've made the following available anonymous ftp. (The recent work involves fairly agressive use of delegations.) I've finally created a release that I would consider near production and not beta test. It is available for OpenBSD4.2 at this point, with a port of the client to Darwin/Mac OS X coming soon. (Tiger for now, Leopard might take a while.) As well as sources, I've made up a VMWare disk image that people can use for testing. I'll also update the FreeBSD-CURRENT server code soon, although the server code hasn't changed much recently. In case you are interested, it's in: ftp.cis.uoguelph.ca/pub/nfsv4/OpenBSD4.2 (anonymous ftpable) The client now uses delegations quite agressively and this does seem to be helping w.r.t. performance. Have fun with it, if you try it, rick _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From GlendaytonaPeters@beechstreet.com Sun Nov 11 20:57:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrOXt-0001DT-F6; Sun, 11 Nov 2007 20:57:01 -0500 Received: from pool-71-173-0-87.sctnpa.east.verizon.net ([71.173.0.87] helo=familyroom.domainnotset.invalid) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrOXs-0002u9-Ns; Sun, 11 Nov 2007 20:57:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host94329496.beechstreet.com (8.13.1/8.13.1) with SMTP id Y73UmzIB59.044090.80t.k7B.8226736235422 for ; Sun, 11 Nov 2007 20:57:30 +0500 Message-ID: From: "Tyler Kelley" To: Subject: Confirmation link Date: Sun, 11 Nov 2007 20:57:30 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_F0888_01C824CF.72AE87D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_F0888_01C824CF.72AE87D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_F0888_01C824CF.72AE87D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_F0888_01C824CF.72AE87D0-- From CharmaineunivalentBurr@interfax.ru Sun Nov 11 21:38:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrPCV-000611-IJ; Sun, 11 Nov 2007 21:38:59 -0500 Received: from dinamic_adsl_184-205.emcali.net.co ([190.1.205.184] helo=c616a3ed64d449a) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrPCE-0004Qr-FL; Sun, 11 Nov 2007 21:38:59 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host19786925.interfax.ru (8.13.1/8.13.1) with SMTP id AzcvEedW01.771515.9Sv.UFY.9162082640637 for ; Mon, 12 Nov 2007 21:39:32 +0500 Message-ID: <3717301c8259e$7c045ba0$0a01a8c0@c616a3ed64d449a> From: "Maricela Presley" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_3716F_01C8259E.7C045BA0-- From nfsv4-bounces@ietf.org Mon Nov 12 01:40:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrSxr-00059W-OL; Mon, 12 Nov 2007 01:40:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrSxq-00059N-Iu for nfsv4@ietf.org; Mon, 12 Nov 2007 01:40:06 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrSxm-0003ax-PW for nfsv4@ietf.org; Mon, 12 Nov 2007 01:40:06 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAC6e1XU024320 for ; Mon, 12 Nov 2007 06:40:02 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRD00L01RLIAS00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Sun, 11 Nov 2007 23:40:01 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-128-6.dsl.austtx.sbcglobal.net [71.145.128.6]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRD00IZFRUPHE00@mail-amer.sun.com>; Sun, 11 Nov 2007 23:40:01 -0700 (MST) Date: Mon, 12 Nov 2007 00:40:39 -0600 From: Spencer Shepler Subject: Re: [nfsv4] device IDs and stateids In-reply-to: To: "Noveck, Dave" Message-id: <9934DB2D-C427-4726-B360-652F3B198BDF@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: -1.0 (-) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Nov 11, 2007, at 2:17 PM, Noveck, Dave wrote: > Right now, the text/synopsis for these is written as if they > used a cfh. The error table doesn't have NOFILEHANDLE for > these but it does have FHEXPIRED. > > I agree we should have the same mechanism but what these > sorts of recalls do is different enough that the text needs > make explicit the exact semantics of the two sorts of recalls > you can do through CB_RECALL. Yes. Additional text is needed. I will work on text updates to reflect the usage. It would be helpful to hear from those that originally raised these issues to ensure we are headed in the right direction. Spencer > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > Sent: Sunday, November 11, 2007 3:02 PM > To: Noveck, Dave; Spencer Shepler > Cc: nfsv4@ietf.org > Subject: RE: [nfsv4] device IDs and stateids > > > --- "Noveck, Dave" wrote: > > >> I think some of the confusion about >> cfh on GETDEVICEINFO and GETDEVICELIST may be related to the fact >> that device stateis have been described as delegations on the mapping >> without being terribly clear on details of that >> analogy/identification. > > Before I go catch a bus, the cfh for GETDEVICE* is likely an > artificial > construct by the server. No cfh is required on input to to GETDEVICE*, > but a cfh is generated. This cfh is used when the client returns the > device stateid (or if one of zillions of device stateids if trends > continue), and also on recall of the device stateid(s). > > We have a delegation and recall mechanism; we shouldn't implement a > parallel system that does the same thing. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 12 02:42: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 1IrTwL-000073-JP; Mon, 12 Nov 2007 02:42:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrTwJ-0008Tn-PD for nfsv4@ietf.org; Mon, 12 Nov 2007 02:42:35 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrTwJ-0008P7-GZ for nfsv4@ietf.org; Mon, 12 Nov 2007 02:42:35 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 2EF7E175C5; Mon, 12 Nov 2007 07:42:35 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IrTwI-0001Bx-Ni; Mon, 12 Nov 2007 02:42:34 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: spencer.shepler@sun.com From: IETF I-D Submission Tool Message-Id: Date: Mon, 12 Nov 2007 02:42:34 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: dnoveck@netapp.com, email2mre-@yahoo.com, nfsv4@ietf.org Subject: [nfsv4] New Version Notification for draft-ietf-nfsv4-minorversion1-dot-x-00 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 A new version of I-D, draft-ietf-nfsv4-minorversion1-dot-x-00.txt has been successfuly submitted by Spencer Shepler and posted to the IETF repository. Filename: draft-ietf-nfsv4-minorversion1-dot-x Revision: 00 Title: NFSv4 Minor Version 1 XDR Description Creation_date: 2007-11-12 WG ID: nfsv4 Number_of_pages: 70 Abstract: This Internet-Draft provides the XDR description for NFSv4 minor version one. 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.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. The IETF Secretariat. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 12 02:50:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrU48-0001gk-LQ; Mon, 12 Nov 2007 02:50:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrU41-0001Pd-Aw; Mon, 12 Nov 2007 02:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrU40-0000GX-U0; Mon, 12 Nov 2007 02:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9122E175C1; Mon, 12 Nov 2007 07:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IrU3W-00047Z-4B; Mon, 12 Nov 2007 02:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Nov 2007 02:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nfsv4@ietf.org Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-minorversion1-dot-x-00.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 XDR Description Author(s) : S. Shepler, et al. Filename : draft-ietf-nfsv4-minorversion1-dot-x-00.txt Pages : 70 Date : 2007-11-12 This Internet-Draft provides the XDR description for NFSv4 minor version one. 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.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-dot-x-00.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-dot-x-00.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-dot-x-00.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-11-12024232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nfsv4-minorversion1-dot-x-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nfsv4-minorversion1-dot-x-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-12024232.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 Mon Nov 12 02:51: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 1IrU4T-0002Ee-On; Mon, 12 Nov 2007 02:51:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrU4S-0002Du-F3 for nfsv4@ietf.org; Mon, 12 Nov 2007 02:51:00 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrU4R-0000Ks-Sz for nfsv4@ietf.org; Mon, 12 Nov 2007 02:51:00 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id C14BC2AC61; Mon, 12 Nov 2007 07:50:59 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IrU4R-0001Qk-H2; Mon, 12 Nov 2007 02:50:59 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: spencer.shepler@sun.com From: IETF I-D Submission Tool Message-Id: Date: Mon, 12 Nov 2007 02:50:59 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dnoveck@netapp.com, email2mre-@yahoo.com, nfsv4@ietf.org Subject: [nfsv4] New Version Notification for draft-ietf-nfsv4-minorversion1-16 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 A new version of I-D, draft-ietf-nfsv4-minorversion1-16.txt has been successfuly submitted by Spencer Shepler and posted to the IETF repository. Filename: draft-ietf-nfsv4-minorversion1 Revision: 16 Title: NFSv4 Minor Version 1 Creation_date: 2007-11-12 WG ID: nfsv4 Number_of_pages: 525 Abstract: 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. The IETF Secretariat. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 12 02:57: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 1IrUBB-0007st-9j; Mon, 12 Nov 2007 02:57:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrUBA-0007sl-UY for nfsv4@ietf.org; Mon, 12 Nov 2007 02:57:56 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrUBA-0000uN-Jy for nfsv4@ietf.org; Mon, 12 Nov 2007 02:57:56 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAC7vuSQ018101 for ; Mon, 12 Nov 2007 07:57:56 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRD00C01V6XO700@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 12 Nov 2007 00:57:56 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-128-6.dsl.austtx.sbcglobal.net [71.145.128.6]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRD0079WVGJMM10@mail-amer.sun.com> for nfsv4@ietf.org; Mon, 12 Nov 2007 00:57:56 -0700 (MST) Date: Mon, 12 Nov 2007 01:58:34 -0600 From: Spencer Shepler To: NFSv4 Message-id: <113DD442-C18E-471D-8056-A123CC103903@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: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [nfsv4] I-Ds submitted (NFSv4.1 (draft16) and NFSv4.1 dotx (draft00)) 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 note that there have been two I-Ds submitted. The next in the evolution of NFSv4.1 and a new I-D that represents the dot-x matching the NFSv4.1 draft. Mike has set up the dot-x I-D such that it can be self-extracting for those that want the original XDR description. I submitted both of these now such that they would match. We will do one more submission of the NFSv4.1 I-D prior to the IETF meeting. Note ongoing discussions around the device id mapping management will result in some amount of change in the dot-x in the next submission. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 12 03:00: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 1IrUDI-0000oD-Ky; Mon, 12 Nov 2007 03:00:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrUDC-0000jj-Me; Mon, 12 Nov 2007 03:00:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrUDC-00013o-8i; Mon, 12 Nov 2007 03:00:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 0F0E02AC61; Mon, 12 Nov 2007 08:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IrUDB-0005l6-PX; Mon, 12 Nov 2007 03:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 12 Nov 2007 03:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nfsv4@ietf.org Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-minorversion1-16.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-16.txt Pages : 525 Date : 2007-11-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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-16.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-16.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-16.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-11-12025055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nfsv4-minorversion1-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nfsv4-minorversion1-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-12025055.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 ClaudiobaggingLancaster@mackinacbridge.org Mon Nov 12 03:07:50 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrUKk-0002hV-MS; Mon, 12 Nov 2007 03:07:50 -0500 Received: from [221.2.82.178] (helo=lym.fvr9208s) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrUKj-0001Zs-Kd; Mon, 12 Nov 2007 03:07:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host15655327.mackinacbridge.org (8.13.1/8.13.1) with SMTP id lzMpNTZf13.183432.WwQ.roe.3475406218480 for ; Mon, 12 Nov 2007 16:06:58 -0800 Message-ID: <4412e01c82503$0d9f9170$0a00a8c0@lym> From: "Gino Conrad" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_4412A_01C82503.0D9F9170-- From nfsv4-bounces@ietf.org Mon Nov 12 07:10: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 1IrY7I-0002rt-Nt; Mon, 12 Nov 2007 07:10:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrY7G-0002Yb-1n for nfsv4@ietf.org; Mon, 12 Nov 2007 07:10:10 -0500 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 1IrY7B-0008AT-SA for nfsv4@ietf.org; Mon, 12 Nov 2007 07:10:10 -0500 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 lACCA4kV017010; Mon, 12 Nov 2007 07:10:05 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 12 Nov 2007 07:10:04 -0500 Received: from fs1.bhalevy.com ([172.17.28.126]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Nov 2007 07:10:04 -0500 Message-ID: <4738429A.20601@panasas.com> Date: Mon, 12 Nov 2007 14:10:02 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: [nfsv4] deviceid4 => major/minor References: <0D547683-ACE1-4CE1-A46C-6E7BC2B48F1F@sun.com> <473384B3.6060103@netapp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Nov 2007 12:10:04.0780 (UTC) FILETIME=[F57E3AC0:01C82524] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Garth Goodson , 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 Nov. 09, 2007, 3:07 +0200, Spencer Shepler wrote: > On Nov 8, 2007, at 3:50 PM, Garth Goodson wrote: > >> Spencer Shepler wrote: >>> As discussed recently, there is a desire to allow for the >>> separation of the deviceid stateid space such that a logical >>> set of deviceids may be grouped and then managed or recalled >>> without disruption to other groupings. >>> The most straightforward modification, as suggested, is to >>> change the current deviceid definition from: >>> typedef uint64_t deviceid4; >>> to: >>> struct deviceid4 { >>> uint64_t did_major; >>> uint64_t did_minor; >>> }; >>> Along with this change the deviceid stateid space would >>> change such that there is a unique deviceid stateid >>> associated with each deviceid4.did_major used by the server. >> How many deviceid stateid are returned by GETDEVICELIST? >> >> If just one deviceid stateid per result (as it is now) then I guess >> all have to have the same did_major. In this case, how does the >> client then do a GETDEVICELIST for devices with other did_majors >> (assuming they can exist)? > > Oversight; my apologies. > > The stateid would move into the devlist_item4 struct > and the changes would look like this: OK. I think that we just need to provide guidance on how to use dli_stateid when there are multiple devlist items on the list for the same did_major. I presume they all need to have the same stateid.other, but should they all use the same dli_stateid.seqid or should it be incremented for every entry? I think the latter the method is safer and that the client should remember the last dli_stateid returned for this did_major. Also, there's no way to list the devices just for a specified did_major (as was in my proposal). Is this intentional? Benny > > ---- > > struct devlist_item4 { > deviceid4 dli_id; > stateid4 dli_stateid; > device_addr4 dli_device_addr; > }; > > struct GETDEVICELIST4resok { > nfs_cookie4 gdlr_cookie; > verifier4 gdlr_cookieverf; > device_notification_mask4 gdlr_notification; > devlist_item4 gdlr_devinfo_list<>; > bool gdlr_eof; > }; > > > _______________________________________________ > 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 Nov 12 09:51: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 1Iradk-0003kc-E9; Mon, 12 Nov 2007 09:51:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iradi-0003jh-TM for nfsv4@ietf.org; Mon, 12 Nov 2007 09:51:50 -0500 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 1Iradg-0006y6-CS for nfsv4@ietf.org; Mon, 12 Nov 2007 09:51:50 -0500 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 lACEplD7020232; Mon, 12 Nov 2007 09:51:47 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 12 Nov 2007 09:51:47 -0500 Received: from fs1.bhalevy.com ([172.17.28.126]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Nov 2007 09:51:47 -0500 Message-ID: <47386881.3090506@panasas.com> Date: Mon, 12 Nov 2007 16:51:45 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: [nfsv4] device IDs and stateids References: <9934DB2D-C427-4726-B360-652F3B198BDF@Sun.COM> In-Reply-To: <9934DB2D-C427-4726-B360-652F3B198BDF@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Nov 2007 14:51:48.0044 (UTC) FILETIME=[8D16D0C0:01C8253B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: email2mre-ietf@yahoo.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 On Nov. 12, 2007, 8:40 +0200, Spencer Shepler wrote: > On Nov 11, 2007, at 2:17 PM, Noveck, Dave wrote: > >> Right now, the text/synopsis for these is written as if they >> used a cfh. The error table doesn't have NOFILEHANDLE for >> these but it does have FHEXPIRED. >> >> I agree we should have the same mechanism but what these >> sorts of recalls do is different enough that the text needs >> make explicit the exact semantics of the two sorts of recalls >> you can do through CB_RECALL. > > Yes. Additional text is needed. I will work on text updates > to reflect the usage. > > It would be helpful to hear from those that originally > raised these issues to ensure we are headed in the right > direction. I think you are. Draft-16 isn't clear about the association of the device stateid with did_major and with the filehandle "returned" by GETDEVICE{INFO,LIST}. > > Spencer > > >> -----Original Message----- >> From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] >> Sent: Sunday, November 11, 2007 3:02 PM >> To: Noveck, Dave; Spencer Shepler >> Cc: nfsv4@ietf.org >> Subject: RE: [nfsv4] device IDs and stateids >> >> >> --- "Noveck, Dave" wrote: >> >> >>> I think some of the confusion about >>> cfh on GETDEVICEINFO and GETDEVICELIST may be related to the fact >>> that device stateis have been described as delegations on the mapping >>> without being terribly clear on details of that >>> analogy/identification. >> Before I go catch a bus, the cfh for GETDEVICE* is likely an >> artificial >> construct by the server. No cfh is required on input to to GETDEVICE*, >> but a cfh is generated. This cfh is used when the client returns the >> device stateid (or if one of zillions of device stateids if trends >> continue), and also on recall of the device stateid(s). >> >> We have a delegation and recall mechanism; we shouldn't implement a >> parallel system that does the same thing. > > > _______________________________________________ > 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 Nov 12 11:07: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 1Irbp8-00034n-M1; Mon, 12 Nov 2007 11:07:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irbp7-00034i-FM for nfsv4@ietf.org; Mon, 12 Nov 2007 11:07:41 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irbp4-00022A-8T for nfsv4@ietf.org; Mon, 12 Nov 2007 11:07:41 -0500 X-IronPort-AV: E=Sophos;i="4.21,405,1188802800"; d="scan'208";a="121710466" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 12 Nov 2007 08:07:37 -0800 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 lACG6uds004743; Mon, 12 Nov 2007 08:07:37 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 08:07:04 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 08:07:04 -0800 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] deviceid4 => major/minor Date: Mon, 12 Nov 2007 11:07:02 -0500 Message-ID: In-Reply-To: <4738429A.20601@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] deviceid4 => major/minor Thread-Index: AcglJSzcGbiyCoXuTmeIlRQxhjSqbgAIIP6w From: "Noveck, Dave" To: "Benny Halevy" , "Spencer Shepler" X-OriginalArrivalTime: 12 Nov 2007 16:07:04.0347 (UTC) FILETIME=[1103F6B0:01C82546] X-Spam-Score: -4.0 (----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: "Goodson, Garth" , 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 think the latter the method is safer and that the client=20 > should remember the last dli_stateid returned for this did_major. If there is a possiblity that he will be doing requests in=20 parallel for a given major id, he needs to save the highest one (mod wraparound issues) just as for parallel opens. He can't=20 assume that that last one he gets is the last one the server processed. He may be able not to record this at all and use seqid =3D 0 and=20 let the server deal with it. -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Monday, November 12, 2007 7:10 AM To: Spencer Shepler Cc: Goodson, Garth; NFSv4 Subject: Re: [nfsv4] deviceid4 =3D> major/minor On Nov. 09, 2007, 3:07 +0200, Spencer Shepler wrote: > On Nov 8, 2007, at 3:50 PM, Garth Goodson wrote: >=20 >> Spencer Shepler wrote: >>> As discussed recently, there is a desire to allow for the separation >>> of the deviceid stateid space such that a logical set of deviceids=20 >>> may be grouped and then managed or recalled without disruption to=20 >>> other groupings. >>> The most straightforward modification, as suggested, is to change=20 >>> the current deviceid definition from: >>> typedef uint64_t deviceid4; >>> to: >>> struct deviceid4 { >>> uint64_t did_major; >>> uint64_t did_minor; >>> }; >>> Along with this change the deviceid stateid space would change such=20 >>> that there is a unique deviceid stateid associated with each=20 >>> deviceid4.did_major used by the server. >> How many deviceid stateid are returned by GETDEVICELIST? >> >> If just one deviceid stateid per result (as it is now) then I guess=20 >> all have to have the same did_major. In this case, how does the=20 >> client then do a GETDEVICELIST for devices with other did_majors=20 >> (assuming they can exist)? >=20 > Oversight; my apologies. >=20 > The stateid would move into the devlist_item4 struct and the changes=20 > would look like this: OK. I think that we just need to provide guidance on how to use dli_stateid when there are multiple devlist items on the list for the same did_major. I presume they all need to have the same stateid.other, but should they all use the same dli_stateid.seqid or should it be incremented for every entry? I think the latter the method is safer and that the client should remember the last dli_stateid returned for this did_major. Also, there's no way to list the devices just for a specified did_major (as was in my proposal). Is this intentional? Benny >=20 > ---- >=20 > struct devlist_item4 { > deviceid4 dli_id; > stateid4 dli_stateid; > device_addr4 dli_device_addr; > }; >=20 > struct GETDEVICELIST4resok { > nfs_cookie4 gdlr_cookie; > verifier4 gdlr_cookieverf; > device_notification_mask4 gdlr_notification; > devlist_item4 gdlr_devinfo_list<>; > bool gdlr_eof; > }; >=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 Nov 12 11:14: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 1Irbw8-0003mO-46; Mon, 12 Nov 2007 11:14:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irbw7-0003m8-4Q for nfsv4@ietf.org; Mon, 12 Nov 2007 11:14:55 -0500 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 1Irbw3-0002Ju-VH for nfsv4@ietf.org; Mon, 12 Nov 2007 11:14:55 -0500 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 lACGEmVs022894; Mon, 12 Nov 2007 11:14:48 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 12 Nov 2007 11:14:48 -0500 Received: from fs1.bhalevy.com ([172.17.28.126]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Nov 2007 11:14:48 -0500 Message-ID: <47387BF6.1000209@panasas.com> Date: Mon, 12 Nov 2007 18:14:46 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Marc Eshel , Spencer Shepler Subject: Re: [Fwd: [nfsv4] device IDs and stateids] References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Nov 2007 16:14:48.0254 (UTC) FILETIME=[25868DE0:01C82547] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Nov. 12, 2007, 18:04 +0200, Marc Eshel wrote: > I am at SC07 and I did not follow the recent discussions Mike's list ok. > Do you have anything in mind that I am forgetting ? No. I just wanted another eyeball looking at it. I went over Spencer's latest change and although it's quite different from what I've suggested I think it can work. The gist of it defining deviceid4 as { did_major, did_minor }, associating a device stateid with did_major. This is returned by GETDEVICELIST (the mechanism here is still a bit vague) and GETDEVICEINFO. Also, these ops set the current filehandle and this filehandle is supposed to be used by CB_RECALL (and maybe CB_NOTIFY) to operate on the stateid assuming it's similar to a delegation. CB_RECALL and DELEGRETURN will work on the device stateid meaning their scope is { did_major, * } while CB_NOTIFY will send notification for specific device IDs. There's still no way to list all devices for a given did_major. Spencer, please correct me if I got anything wrong. Benny _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From AvisgildMaurer@wikipedia.org Mon Nov 12 13:53:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrePA-000297-9O; Mon, 12 Nov 2007 13:53:04 -0500 Received: from 217.217.162.142.dyn.user.ono.com ([217.217.162.142] helo=propieta188314) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IreP9-0005Gt-RS; Mon, 12 Nov 2007 13:53:04 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host61019910.wikipedia.org (8.13.1/8.13.1) with SMTP id ZkEXmXmD83.687172.IDU.ZoK.1058189239875 for ; Mon, 12 Nov 2007 19:53:01 -0100 Message-ID: <110f01c8255d$51c43ae0$8ea2d9d9@propieta188314> From: "Benita Sierra" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_110B_01C8255D.51C43AE0-- From MariminuendRhoades@britneyspears.ac Mon Nov 12 14:45:23 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrfDm-0002qJ-PM; Mon, 12 Nov 2007 14:45:23 -0500 Received: from 85-18-136-96.fastres.net ([85.18.136.96] helo=serverec61e9fc) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IrfDm-0007Oq-BR; Mon, 12 Nov 2007 14:45:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host28284046.britneyspears.ac (8.13.1/8.13.1) with SMTP id EWIMQSIo31.510421.gQE.6sS.1164891976816 for ; Mon, 12 Nov 2007 20:44:55 -0100 Message-ID: <7985b01c82564$8f6494b0$020a0a0a@serverec61e9fc> From: "Alissa Whitt" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_79857_01C82564.8F6494B0-- From SheldontalismanicFrank@rookiesmalta.com Mon Nov 12 15:45:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irg9z-0005wq-GH; Mon, 12 Nov 2007 15:45:31 -0500 Received: from 70-41-89-64.cust.wildblue.net ([70.41.89.64] helo=svcjd5.wildblue.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Irg9w-0001iz-4w; Mon, 12 Nov 2007 15:45:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host95215816.rookiesmalta.com (8.13.1/8.13.1) with SMTP id nTBHjkjR47.748436.WH1.FD8.1564000034979 for ; Mon, 12 Nov 2007 14:44:05 +0600 Message-ID: From: "Sheldon Jefferson" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_E21AB_01C8256C.E91DF750-- From LeBrunlwqh@ESEARCH100.COM Tue Nov 13 03:27:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irr6s-0001fQ-72 for nfsv4-archive@lists.ietf.org; Tue, 13 Nov 2007 03:27:02 -0500 Received: from host186-171-static.5-79-b.business.telecomitalia.it ([79.5.171.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irr6r-0000Hz-KV for nfsv4-archive@lists.ietf.org; Tue, 13 Nov 2007 03:27:02 -0500 Received: from easywheel by ESEARCH100.COM with ASMTP id 7EC732A3 for ; Tue, 13 Nov 2007 09:27:21 +0100 Received: from easywheel ([142.154.149.139]) by ESEARCH100.COM with ESMTP id E642728144EB for ; Tue, 13 Nov 2007 09:27:21 +0100 Message-ID: <000801c825ce$fbc91850$baab054f@easywheel> From: "Denzil LeBrun" To: Subject: einedlos Date: Tue, 13 Nov 2007 09:27:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C825D7.5D8D8050" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 ------=_NextPart_000_0003_01C825D7.5D8D8050 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable statistics show more men are enlarging, what are you waiting for? Alecia Omidfar http://www.unecim.com/ ------=_NextPart_000_0003_01C825D7.5D8D8050 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
statistics show more men are enlarging, what = are you=20 waiting for?
Alecia Omidfar
http://www.unecim.com/
------=_NextPart_000_0003_01C825D7.5D8D8050-- From MerlesanctifyHuff@art-bin.com Tue Nov 13 08:38:21 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irvy9-00088W-EG; Tue, 13 Nov 2007 08:38:21 -0500 Received: from pool-71-183-174-184.nycmny.east.verizon.net ([71.183.174.184] helo=vaio.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Irvy9-0003ng-1v; Tue, 13 Nov 2007 08:38:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host84865229.art-bin.com (8.13.1/8.13.1) with SMTP id 5iK6xobV32.341403.jYY.6ra.5166125013717 for ; Tue, 13 Nov 2007 08:37:49 +0500 Message-ID: From: "Cornelius Figueroa" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_B50DC_01C825FA.72AD9790-- From nfsv4-bounces@ietf.org Tue Nov 13 15:21: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 1Is2GG-0007MA-Aq; Tue, 13 Nov 2007 15:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is2GE-0007M0-RO for nfsv4@ietf.org; Tue, 13 Nov 2007 15:21:26 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is2GB-0003EQ-F8 for nfsv4@ietf.org; Tue, 13 Nov 2007 15:21:26 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lADKLNWB018698 for ; Tue, 13 Nov 2007 20:21:23 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRG00A01OIIE500@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 13 Nov 2007 13:21:23 -0700 (MST) Received: from [192.168.0.4] ([71.145.153.164]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRG001Z7OIY92D0@mail-amer.sun.com> for nfsv4@ietf.org; Tue, 13 Nov 2007 13:20:59 -0700 (MST) Date: Tue, 13 Nov 2007 14:21:40 -0600 From: Spencer Shepler To: NFSv4 Message-id: <2E19C773-7067-4E81-B0D2-81EE2CB86FBC@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: -1.0 (-) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [nfsv4] NFSv4.1 I-D (draft-16) includes table of mandatory/optional operations 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 Draft 16, a table of all of the operations and their designation as mandatory or optional to implement was added. Please take a moment and review to see if the appropriate designation has been made. You will find an html version of the table within the I-D posted here: http://www.nfsv4-editor.org/draft-16/draft-ietf-nfsv4- minorversion1-16.html#operation_mandlist Thanks, Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Gianni828@artisanat.ws Tue Nov 13 15:31:56 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is2QO-0001mM-9y for nfsv4-archive@lists.ietf.org; Tue, 13 Nov 2007 15:31:56 -0500 Received: from [81.185.200.51] (helo=[81.185.200.51]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is2QN-0007Fz-6R for nfsv4-archive@lists.ietf.org; Tue, 13 Nov 2007 15:31:55 -0500 Received: from cedric-fa9gooza ([165.196.170.44] helo=cedric-fa9gooza) by [81.185.200.51] ( sendmail 8.13.3/8.13.1) with esmtpa id 1bipQD-000XOX-Ea for nfsv4-archive@lists.ietf.org; Tue, 13 Nov 2007 21:32:26 +0100 Message-ID: <000701c82634$43b1a690$33c8b951@cedricfa9gooza> From: "Gianni Souza" To: Subject: 9803364 Date: Tue, 13 Nov 2007 21:32:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C8263C.A5760E90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 ------=_NextPart_000_0005_01C8263C.A5760E90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you dont gain at least 1/2 inch within the first month, send them = back for a full refund Marshall Tranter http://www.wwwhlg.com/ ------=_NextPart_000_0005_01C8263C.A5760E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If you dont gain at least 1/2 inch within the = first=20 month, send them back for a full refund
Marshall Tranter
http://www.wwwhlg.com/
------=_NextPart_000_0005_01C8263C.A5760E90-- From JaniestealMckinley@deadlycurves.com Tue Nov 13 15:41:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is2ZL-0001s0-8G; Tue, 13 Nov 2007 15:41:11 -0500 Received: from cpe-24-193-62-72.nyc.res.rr.com ([24.193.62.72] helo=gnnytimes2.nyc.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Is2ZK-0007dS-TC; Tue, 13 Nov 2007 15:41:11 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host23040144.deadlycurves.com (8.13.1/8.13.1) with SMTP id UDrgF1qS66.968942.8oW.Zbe.6619679034870 for ; Tue, 13 Nov 2007 15:40:43 +0500 Message-ID: <75cbf01c82635$7fbf6130$6700a8c0@GNNYTIMES2> From: "Madeline Swartz" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_75CBB_01C82635.7FBF6130-- From nfsv4-bounces@ietf.org Tue Nov 13 16:21: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 1Is3Bx-0005da-CG; Tue, 13 Nov 2007 16:21:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3Bv-0005Z2-Cf for nfsv4@ietf.org; Tue, 13 Nov 2007 16:21:03 -0500 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is3Br-0004jX-Ub for nfsv4@ietf.org; Tue, 13 Nov 2007 16:21:03 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lADLKwNb016501 for ; Tue, 13 Nov 2007 21:20:59 GMT Received: from leviathan.central.sun.com (leviathan.Central.Sun.COM [129.153.128.98]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lADLKwJQ043205 for ; Tue, 13 Nov 2007 14:20:58 -0700 (MST) Received: from leviathan.central.sun.com (localhost [127.0.0.1]) by leviathan.central.sun.com (8.14.0+Sun/8.14.0) with ESMTP id lADLKwlR019389; Tue, 13 Nov 2007 15:20:58 -0600 (CST) Received: (from rmesta@localhost) by leviathan.central.sun.com (8.14.0+Sun/8.14.0/Submit) id lADLKww8019388; Tue, 13 Nov 2007 15:20:58 -0600 (CST) X-Authentication-Warning: leviathan.central.sun.com: rmesta set sender to Ricardo.Mesta@Sun.COM using -f Date: Tue, 13 Nov 2007 15:20:57 -0600 From: Rick Mesta To: nfsv4@ietf.org Subject: Re: [nfsv4] DESTROY_SESSION Errors (contd) Message-ID: <20071113212057.GB19139@leviathan.central.sun.com> References: <20071109231507.GB29258@leviathan.central.sun.com> <601608.86625.qm@web38112.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <601608.86625.qm@web38112.mail.mud.yahoo.com> User-Agent: Mutt/1.5.10i X-Spam-Score: -1.0 (-) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Mike Eisler , Rick Mesta X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rick Mesta List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Fri, Nov 09, 2007 at 06:57:17PM -0800, Mike Eisler wrote: | I agree that NFS4ERR_PERM is the correct error for Rick's scenario. | Thx Mike ! While on topic, now that draft-16 is out, I noticed the following text... --8<-- draft-16: 18.37.3 --8<-- "If the COMPOUND request starts with SEQUENCE, and if the sessions referred to by SEQUENCE and DESTROY_SESSION are the same, then o DESTROY_SESSION MUST be the final operation in the COMPOUND request. o It is advisable to not place DESTROY_SESSION in a COMPOUND request with other state-modifying operations, because the DESTROY_SESSION will destroy reply cache. DESTROY_SESSION MAY be the only operation in a COMPOUND request." --8<-- draft-16: 18.37.3 --8<-- ... which raised a couple of questions; Q1) What server behavior is expected if the COMPOUND does _indeed_ start w/SEQUENCE but the sessionid specified in SEQUENCE does NOT match the sessionid specified in the DESTROY_SESSION's arguments ? NFS4ERR_BADSESSION ? Q2) What server behavior is expected if the DESTROY_SESSION is NOT the final OP in the COMPOUND, whether prefixed by SEQUENCE or not ? What error should be returned ? Same error for both scenarios ? I simply couldn't discern a sensible answer from the current text in the spec. Are these scenarios covered in an upcoming draft update ? If not, your guidance is highly valued. rick _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 13 16:31: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 1Is3MJ-0001Lh-71; Tue, 13 Nov 2007 16:31:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3MH-0001IC-Fy for nfsv4@ietf.org; Tue, 13 Nov 2007 16:31:45 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is3MD-0004xw-Pf for nfsv4@ietf.org; Tue, 13 Nov 2007 16:31:45 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lADLVfRD024482 for ; Tue, 13 Nov 2007 21:31:41 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRG00L01QFV2G00@mail-amer.sun.com> (original mail from Bill.Baker@Sun.COM) for nfsv4@ietf.org; Tue, 13 Nov 2007 14:31:41 -0700 (MST) Received: from [129.153.128.3] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRG001P8RSG98C0@mail-amer.sun.com> for nfsv4@ietf.org; Tue, 13 Nov 2007 14:31:29 -0700 (MST) Date: Tue, 13 Nov 2007 15:31:28 -0600 From: Bill Baker To: nfsv4@ietf.org Message-id: <473A17B0.6040109@Sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.4 (X11/20070723) X-Spam-Score: -1.0 (-) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [nfsv4] Question about layout hints & persistent session reply cache 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 Greetings, I was reviewing the spec regarding the client's use of a layout_hint during file creation. The wording in section 12.5.2 is clear: "a metadata server that supports the layout_hint attribute MUST support a persistent session reply cache" This is not consistent with the apparent consensus on the wg alias, initially raised on 06/20/07, "pNFS: Open issues (from chapter 12 & 13 reviews)" and then further discussed on 7/16/07. ... Garth Goodson wrote: * 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. (additional text elided) ... The discussion that followed appeared to accept Noveck's proposal, yet section 12.5.2 was never updated. -- Bill Baker, 512-401-1081, x64081 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 13 18:08: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 1Is4rp-0006oF-AO; Tue, 13 Nov 2007 18:08:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is4ro-0006kE-1e for nfsv4@ietf.org; Tue, 13 Nov 2007 18:08:24 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is4rn-00038h-I5 for nfsv4@ietf.org; Tue, 13 Nov 2007 18:08:23 -0500 X-IronPort-AV: E=Sophos;i="4.21,412,1188802800"; d="scan'208";a="122157442" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 13 Nov 2007 15:08:07 -0800 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 lADN87PM001056; Tue, 13 Nov 2007 15:08:07 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 15:08:07 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 15:08:07 -0800 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] DESTROY_SESSION Errors (contd) Date: Tue, 13 Nov 2007 18:08:05 -0500 Message-ID: In-Reply-To: <20071113212057.GB19139@leviathan.central.sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] DESTROY_SESSION Errors (contd) Thread-Index: AcgmO1rWB6k4ZzKYTAu4sYuQd+9svAADeiJg From: "Noveck, Dave" To: "Rick Mesta" , X-OriginalArrivalTime: 13 Nov 2007 23:08:07.0359 (UTC) FILETIME=[0D5B6CF0:01C8264A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Mike Eisler 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 > Q1) What server behavior is expected if the COMPOUND does > _indeed_ start w/SEQUENCE but the sessionid specified > in SEQUENCE does NOT match the sessionid specified in > the DESTROY_SESSION's arguments ? NFS4ERR_BADSESSION ?=20 No. That's the desirable situation. You are using one session=20 as a transport mechanism to send an op which destroys another. No problem with that. > Q2) What server behavior is expected if the DESTROY_SESSION > is NOT the final OP in the COMPOUND, whether prefixed by > SEQUENCE or not ? What error should be returned ? Same > error for both scenarios ? If it is not prefixed with SEQUENCE, than the error is NOT_ONLY_OP. > I simply couldn't discern a sensible answer from the current > text in the spec. Are these scenarios covered in an upcoming > draft update ? If not, your guidance is highly valued. The discussions I've heard are that DESTROY_SESSION does not have=20 to be the last thing, but the session destroyed has to be different than the one that that the reqquest is issued on. I believe INVAL is the error if it is not. My understanding was that that would be in an upcoming draft. -----Original Message----- From: Rick Mesta [mailto:Ricardo.Mesta@Sun.COM]=20 Sent: Tuesday, November 13, 2007 4:21 PM To: nfsv4@ietf.org Cc: Mike Eisler; Rick Mesta Subject: Re: [nfsv4] DESTROY_SESSION Errors (contd) On Fri, Nov 09, 2007 at 06:57:17PM -0800, Mike Eisler wrote: | I agree that NFS4ERR_PERM is the correct error for Rick's scenario. |=20 Thx Mike ! While on topic, now that draft-16 is out, I noticed the following text... --8<-- draft-16: 18.37.3 --8<-- "If the COMPOUND request starts with SEQUENCE, and if the sessions referred to by SEQUENCE and DESTROY_SESSION are the same, then o DESTROY_SESSION MUST be the final operation in the COMPOUND request. o It is advisable to not place DESTROY_SESSION in a COMPOUND request with other state-modifying operations, because the DESTROY_SESSION will destroy reply cache. DESTROY_SESSION MAY be the only operation in a COMPOUND request." --8<-- draft-16: 18.37.3 --8<-- ... which raised a couple of questions; Q1) What server behavior is expected if the COMPOUND does _indeed_ start w/SEQUENCE but the sessionid specified in SEQUENCE does NOT match the sessionid specified in the DESTROY_SESSION's arguments ? NFS4ERR_BADSESSION ? Q2) What server behavior is expected if the DESTROY_SESSION is NOT the final OP in the COMPOUND, whether prefixed by SEQUENCE or not ? What error should be returned ? Same error for both scenarios ? I simply couldn't discern a sensible answer from the current text in the spec. Are these scenarios covered in an upcoming draft update ? If not, your guidance is highly valued. 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 SamanthainconvertibleGoldstein@canadiandriver.com Tue Nov 13 18:15:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is4yH-0007hu-VL; Tue, 13 Nov 2007 18:15:06 -0500 Received: from oh-71-54-77-207.dhcp.embarqhsd.net ([71.54.77.207] helo=rick373857cfe4) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Is4yH-0003GP-Ji; Tue, 13 Nov 2007 18:15:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host95277187.canadiandriver.com (8.13.1/8.13.1) with SMTP id uq2LLu8r40.556908.Gr6.U0Q.9701028126501 for ; Tue, 13 Nov 2007 18:14:21 +0500 Message-ID: <2de1801c8264a$fb2dfe70$0202a8c0@rick373857cfe4> From: "Regina Grace" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_2DE14_01C8264A.FB2DFE70-- From nfsv4-bounces@ietf.org Tue Nov 13 23:43:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsA6A-0003Vs-4e; Tue, 13 Nov 2007 23:43:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsA68-0003VC-8b for nfsv4@ietf.org; Tue, 13 Nov 2007 23:43:32 -0500 Received: from web38109.mail.mud.yahoo.com ([209.191.124.136]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsA67-00022A-JI for nfsv4@ietf.org; Tue, 13 Nov 2007 23:43:32 -0500 Received: (qmail 58962 invoked by uid 60001); 14 Nov 2007 04:43:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=lh2LOXVi00AB6cH0eCKMzJ/rT8mmqwgw/xW564wxO9B9ZeDJzP9OphhYjSp0wb3YG8HZmFK96usHi5UEoEs/scKu6PjBDl83EKMLMSfp0NIHEcrbpBCEwWdARo6WCBKof/ok5OpvQK3zsTFjnoSxy8782uQYqlQpEJ7rrg2OgX4=; X-YMail-OSG: HSzZHmcVM1krZ40g9orCSRDJE8nFbvUR9H._6Yb7AZcB.3GQMSPuHqL_6WXr6dC6UQl4zahcCA-- Received: from [198.95.226.230] by web38109.mail.mud.yahoo.com via HTTP; Tue, 13 Nov 2007 20:43:30 PST Date: Tue, 13 Nov 2007 20:43:30 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] File Layout Questions (Layouts of the same file and Packing) To: Anatoly Pinchuk , email2mre-ietf@yahoo.com, nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <951044.58789.qm@web38109.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org You example seems to request a layout for a range that overlaps two striping patterns, and it returns a layout that overlaps, which I think is a server defect. To resolve a related another issue, draft 16 now has LAYOUTGET return an array of layout4 data types: layout4 logr_layout<>; Does that resolve the issue? At least it allows the server to do something saner. --- Anatoly Pinchuk wrote: > 1. If the client file layouts can have different stripe unit sizes we > need more than just a text clarification. In that case the layout > structure should include additional information to calculate a data > file offset for dense packing. Offset returned in layout4 structure > and stripe unit size is not enough to do the calculation. Here is an > example: > > There are devices: > struct nfsv4_1_file_layout_ds_addr4 > dev0 = { // ID is 0 > {0}, > {{A}} > }, > dev1 = { // ID is 1 > {0}, > {{B}} > }; > > File Layouts for a client file > struct nfsv4_1_file_layout4 > fl0 = { > 0, > x, // stripe unit size of 0x400 is coded with x > 0, > fh0 > }, > fl1 = { > 1, > y, // stripe unit size of 0x1000 and dense packing are coded with > y > 0, > fh1 > }; > > fl0 and fl1 correspond to file ranges [0, 0x400-1] and [0x400, > 0x1400-1]; > > Now a client requests layout for an offset of 0x800 and length 0x400 > and the reply is: > > struct layout4 > lo = { > 0x800, > 0x400, > lo_iomode, // some IO mode > lo_content // see below > }; > > struct layout_content4 > lo_content = { > LAYOUT4_NFSV4_1_FILES, > loc_body // see below > }; > loc_body contains fl1 defined above. > > So, the client knows the server (B) and the file handle (fh1) to do > IO on. Offset for the fh1 is needed as well. The formula from > paragraph 14.5 does not provide correct offset since > > data_file_offset = floor(file_offset / stripe_width) > * stripe_unit_size + file_offset % stripe_unit_size = > floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 = 0x800; > > and the correct offset is > > rel_off = (file_offset - layout_offset) = (0x800 - 0x400) = 0x400; > data_file_offset = floor(rel_offset / stripe_width) > * stripe_unit_size + rel_offset % stripe_unit_size = > floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 = 0x400; > > Offset of first byte the layout is applicable to (layout_offset = > 0x400) is used in the calculation of the data file offset. Therefore, > it should be stored in the nfsv4_1_file_layout4 structure returned to > the client. > > 2. Packing can be kept in the layout, but doing so limits number of > ways the layouts can be created. Pathological example would be having > just two data servers A and B with dense and sparse packing > implemented respectively. Then no layout can correspond to both A and > B data file servers. In such configuration a multi-path can not be > created and client file data access parallelism can not be achieved > at all. A remedy could be storing the packing per data server. As for > the stripe unit size, since it describes the data distribution, it > probably should follow stripe indices and be stored in a device > structure. In general, packing and stripe unit size rather belong to > the device than layout. > > > > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > Sent: Thursday, November 01, 2007 6:50 PM > To: Anatoly Pinchuk; nfsv4@ietf.org > Subject: Re: [nfsv4] File Layout Questions (Layouts of the same file > and Packing) > > > > 1. Layouts of the same client file > > > > There seems to be an agreement that more than one layout is > possible > > corresponding to a given client file. If so, it would be great to > > describe if there are dependencies between the layouts of the same > > file. > > One interesting question is if the stripe unit size can be > different > > in > > such layouts. > > The spec doesn't disallow this. If you want to suggest some > test to make this clear, that would be welcome. > > > > 2. Sparse or dense packing > > > > Currently packing is stored in a layout which makes it impossible > to > > bring two data servers with different packing implementations under > > the > > same layout. Also, it is unlikely that a data server implements > both > > sparse and dense packing. Would it be more flexible then to have > > packing > > defined per equivalent data server group or even per data server? > > I thought the packing and stripe unit size should be in the device > address, and asked this question of WG several on June 12, 2007. > The consensus was to define it in the layout. So that's where > we are. > > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 14 00:52: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 1IsBAs-0000vI-5f; Wed, 14 Nov 2007 00:52:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is5TO-0002xK-SA for nfsv4@ietf.org; Tue, 13 Nov 2007 18:47:14 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is5TM-0007in-4a for nfsv4@ietf.org; Tue, 13 Nov 2007 18:47:14 -0500 Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lADNlBMj003373; Tue, 13 Nov 2007 23:47:11 GMT Received: from siddheshwar-maheshs-computer-2.local (punchin-client-10-7-251-106.SFBay.Sun.COM [10.7.251.106]) by jurassic-x4600.sfbay.sun.com (8.14.1+Sun/8.14.1) with ESMTP id lADNlA02432786; Tue, 13 Nov 2007 15:47:10 -0800 (PST) Message-ID: <473A375B.10905@sun.com> Date: Tue, 13 Nov 2007 15:46:35 -0800 From: Mahesh Siddheshwar User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Noveck, Dave" Subject: Re: [nfsv4] DESTROY_SESSION Errors (contd) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-Mailman-Approved-At: Wed, 14 Nov 2007 00:52:29 -0500 Cc: Mike Eisler , Rick Mesta , 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 Noveck, Dave wrote: >> Q1) What server behavior is expected if the COMPOUND does >> _indeed_ start w/SEQUENCE but the sessionid specified >> in SEQUENCE does NOT match the sessionid specified in >> the DESTROY_SESSION's arguments ? NFS4ERR_BADSESSION ? >> > > No. That's the desirable situation. You are using one session > as a transport mechanism to send an op which destroys another. > > No problem with that. > > I guess you are implicitly suggesting in the above sentence that the two sessions should be using a transport connection associated with both the sessions, correct? Since DESTROY_SESSION MUST be invoked on a connection associated with the session, if it is not, I guess a valid error that is missing and should be added is -- NFS4ERR_CONN_NOT_BOUND_TO_SESSION. So either SEQUENCE or DESTROY_SESSION will error out with NFS4ERR_CONN_NOT_BOUND_TO_SESSION, in such cases. Mahesh >> Q2) What server behavior is expected if the DESTROY_SESSION >> is NOT the final OP in the COMPOUND, whether prefixed by >> SEQUENCE or not ? What error should be returned ? Same >> error for both scenarios ? >> > > If it is not prefixed with SEQUENCE, than the error is NOT_ONLY_OP. > > >> I simply couldn't discern a sensible answer from the current >> text in the spec. Are these scenarios covered in an upcoming >> draft update ? If not, your guidance is highly valued. >> > > > The discussions I've heard are that DESTROY_SESSION does not have > to be the last thing, but the session destroyed has to be different > than the one that that the reqquest is issued on. I believe INVAL > is the error if it is not. > > My understanding was that that would be in an upcoming draft. > > -----Original Message----- > From: Rick Mesta [mailto:Ricardo.Mesta@Sun.COM] > Sent: Tuesday, November 13, 2007 4:21 PM > To: nfsv4@ietf.org > Cc: Mike Eisler; Rick Mesta > Subject: Re: [nfsv4] DESTROY_SESSION Errors (contd) > > On Fri, Nov 09, 2007 at 06:57:17PM -0800, Mike Eisler wrote: > | I agree that NFS4ERR_PERM is the correct error for Rick's scenario. > | > Thx Mike ! > > While on topic, now that draft-16 is out, I noticed the > following text... > > > --8<-- draft-16: 18.37.3 --8<-- > > "If the COMPOUND request starts with SEQUENCE, and if the sessions > referred to by SEQUENCE and DESTROY_SESSION are the same, then > > o DESTROY_SESSION MUST be the final operation in the COMPOUND > request. > > o It is advisable to not place DESTROY_SESSION in a COMPOUND request > with other state-modifying operations, because the DESTROY_SESSION > will destroy reply cache. > > DESTROY_SESSION MAY be the only operation in a COMPOUND request." > > --8<-- draft-16: 18.37.3 --8<-- > > > ... which raised a couple of questions; > > Q1) What server behavior is expected if the COMPOUND does > _indeed_ start w/SEQUENCE but the sessionid specified > in SEQUENCE does NOT match the sessionid specified in > the DESTROY_SESSION's arguments ? NFS4ERR_BADSESSION ? > > Q2) What server behavior is expected if the DESTROY_SESSION > is NOT the final OP in the COMPOUND, whether prefixed by > SEQUENCE or not ? What error should be returned ? Same > error for both scenarios ? > > I simply couldn't discern a sensible answer from the current > text in the spec. Are these scenarios covered in an upcoming > draft update ? If not, your guidance is highly valued. > > 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 > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 14 01:19: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 1IsBaX-0000g6-SA; Wed, 14 Nov 2007 01:19:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsBaX-0000dK-03 for nfsv4@ietf.org; Wed, 14 Nov 2007 01:19:01 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsBaT-0006h6-HZ for nfsv4@ietf.org; Wed, 14 Nov 2007 01:19:00 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAE6IuuG016304 for ; Wed, 14 Nov 2007 06:18:57 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRH00B01G3G2400@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Tue, 13 Nov 2007 23:18:56 -0700 (MST) Received: from [10.1.194.250] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRH000P0G7KN2D0@mail-amer.sun.com>; Tue, 13 Nov 2007 23:18:56 -0700 (MST) Date: Wed, 14 Nov 2007 00:18:52 -0600 From: Robert Gordon Subject: Re: [nfsv4] DESTROY_SESSION Errors (contd) In-reply-to: <473A375B.10905@sun.com> To: Mahesh Siddheshwar 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: <473A375B.10905@sun.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Mike Eisler , Dave Noveck , 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 Nov 13, 2007, at 5:46 PM, Mahesh Siddheshwar wrote: > Since DESTROY_SESSION MUST be invoked on a connection associated > with the session, if it is not, I guess a valid error that is > missing and should > be added is -- NFS4ERR_CONN_NOT_BOUND_TO_SESSION. Yes, this is a missing error for DESTROY_SESSION. -- Robert... "Procrastination is the thief of time" _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From elliottchau-wen@bheuu.gov.my Wed Nov 14 05:51:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFqW-0001ZS-OQ for nfsv4-archive@lists.ietf.org; Wed, 14 Nov 2007 05:51:48 -0500 Received: from [85.108.251.6] (helo=85.108.251.6) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsFqV-0004Bk-Od for nfsv4-archive@lists.ietf.org; Wed, 14 Nov 2007 05:51:48 -0500 Received: from [85.108.251.6] by rrfuc.bheuu.gov.my; Wed, 14 Nov 2007 10:51:49 +0000 Message-ID: <000801c826ac$04f116d6$856756bc@sbrkkghi> From: "clevey wojtek" To: "Freda Keith" Subject: Sign your name with the finest pens ever made Date: Wed, 14 Nov 2007 09:04:27 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C826AC.04EC9EEC" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C826AC.04EC9EEC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices!=20 http://popullatrave.net/ ------=_NextPart_000_0005_01C826AC.04EC9EEC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices! =

http://popullatrave.net/ ------=_NextPart_000_0005_01C826AC.04EC9EEC-- From yangdave@chartertn.net Wed Nov 14 05:54:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFsy-0004t0-DZ for nfsv4-archive@lists.ietf.org; Wed, 14 Nov 2007 05:54:20 -0500 Received: from [190.65.98.1] (helo=190.65.98.1) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsFsx-0004Ed-SJ for nfsv4-archive@lists.ietf.org; Wed, 14 Nov 2007 05:54:20 -0500 Received: from [190.65.98.1] by bgoa.chartertn.net; Wed, 14 Nov 2007 10:54:15 +0000 Message-ID: <000901c826ac$02829ea4$5f4a8b90@amegx> From: "georges shelia" To: "Lawanda Meyer" Subject: Online venture Date: Wed, 14 Nov 2007 09:06:53 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C826AC.027DF114" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C826AC.027DF114 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices!=20 http://popullatrave.net/ ------=_NextPart_000_0006_01C826AC.027DF114 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices! =

http://popullatrave.net/ ------=_NextPart_000_0006_01C826AC.027DF114-- From StefannaiadMorse@43people.com Wed Nov 14 06:58:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGss-000126-Bt; Wed, 14 Nov 2007 06:58:18 -0500 Received: from [211.225.151.27] (helo=home7d6ba7bda6.private) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsGsr-0006p0-OR; Wed, 14 Nov 2007 06:58:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host06921496.43people.com (8.13.1/8.13.1) with SMTP id x5PKWnDQ72.451990.Lob.oRn.9313728770871 for ; Wed, 14 Nov 2007 20:57:18 -0900 Message-ID: <221b901c826b5$a3063c10$660aa8c0@home7d6ba7bda6> From: "Barney Weeks" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_221B5_01C826B5.A3063C10-- From nfsv4-bounces@ietf.org Wed Nov 14 07:42: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 1IsHZQ-0007As-O8; Wed, 14 Nov 2007 07:42:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsHZO-00078l-KR for nfsv4@ietf.org; Wed, 14 Nov 2007 07:42:14 -0500 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 1IsHZO-0000KV-7i for nfsv4@ietf.org; Wed, 14 Nov 2007 07:42:14 -0500 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 lAECgB5e018415; Wed, 14 Nov 2007 07:42:11 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 14 Nov 2007 07:42:11 -0500 Received: from fs1.bhalevy.com ([172.17.28.115]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Nov 2007 07:42:10 -0500 Message-ID: <473AED21.6070305@panasas.com> Date: Wed, 14 Nov 2007 14:42:09 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: [nfsv4] I-Ds submitted (NFSv4.1 (draft16) and NFSv4.1 dotx (draft00)) References: <113DD442-C18E-471D-8056-A123CC103903@Sun.COM> In-Reply-To: <113DD442-C18E-471D-8056-A123CC103903@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 12:42:11.0237 (UTC) FILETIME=[C693BD50:01C826BB] 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 Spencer, I see that the source files for generating the .x are no longer in http://www.nfsv4-editor.org/draft-16/draft-16.tar.gz Can you make them available please? Benny On Nov. 12, 2007, 9:58 +0200, Spencer Shepler wrote: > You will note that there have been two I-Ds submitted. > The next in the evolution of NFSv4.1 and a new I-D that > represents the dot-x matching the NFSv4.1 draft. > > Mike has set up the dot-x I-D such that it can be self-extracting > for those that want the original XDR description. > > I submitted both of these now such that they would match. > We will do one more submission of the NFSv4.1 I-D prior > to the IETF meeting. > > Note ongoing discussions around the device id mapping management > will result in some amount of change in the dot-x in the > next submission. > > 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 DanialFichtel@schallplattenwelt.de Wed Nov 14 08:05:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsHvS-0000nA-RH for nfsv4-archive@lists.ietf.org; Wed, 14 Nov 2007 08:05:02 -0500 Received: from [189.13.243.86] (helo=18913243086.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsHvS-0001Qe-2Z for nfsv4-archive@lists.ietf.org; Wed, 14 Nov 2007 08:05:02 -0500 Received: from dansyste-dba551 by schallplattenwelt.de with ASMTP id 16AEF2ED for ; Wed, 14 Nov 2007 11:05:29 -0200 Received: from dansyste-dba551 ([100.168.33.44]) by schallplattenwelt.de with ESMTP id CD7407E3EFAD for ; Wed, 14 Nov 2007 11:05:29 -0200 Message-ID: <000601c826be$fa93a180$56f30dbd@dansystedba551> From: "Danial Fichtel" To: Subject: realisen Date: Wed, 14 Nov 2007 11:05:06 -0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C826AE.370AD180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.7 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0008_01C826AE.370AD180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hook into all the hot bitches with a much bigger dick aedf HOLZWARTH http://aipte.com/ ------=_NextPart_000_0008_01C826AE.370AD180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hook into all the hot bitches with a much = bigger dick
aedf HOLZWARTH
http://aipte.com/
------=_NextPart_000_0008_01C826AE.370AD180-- From nfsv4-bounces@ietf.org Wed Nov 14 08:49: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 1IsIcB-0001IV-3n; Wed, 14 Nov 2007 08:49:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIc9-0001I0-CY for nfsv4@ietf.org; Wed, 14 Nov 2007 08:49:09 -0500 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 1IsIc6-0003Xz-RZ for nfsv4@ietf.org; Wed, 14 Nov 2007 08:49:09 -0500 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 lAEDn6E3019721 for ; Wed, 14 Nov 2007 08:49:06 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 14 Nov 2007 08:49:06 -0500 Received: from fs1.bhalevy.com ([172.17.28.115]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Nov 2007 08:49:06 -0500 Message-ID: <473AFCD1.8060708@panasas.com> Date: Wed, 14 Nov 2007 15:49:05 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: NFSv4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2007 13:49:06.0429 (UTC) FILETIME=[1FD16AD0:01C826C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [nfsv4] LAYOUTGET minlength 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 Following a discussion we had in the last Bakeathon I propose the following wording changes: 1. Allow zero minlength. The motivation is to send an opportunistic LAYOUTGET for iomode=open_mode and offset=length=minlength=0 along with OPEN so that the server can return an initial layout starting from offset 0 for which the length doesn't matter, as the client has no bytes to read or write at this point. diff -Npu a/nfsv41_middle_pnfs.xml b/nfsv41_middle_pnfs.xml --- a/nfsv41_middle_pnfs.xml +++ b/nfsv41_middle_pnfs.xml @@ -454,9 +454,8 @@ the requested byte range. A field within the LAYOUTGET request, loga_minlength, specifies the minimum overlap that MUST exist between the requested layout and the layout returned by the metadata - server. The loga_minlength field should be at least one. As needed a - client may make multiple LAYOUTGET requests; these will result in - multiple overlapping, non-conflicting layouts. + server. As needed, a client may make multiple LAYOUTGET requests; + these will result in multiple overlapping, non-conflicting layouts. There is no required ordering between getting a layout and performing 2. clarify how loga_minlength relates to the requested offset There was agreement among the bakeathon participants that the minlength bytes that the client wants should start from the requested offset rather than just any minlength bytes in the requested byte-range. diff -Npu a/nfsv41_middle_op_layoutget.xml b/nfsv41_middle_op_layoutget.xml --- a/nfsv41_middle_op_layoutget.xml +++ b/nfsv41_middle_op_layoutget.xml @@ -69,7 +69,8 @@ the loga_iomode. The client must be prepared to get a layout that does not align exactly with its request. There MUST be at least an overlap of loga_minlength between the layout returned - by the server and the client's request, or the server SHOULD + by the server and the client's request, starting from loga_offset + to loga_offset + loga_minlength, or the server SHOULD reject the request. See for more details. Benny _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 14 09:30: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 1IsJFx-0007cz-MS; Wed, 14 Nov 2007 09:30:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJFw-0007c2-JM for nfsv4@ietf.org; Wed, 14 Nov 2007 09:30:16 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsJFw-00082U-0M for nfsv4@ietf.org; Wed, 14 Nov 2007 09:30:16 -0500 X-IronPort-AV: E=Sophos;i="4.21,417,1188802800"; d="scan'208";a="122336417" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 14 Nov 2007 06:29:49 -0800 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 lAEETmuI003486; Wed, 14 Nov 2007 06:29:48 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 06:29:48 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 06:29:48 -0800 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] LAYOUTGET minlength Date: Wed, 14 Nov 2007 09:29:46 -0500 Message-ID: In-Reply-To: <473AFCD1.8060708@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] LAYOUTGET minlength Thread-Index: AcgmxVDm+sVuSFQGQ9OTfi84wfOPjQAAlUBg From: "Noveck, Dave" To: "Benny Halevy" , "NFSv4" X-OriginalArrivalTime: 14 Nov 2007 14:29:48.0652 (UTC) FILETIME=[CF7F12C0:01C826CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 guess I don't have any objection to allowing this to be zero but I think it is a mistake on the part of client to send this=20 value as zero or anything below around 64K. Although I'm not asking for the spec to say this, my view is that if you send very low values, then you "SHOULD have your=20 head examined." Accessing the data server directly is an optmization and the layout lengths you get should not make it a pessimization. If the layout lengths are so short that it is, you should read and write to the MDS. A value of zero, which suggests that you want any length for communication with the DS, no matter how small, in preference to communication with the MDS, suggests a very different view of the matter. We can't legislate=20 performance characteristics (or at least I'd prefer not to have to draft the requisite legislation), but I would hope that clients not assume the sort of very slow MDS that would justify this strategy and that servers would not drive them to it. "for which the length doesn't matter, as the client has no bytes=20 to read or write at this point." seems to ignore important issues. Despite the fact that no read or write is physically pending, clients will have buffer sizes and other existing performance=20 characteristics that give some idea of where the cross-over=20 point for MDS-vs-DS access is. Given that, I would say that there would be some non-zero length where the client would in effect say "If you can't give me at least N bytes, then don't bother". Saying that one byte is OK whether by sending one or zero as the minlength would seem to call for the aformentioned mental status examination. In the implementations I would be doing, even if the client asked for zero, he would get a considerable length, but he would also get that if he asked for one byte.=20 -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Wednesday, November 14, 2007 8:49 AM To: NFSv4 Subject: [nfsv4] LAYOUTGET minlength Following a discussion we had in the last Bakeathon I propose the following wording changes: 1. Allow zero minlength. The motivation is to send an opportunistic LAYOUTGET for iomode=3Dopen_mode and offset=3Dlength=3Dminlength=3D0 along with OPEN = so that the server can return an initial layout starting from offset 0 for which the length doesn't matter, as the client has no bytes to read or write at this point. diff -Npu a/nfsv41_middle_pnfs.xml b/nfsv41_middle_pnfs.xml --- a/nfsv41_middle_pnfs.xml +++ b/nfsv41_middle_pnfs.xml @@ -454,9 +454,8 @@ the requested byte range. A field within the LAYOUTGET request, loga_minlength, specifies the minimum overlap that MUST exist between the requested layout and the layout returned by the metadata - server. The loga_minlength field should be at least one. As needed a - client may make multiple LAYOUTGET requests; these will result in - multiple overlapping, non-conflicting layouts. + server. As needed, a client may make multiple LAYOUTGET requests; =20 + these will result in multiple overlapping, non-conflicting layouts. There is no required ordering between getting a layout and performing 2. clarify how loga_minlength relates to the requested offset There was agreement among the bakeathon participants that the minlength bytes that the client wants should start from the requested offset rather than just any minlength bytes in the requested byte-range. diff -Npu a/nfsv41_middle_op_layoutget.xml b/nfsv41_middle_op_layoutget.xml --- a/nfsv41_middle_op_layoutget.xml +++ b/nfsv41_middle_op_layoutget.xml @@ -69,7 +69,8 @@ the loga_iomode. The client must be prepared to get a layout that does not align exactly with its request. There MUST be at least an overlap of loga_minlength between the layout returned - by the server and the client's request, or the server SHOULD + by the server and the client's request, starting from loga_offset + to loga_offset + loga_minlength, or the server SHOULD reject the request. See for more details. 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 Wed Nov 14 10:11: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 1IsJtP-0004kC-AZ; Wed, 14 Nov 2007 10:11:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJtN-0004en-Oz for nfsv4@ietf.org; Wed, 14 Nov 2007 10:11:01 -0500 Received: from e6.ny.us.ibm.com ([32.97.182.146]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsJtN-0004C4-4v for nfsv4@ietf.org; Wed, 14 Nov 2007 10:11:01 -0500 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 lAEFCZHQ002384 for ; Wed, 14 Nov 2007 10:12:35 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.6) with ESMTP id lAEFAv2t408724 for ; Wed, 14 Nov 2007 10:10:57 -0500 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 lAEFAv6L004648 for ; Wed, 14 Nov 2007 10:10:57 -0500 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 lAEFAvXA004643; Wed, 14 Nov 2007 10:10:57 -0500 In-Reply-To: To: "Noveck, Dave" MIME-Version: 1.0 Subject: RE: [nfsv4] LAYOUTGET minlength X-Mailer: Lotus Notes Release 7.0 HF144 February 01, 2006 Message-ID: From: Marc Eshel Date: Wed, 14 Nov 2007 07:10:52 -0800 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 8.0|August 02, 2007) at 11/14/2007 10:10:56, Serialize complete at 11/14/2007 10:10:56 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: Benny Halevy , 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 think this a fine idea. It is just a way for the client to tell the server to deiced how much to return. If it is a read for a small file and the server prefers that the client don't use layout it can decline the request for a layout, but I think that in general it is better to use layout for every file so we get load balancing. If you don't use layout for small files and most of the files are small you are going to overload your MDS. Marc. "Noveck, Dave" wrote on 11/14/2007 06:29:46 AM: > I guess I don't have any objection to allowing this to be zero > but I think it is a mistake on the part of client to send this > value as zero or anything below around 64K. > > Although I'm not asking for the spec to say this, my view is > that if you send very low values, then you "SHOULD have your > head examined." > > Accessing the data server directly is an optmization and the > layout lengths you get should not make it a pessimization. > If the layout lengths are so short that it is, you should read > and write to the MDS. A value of zero, which suggests that > you want any length for communication with the DS, no matter > how small, in preference to communication with the MDS, suggests > a very different view of the matter. We can't legislate > performance characteristics (or at least I'd prefer not to have > to draft the requisite legislation), but I would hope that > clients not assume the sort of very slow MDS that would justify > this strategy and that servers would not drive them to it. > > "for which the length doesn't matter, as the client has no bytes > to read or write at this point." seems to ignore important issues. > Despite the fact that no read or write is physically pending, > clients will have buffer sizes and other existing performance > characteristics that give some idea of where the cross-over > point for MDS-vs-DS access is. Given that, I would say that > there would be some non-zero length where the client would in > effect say "If you can't give me at least N bytes, then don't > bother". Saying that one byte is OK whether by sending one or > zero as the minlength would seem to call for the aformentioned > mental status examination. > > In the implementations I would be doing, even if the client asked > for zero, he would get a considerable length, but he would also > get that if he asked for one byte. > > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com] > Sent: Wednesday, November 14, 2007 8:49 AM > To: NFSv4 > Subject: [nfsv4] LAYOUTGET minlength > > Following a discussion we had in the last Bakeathon I propose the > following wording changes: > > 1. Allow zero minlength. > The motivation is to send an opportunistic LAYOUTGET for > iomode=open_mode and offset=length=minlength=0 along with OPEN so that > the server can return an initial layout starting from offset 0 for which > the length doesn't matter, as the client has no bytes to read or write > at this point. > > diff -Npu a/nfsv41_middle_pnfs.xml b/nfsv41_middle_pnfs.xml > --- a/nfsv41_middle_pnfs.xml > +++ b/nfsv41_middle_pnfs.xml > @@ -454,9 +454,8 @@ > the requested byte range. A field within the LAYOUTGET request, > loga_minlength, specifies the minimum overlap that MUST exist > between the requested layout and the layout returned by the metadata > - server. The loga_minlength field should be at least one. As needed a > - client may make multiple LAYOUTGET requests; these will result in > - multiple overlapping, non-conflicting layouts. > + server. As needed, a client may make multiple LAYOUTGET requests; > + these will result in multiple overlapping, non-conflicting layouts. > > > There is no required ordering between getting a layout and performing > > 2. clarify how loga_minlength relates to the requested offset There was > agreement among the bakeathon participants that the minlength bytes that > the client wants should start from the requested offset rather than just > any minlength bytes in the requested byte-range. > > diff -Npu a/nfsv41_middle_op_layoutget.xml > b/nfsv41_middle_op_layoutget.xml > --- a/nfsv41_middle_op_layoutget.xml > +++ b/nfsv41_middle_op_layoutget.xml > @@ -69,7 +69,8 @@ > the loga_iomode. The client must be prepared to get a layout > that does not align exactly with its request. There MUST be at > least an overlap of loga_minlength between the layout returned > - by the server and the client's request, or the server SHOULD > + by the server and the client's request, starting from loga_offset > + to loga_offset + loga_minlength, or the server SHOULD > reject the request. See for > more details. > > > 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 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 14 11:04: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 1IsKj2-0002VJ-Px; Wed, 14 Nov 2007 11:04:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKj1-0002SB-Dx for nfsv4@ietf.org; Wed, 14 Nov 2007 11:04:23 -0500 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsKj0-0002Un-Sr for nfsv4@ietf.org; Wed, 14 Nov 2007 11:04:23 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAEG4Mme016776 for ; Wed, 14 Nov 2007 16:04:22 GMT Received: from leviathan.central.sun.com (leviathan.Central.Sun.COM [129.153.128.98]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAEG4LfK057030 for ; Wed, 14 Nov 2007 09:04:21 -0700 (MST) Received: from leviathan.central.sun.com (localhost [127.0.0.1]) by leviathan.central.sun.com (8.14.0+Sun/8.14.0) with ESMTP id lAEG4LUw023012; Wed, 14 Nov 2007 10:04:21 -0600 (CST) Received: (from rmesta@localhost) by leviathan.central.sun.com (8.14.0+Sun/8.14.0/Submit) id lAEG4KV2023011; Wed, 14 Nov 2007 10:04:20 -0600 (CST) X-Authentication-Warning: leviathan.central.sun.com: rmesta set sender to Ricardo.Mesta@Sun.COM using -f Date: Wed, 14 Nov 2007 10:04:20 -0600 From: Rick Mesta To: Mahesh Siddheshwar , Dave Noveck Subject: Re: [nfsv4] DESTROY_SESSION Errors (contd) Message-ID: <20071114160420.GA22967@leviathan.central.sun.com> References: <473A375B.10905@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <473A375B.10905@sun.com> User-Agent: Mutt/1.5.10i X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Mike Eisler , Rick Mesta , nfsv4@ietf.org X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rick Mesta List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org On Tue, Nov 13, 2007 at 03:46:35PM -0800, Siddheshwar Mahesh wrote: | Noveck, Dave wrote: | >> Q1) What server behavior is expected if the COMPOUND does | >> _indeed_ start w/SEQUENCE but the sessionid specified | >> in SEQUENCE does NOT match the sessionid specified in | >> the DESTROY_SESSION's arguments ? NFS4ERR_BADSESSION ? | >> | > | >No. That's the desirable situation. You are using one session | >as a transport mechanism to send an op which destroys another. | > | >No problem with that. | > | > | I guess you are implicitly suggesting in the above sentence that the two | sessions | should be using a transport connection associated with both the | sessions, correct? | | Since DESTROY_SESSION MUST be invoked on a connection associated | with the session, if it is not, I guess a valid error that is missing | and should | be added is -- NFS4ERR_CONN_NOT_BOUND_TO_SESSION. | | So either SEQUENCE or DESTROY_SESSION will error out with | NFS4ERR_CONN_NOT_BOUND_TO_SESSION, in such cases. | | Mahesh Hi Mahesh, I was thinking about Dave's answer when I logged off for the evening. It seems to me that we have either... a) (as you note) an implicit (though subtle) hint that both sessions share the same connection in cases such as... [ SEQ sessid-a, DESTROY_SESSION sessid-b ] <<< OR >>> b) there is a contradiction in the spec's text, since (again, as you note) the inbound DESTROY_SESSION op MUST be bound to the session being destroyed. If it's a) above, I'd suggest clearer text to make sure we differentiate between a clientid with two sessions (as in case a) above) and the clientid with only a single session (in which case I would assume a singleton COMPOUND with only DESTROY_SESSION suffices ? | >> Q2) What server behavior is expected if the DESTROY_SESSION | >> is NOT the final OP in the COMPOUND, whether prefixed by | >> SEQUENCE or not ? What error should be returned ? Same | >> error for both scenarios ? | >> | > | >If it is not prefixed with SEQUENCE, than the error is NOT_ONLY_OP. I don't see such error in draft-16, so I'm assuming it'll be something like NFS4ERR_NOT_ONLY_OP ? | >> I simply couldn't discern a sensible answer from the current | >> text in the spec. Are these scenarios covered in an upcoming | >> draft update ? If not, your guidance is highly valued. | >> | > | > | >The discussions I've heard are that DESTROY_SESSION does not have | >to be the last thing, but the session destroyed has to be different | >than the one that that the reqquest is issued on. I believe INVAL | >is the error if it is not. | > | >My understanding was that that would be in an upcoming draft. Ack... thx for the quick response, Dave. rick _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 14 11:08:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKmh-0007rZ-MF; Wed, 14 Nov 2007 11:08:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKmf-0007oU-Re for nfsv4@ietf.org; Wed, 14 Nov 2007 11:08:09 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsKme-00030T-U0 for nfsv4@ietf.org; Wed, 14 Nov 2007 11:08:09 -0500 X-IronPort-AV: E=Sophos;i="4.21,417,1188802800"; d="scan'208";a="122364909" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 14 Nov 2007 08:07:37 -0800 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 lAEG7YvK029144; Wed, 14 Nov 2007 08:07:36 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 08:07:34 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 08:07:34 -0800 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] LAYOUTGET minlength Date: Wed, 14 Nov 2007 11:07:31 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] LAYOUTGET minlength Thread-Index: Acgm0JqeUz2LGRNpRtCwI14XV9gQTAAArNig From: "Noveck, Dave" To: "Marc Eshel" X-OriginalArrivalTime: 14 Nov 2007 16:07:34.0259 (UTC) FILETIME=[77ABAC30:01C826D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Benny Halevy , 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 > It is just a way for the client to tell the server to deiced how=20 > much to return.=20 Exactly. It's saying whatever the server decides is OK with you. I'd prefer not to do that. > server prefers that the client don't use layout it can decline=20 > the request for a layout Doesn't the client have any preferences here? > If you don't use layout for small files and most of the files=20 > are small you are going to overload your MDS. I think you need to distinguish small files and small layouts. If=20 a file is 50 bytes and I get a 64K layout, then I'm cool sending a 50-byte READ to the DS. If the file is 64K and I get a 50 byte=20 layout, the DS is not going to be my choice. If the file and=20 the layout are both 50 bytes, I'm not sure. I'd probably decide to use a different server. -----Original Message----- From: Marc Eshel [mailto:eshel@almaden.ibm.com]=20 Sent: Wednesday, November 14, 2007 10:11 AM To: Noveck, Dave Cc: Benny Halevy; NFSv4 Subject: RE: [nfsv4] LAYOUTGET minlength I think this a fine idea. It is just a way for the client to tell the server to deiced how much to return. If it is a read for a small file and the server prefers that the client don't use layout it can decline the request for a layout, but I think that in general it is better to use layout for every file so we get load balancing. If you don't use layout for small files and most of the files are small you are going to overload your MDS. Marc. "Noveck, Dave" wrote on 11/14/2007 06:29:46 AM: > I guess I don't have any objection to allowing this to be zero but I=20 > think it is a mistake on the part of client to send this value as zero > or anything below around 64K. >=20 > Although I'm not asking for the spec to say this, my view is that if=20 > you send very low values, then you "SHOULD have your head examined." >=20 > Accessing the data server directly is an optmization and the layout=20 > lengths you get should not make it a pessimization. > If the layout lengths are so short that it is, you should read and=20 > write to the MDS. A value of zero, which suggests that you want any=20 > length for communication with the DS, no matter how small, in=20 > preference to communication with the MDS, suggests a very different=20 > view of the matter. We can't legislate performance characteristics=20 > (or at least I'd prefer not to have to draft the requisite=20 > legislation), but I would hope that clients not assume the sort of=20 > very slow MDS that would justify this strategy and that servers would=20 > not drive them to it. >=20 > "for which the length doesn't matter, as the client has no bytes to=20 > read or write at this point." seems to ignore important issues. > Despite the fact that no read or write is physically pending, clients=20 > will have buffer sizes and other existing performance characteristics=20 > that give some idea of where the cross-over point for MDS-vs-DS access > is. Given that, I would say that there would be some non-zero length=20 > where the client would in effect say "If you can't give me at least N=20 > bytes, then don't bother". Saying that one byte is OK whether by=20 > sending one or zero as the minlength would seem to call for the=20 > aformentioned mental status examination. >=20 > In the implementations I would be doing, even if the client asked for=20 > zero, he would get a considerable length, but he would also get that=20 > if he asked for one byte. >=20 > -----Original Message----- > From: Benny Halevy [mailto:bhalevy@panasas.com] > Sent: Wednesday, November 14, 2007 8:49 AM > To: NFSv4 > Subject: [nfsv4] LAYOUTGET minlength >=20 > Following a discussion we had in the last Bakeathon I propose the=20 > following wording changes: >=20 > 1. Allow zero minlength. > The motivation is to send an opportunistic LAYOUTGET for=20 > iomode=3Dopen_mode and offset=3Dlength=3Dminlength=3D0 along with OPEN = so that > the server can return an initial layout starting from offset 0 for=20 > which the length doesn't matter, as the client has no bytes to read or > write at this point. >=20 > diff -Npu a/nfsv41_middle_pnfs.xml b/nfsv41_middle_pnfs.xml > --- a/nfsv41_middle_pnfs.xml > +++ b/nfsv41_middle_pnfs.xml > @@ -454,9 +454,8 @@ > the requested byte range. A field within the LAYOUTGET request, > loga_minlength, specifies the minimum overlap that MUST exist > between the requested layout and the layout returned by the=20 > metadata > - server. The loga_minlength field should be at least one. As needed > a > - client may make multiple LAYOUTGET requests; these will result in > - multiple overlapping, non-conflicting layouts. > + server. As needed, a client may make multiple LAYOUTGET requests;=20 > + these will result in multiple overlapping, non-conflicting layouts. > > > There is no required ordering between getting a layout and=20 > performing >=20 > 2. clarify how loga_minlength relates to the requested offset There=20 > was agreement among the bakeathon participants that the minlength=20 > bytes that the client wants should start from the requested offset=20 > rather than just any minlength bytes in the requested byte-range. >=20 > diff -Npu a/nfsv41_middle_op_layoutget.xml=20 > b/nfsv41_middle_op_layoutget.xml > --- a/nfsv41_middle_op_layoutget.xml > +++ b/nfsv41_middle_op_layoutget.xml > @@ -69,7 +69,8 @@ > the loga_iomode. The client must be prepared to get a layout > that does not align exactly with its request. There MUST be at > least an overlap of loga_minlength between the layout returned > - by the server and the client's request, or the server SHOULD > + by the server and the client's request, starting from loga_offset > + to loga_offset + loga_minlength, or the server SHOULD > reject the request. See = for > more details. > >=20 > Benny >=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 LuztradeoffQuintana@supremecourthistory.org Wed Nov 14 12:18:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLss-0004LP-Qm; Wed, 14 Nov 2007 12:18:38 -0500 Received: from dslb-084-063-102-087.pools.arcor-ip.net ([84.63.102.87] helo=artist) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsLsq-0003CS-Ps; Wed, 14 Nov 2007 12:18:38 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host03529978.supremecourthistory.org (8.13.1/8.13.1) with SMTP id Vq6M8GjL68.633841.qAG.K6G.2843054427744 for ; Wed, 14 Nov 2007 18:17:57 -0100 Message-ID: <213a401c826e2$5f9bce90$6402a8c0@artist> From: "Olivia Huggins" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_213A0_01C826E2.5F9BCE90-- From nfsv4-bounces@ietf.org Wed Nov 14 12:21: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 1IsLvF-0000E4-RS; Wed, 14 Nov 2007 12:21:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLvE-0000Cq-Kb for nfsv4@ietf.org; Wed, 14 Nov 2007 12:21:04 -0500 Received: from nz-out-0506.google.com ([64.233.162.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsLvB-0001qg-AG for nfsv4@ietf.org; Wed, 14 Nov 2007 12:21:04 -0500 Received: by nz-out-0506.google.com with SMTP id n1so221877nzf for ; Wed, 14 Nov 2007 09:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=kiITo+HSu88JPeUs03nqUgqWm7TvRrWhn3JOhV/ZzIY=; b=K5TnHc+xrzTPMFM7A1V8Yz+2JYZewGq1KaBB1aDq0+cj0RBKrf8SZK2ynb8Awbeh9DPkqsb3rl788QKVzAGGaU0EuXs44mvnIDodQ8y9ZymPivDdsfn9uHVAVytWJskmxLVuEBlEJNvb81b0OwK0QCcH4baZ6kmnWx843NNLFCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=D8sFELAezLupp5VSws0FLs63osg2jK/gOafxNTW+eDnG0OY1yKN+Bw7sWU02td0UPDG0fsIuuaM05dXNbuWgPOg5XkhcpE4QmFiYUlLQxeIWs5U6WyeBJWLr5sTJh0C0+kB9sdPFS6X15kTnKZnYMM8UMW7fVU8/nPaAP1afmng= Received: by 10.142.242.8 with SMTP id p8mr1259683wfh.1195060860141; Wed, 14 Nov 2007 09:21:00 -0800 (PST) Received: by 10.142.98.1 with HTTP; Wed, 14 Nov 2007 09:21:00 -0800 (PST) Message-ID: <89c397150711140921p72368255s7c9076be9fa4aae5@mail.gmail.com> Date: Wed, 14 Nov 2007 12:21:00 -0500 From: "William A. (Andy) Adamson" To: NFSv4 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 404a749ce2177974 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [nfsv4] draft-ietf-nfsv4-minorversion1-16 LAYOUTRETURN question 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 if I missed the discussion on this point. The last paragraph of section 18.44.3 (LAYOUTRETURN) draft-ietf-nfsv4-minorversion1-16.txt: The server MAY require that the principal, security flavor, and applicable, the GSS mechanism, combination that acquired the layout also be the one to issue LAYOUTRETURN. his might not be possible if credentials for the principal are no longer available. The server MAY allow the machine credential or SSV credential (see Section 18.35) to issue DELEGRETURN. Why is it allowed for a client-wide layout to be attached to a user? This paragraph suggests that the layout is somehow attached to user credentials. The layout, and therefore the layoutreturn, is of client scope and so any user credentials should be acceptable to any pnfs server. Also. Why is it that the pNFS server is not required to allow machine credentials?!?!? -->Andy _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 14 12:33: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 1IsM7M-0006ha-WA; Wed, 14 Nov 2007 12:33:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsM7K-0006gH-A5 for nfsv4@ietf.org; Wed, 14 Nov 2007 12:33:34 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsM7J-0004et-Rj for nfsv4@ietf.org; Wed, 14 Nov 2007 12:33:34 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAEHXWLV012421 for ; Wed, 14 Nov 2007 17:33:32 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRI008019KNE100@mail-amer.sun.com> (original mail from Robert.Gordon@Sun.COM) for nfsv4@ietf.org; Wed, 14 Nov 2007 10:33:32 -0700 (MST) Received: from jeeves.macrbg.com ([72.179.36.242]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRI002SZBFJWZA0@mail-amer.sun.com> for nfsv4@ietf.org; Wed, 14 Nov 2007 10:33:19 -0700 (MST) Date: Wed, 14 Nov 2007 11:33:19 -0600 From: Robert Gordon Subject: Re: [nfsv4] DESTROY_SESSION Errors (contd) In-reply-to: <20071114160420.GA22967@leviathan.central.sun.com> To: Rick Mesta Message-id: <55CC19B5-4D93-456E-BEFD-93936E15E6D0@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.912) Content-type: text/plain; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT References: <473A375B.10905@sun.com> <20071114160420.GA22967@leviathan.central.sun.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Nov 14, 2007, at 10:04 AM, Rick Mesta wrote: > > I don't see such error in draft-16, so I'm assuming it'll be > something like NFS4ERR_NOT_ONLY_OP ? > Indeed. Robert. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 14 14:08:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsNbL-00072r-Jc; Wed, 14 Nov 2007 14:08:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsNbK-00070G-ES for nfsv4@ietf.org; Wed, 14 Nov 2007 14:08:38 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsNbH-0004iP-8p for nfsv4@ietf.org; Wed, 14 Nov 2007 14:08:38 -0500 Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAEJ8YFk029603; Wed, 14 Nov 2007 14:08:35 -0500 (EST) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Wed, 14 Nov 2007 14:08:34 -0500 Received: from corpussmtp2.corp.emc.com (corpussmtp2.corp.emc.com [128.221.14.146]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAEJ8T0S028880; Wed, 14 Nov 2007 14:08:31 -0500 (EST) From: Glasgow_Jason@emc.com Received: from CORPUSMX40A.corp.emc.com ([10.254.64.44]) by corpussmtp2.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 14:07:55 -0500 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: Wed, 14 Nov 2007 14:07:54 -0500 Message-ID: <39CF2A4B63947142A66EAA65B2FDF2F005E0CB2D@CORPUSMX40A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LAYOUTGET in draft-16 spec. thread-index: AcggP00NZPN49awaQ8W7Wt5GoapSSwGq9Iig To: , X-OriginalArrivalTime: 14 Nov 2007 19:07:55.0933 (UTC) FILETIME=[A9E414D0:01C826F1] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=1%, Reason='EMC_FROM_0+ -3, NO_REAL_NAME 0, __CP_NOT_1 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-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: -4.0 (----) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Subject: [nfsv4] LAYOUTGET in draft-16 spec. 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 changes in draft-16 for GETDEVICEINFO and GETDEVICELIST look great. My fault for not noticing earlier, but a similar treatment applies to LAYOUTGET in section 18.41.3. If it is not too late, union LAYOUTGET4res switch (nfsstat4 logr_status) {=09 case NFS4_OK:=09 LAYOUTGET4resok logr_resok4; case NFS4ERR_LAYOUTTRYLATER: bool logr_will_signal_layout_avail; default: default:=09 void; void;=09 }; should be union LAYOUTGET4res switch (nfsstat4 logr_status) {=09 case NFS4_OK:=09 LAYOUTGET4resok logr_resok4; case NFS4ERR_LAYOUTTRYLATER: bool logr_will_signal_layout_avail; case NFS4ERR_TOOSMALL: count4 logr_mincount; default: default:=09 void; void;=09 }; " The loga_maxcount field specifies the maximum layout size (in bytes) that the client can handle. If the size of the layout structure=09 exceeds the size specified by maxcount, the metadata server will return the NFS4ERR_TOOSMALL error." should be " The client provides loga_maxcount to limit the number of bytes for the result. This maximum size represents all of the data being returned within the LAYOUTGETresok structure and includes the XDR overhead. The server may return less data. If the server is unable to return the data within the loga_maxcount=20 limit, the error NFS4ERR_TOOSMALL will be returned." And a new paragraph should be added, "If NFS4ERR_TOOSMALL is returned, the results also contain=09 logr_mincount. The value of logr_mincount represents the minimum size necessary to obtain the layout." -Jason -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Tuesday, November 06, 2007 12:54 AM To: NFSv4 Subject: Re: [nfsv4] GETDEVICEINFO and GETDEVICELIST in the draft-15 spec On Nov 1, 2007, at 2:09 PM, Glasgow_Jason@emc.com wrote: > I have two minor issues with the draft-15 spec related to =20 > GETDEVICEINFO and GETDEVICELIST. The spec does not adequately =20 > specify the meaning of gdia_maxcount. The sentence describing its =20 > usage states: > > > > "The client provides gdia_maxcount to limit the amount of device =20 > address information to be returned for the mapping. If the mapping =20 > can not be returned within the maximum specified, NFS4ERR_TOOSMALL =20 > is returned." > > > > This sentence does not make clear if gdia_maxount limits the number =20 > of bytes in the GETDEVICEINFO4res data structure, within the =20 > "device_addr4" structure, or within the protocol specific opaque =20 > data "da_addr_body". I propose that the wording be changed to =20 > clarify that this refers to the number of bytes in the =20 > "device_addr4" portion of the response. I agree that the use of gdia_maxcount is underspecified. However, I would prefer the the "maxcount" be interpreted as it is for the READDIR operation. Quoting from that operation description: "The maxcount value of the argument is the maximum number of bytes =20 for the result. This maximum size represents all of the data being returned within the READDIR4resok structure and includes the XDR overhead. The server may return less data. If the server is unable to return a single directory entry within the maxcount limit, the error NFS4ERR_TOOSMALL will be returned to the client." Therefore, I would suggest the text for GETDEVICEINFO be: "The client provides gdia_maxcount to limit the number of bytes for the result. This maximum size represents all of the data being returned within the GETDEVICEINFO4resok structure and includes the XDR overhead. The server may return less data. If the server is unable to return the information within the gdia_maxcount limit, the error NFS4ERR_TOOSMALL will be returned." And for GETDEVICELIST: "The client provides gdla_maxcount to limit the number of bytes for the result. This maximum size represents all of the data being returned within the GETDEVICELIST4resok structure and includes the XDR overhead. The server may return less data. If the server is unable to return a single entry device list item within the gdla_maxcount limit, the error NFS4ERR_TOOSMALL will be returned." The remaining suggestions of adding NFS4ERR_TOOSMALL to the return union is fine with me. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 14 14:13: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 1IsNgN-0000ML-Rh; Wed, 14 Nov 2007 14:13:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsNgK-0000LE-36 for nfsv4@ietf.org; Wed, 14 Nov 2007 14:13:48 -0500 Received: from p01c11o145.mxlogic.net ([208.65.144.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsNgJ-0007UC-BZ for nfsv4@ietf.org; Wed, 14 Nov 2007 14:13:48 -0500 Received: from unknown [63.110.244.103] (EHLO p01c11o145.mxlogic.net) by p01c11o145.mxlogic.net (mxl_mta-5.2.0-1) with ESMTP id be84b374.2273270704.177656.00-502.p01c11o145.mxlogic.net (envelope-from ); Wed, 14 Nov 2007 12:13:47 -0700 (MST) Received: from unknown [63.110.244.103] (EHLO us-email.terastack.bluearc.com) by p01c11o145.mxlogic.net (mxl_mta-5.2.0-1) with ESMTP id 6e84b374.1696328624.177625.00-037.p01c11o145.mxlogic.net (envelope-from ); Wed, 14 Nov 2007 12:13:42 -0700 (MST) 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] File Layout Questions (Layouts of the same file and Packing) Date: Wed, 14 Nov 2007 11:13:40 -0800 Message-ID: In-Reply-To: <951044.58789.qm@web38109.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] File Layout Questions (Layouts of the same file and Packing) Thread-Index: AcgmeOiTvMJv1lzpSG+u4z+kUOaqOAAeLSdg References: <951044.58789.qm@web38109.mail.mud.yahoo.com> From: "Anatoly Pinchuk" To: , X-Spam: [F=0.2696173227; S=0.269(2007110801)] X-MAIL-FROM: X-SOURCE-IP: [63.110.244.103] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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 Actually, in the example there are two striping patterns (dev0 and dev1) but returned layout (lo) does not cross the device boundaries. It is solely=20 based on the device dev1 and, therefore, does not overlap. Having array of layout4 as return result is not going to help to resolve the issue since in the example just one layout corresponds to the client provided offset (0x800) and length (0x400). -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Tuesday, November 13, 2007 8:44 PM To: Anatoly Pinchuk; email2mre-ietf@yahoo.com; nfsv4@ietf.org Subject: RE: [nfsv4] File Layout Questions (Layouts of the same file and Packing) You example seems to request a layout for a range that overlaps two striping patterns, and it returns a layout that overlaps, which I think is a server defect. To resolve a related another issue,=20 draft 16 now has LAYOUTGET return an array of layout4 data types: layout4 logr_layout<>; Does that resolve the issue? At least it allows the server to do something saner. --- Anatoly Pinchuk wrote: > 1. If the client file layouts can have different stripe unit sizes we > need more than just a text clarification. In that case the layout > structure should include additional information to calculate a data > file offset for dense packing. Offset returned in layout4 structure > and stripe unit size is not enough to do the calculation. Here is an > example: > =20 > There are devices: > struct nfsv4_1_file_layout_ds_addr4 > dev0 =3D { // ID is 0 > {0}, > {{A}} > }, > dev1 =3D { // ID is 1 > {0}, > {{B}} > }; > =20 > File Layouts for a client file > struct nfsv4_1_file_layout4 > fl0 =3D { > 0, > x, // stripe unit size of 0x400 is coded with x > 0, > fh0 > }, > fl1 =3D { > 1, > y, // stripe unit size of 0x1000 and dense packing are coded with > y > 0, > fh1 > }; > =20 > fl0 and fl1 correspond to file ranges [0, 0x400-1] and [0x400, > 0x1400-1]; > =20 > Now a client requests layout for an offset of 0x800 and length 0x400 > and the reply is: > =20 > struct layout4 > lo =3D { > 0x800, > 0x400, > lo_iomode, // some IO mode > lo_content // see below > }; > =20 > struct layout_content4 > lo_content =3D { > LAYOUT4_NFSV4_1_FILES, > loc_body // see below > }; > loc_body contains fl1 defined above. > =20 > So, the client knows the server (B) and the file handle (fh1) to do > IO on. Offset for the fh1 is needed as well. The formula from > paragraph 14.5 does not provide correct offset since > =20 > data_file_offset =3D floor(file_offset / stripe_width) > * stripe_unit_size + file_offset % stripe_unit_size =3D > floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 =3D 0x800; > =20 > and the correct offset is >=20 > rel_off =3D (file_offset - layout_offset) =3D (0x800 - 0x400) =3D = 0x400;=20 > data_file_offset =3D floor(rel_offset / stripe_width) > * stripe_unit_size + rel_offset % stripe_unit_size =3D > floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 =3D 0x400; > =20 > Offset of first byte the layout is applicable to (layout_offset =3D > 0x400) is used in the calculation of the data file offset. Therefore, > it should be stored in the nfsv4_1_file_layout4 structure returned to > the client. >=20 > 2. Packing can be kept in the layout, but doing so limits number of > ways the layouts can be created. Pathological example would be having > just two data servers A and B with dense and sparse packing > implemented respectively. Then no layout can correspond to both A and > B data file servers. In such configuration a multi-path can not be > created and client file data access parallelism can not be achieved > at all. A remedy could be storing the packing per data server. As for > the stripe unit size, since it describes the data distribution, it > probably should follow stripe indices and be stored in a device > structure. In general, packing and stripe unit size rather belong to > the device than layout. >=20 >=20 >=20 > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 > Sent: Thursday, November 01, 2007 6:50 PM > To: Anatoly Pinchuk; nfsv4@ietf.org > Subject: Re: [nfsv4] File Layout Questions (Layouts of the same file > and Packing) >=20 > =20 > > 1. Layouts of the same client file > >=20 > > There seems to be an agreement that more than one layout is > possible > > corresponding to a given client file. If so, it would be great to > > describe if there are dependencies between the layouts of the same > > file. > > One interesting question is if the stripe unit size can be > different > > in > > such layouts. >=20 > The spec doesn't disallow this. If you want to suggest some > test to make this clear, that would be welcome. >=20 >=20 > > 2. Sparse or dense packing > >=20 > > Currently packing is stored in a layout which makes it impossible > to > > bring two data servers with different packing implementations under > > the > > same layout. Also, it is unlikely that a data server implements > both > > sparse and dense packing. Would it be more flexible then to have > > packing > > defined per equivalent data server group or even per data server? >=20 > I thought the packing and stripe unit size should be in the device > address, and asked this question of WG several on June 12, 2007. > The consensus was to define it in the layout. So that's where > we are. >=20 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 14 14:27: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 1IsNt9-0005YS-KR; Wed, 14 Nov 2007 14:27:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsNt8-0005Y5-0J for nfsv4@ietf.org; Wed, 14 Nov 2007 14:27:02 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsNt7-0000so-Dp for nfsv4@ietf.org; Wed, 14 Nov 2007 14:27:01 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAEJR01x028999 for ; Wed, 14 Nov 2007 19:27:00 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRI00901F27MY00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 14 Nov 2007 12:27:00 -0700 (MST) Received: from [192.168.0.4] ([129.150.33.14]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRI007DFGONVAC0@mail-amer.sun.com>; Wed, 14 Nov 2007 12:26:48 -0700 (MST) Date: Wed, 14 Nov 2007 13:27:31 -0600 From: Spencer Shepler Subject: Re: [nfsv4] I-Ds submitted (NFSv4.1 (draft16) and NFSv4.1 dotx (draft00)) In-reply-to: <473AED21.6070305@panasas.com> To: Benny Halevy Message-id: <880506A3-5523-4BF1-A1BA-2AE40C280B7F@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: <113DD442-C18E-471D-8056-A123CC103903@Sun.COM> <473AED21.6070305@panasas.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Nov 14, 2007, at 6:42 AM, Benny Halevy wrote: > Spencer, I see that the source files for generating the .x > are no longer in http://www.nfsv4-editor.org/draft-16/draft-16.tar.gz > Can you make them available please? ? I downloaded from the link, extracted and did "make". It built both drafts: draft-ietf-nfsv4-minorversion1-16.txt -and- draft-ietf-nfsv4-minorversion1-dot-x-00.txt and the dotx file is also present (nfsv41.x). Everything is there. Spencer > > Benny > > On Nov. 12, 2007, 9:58 +0200, Spencer Shepler > wrote: >> You will note that there have been two I-Ds submitted. >> The next in the evolution of NFSv4.1 and a new I-D that >> represents the dot-x matching the NFSv4.1 draft. >> >> Mike has set up the dot-x I-D such that it can be self-extracting >> for those that want the original XDR description. >> >> I submitted both of these now such that they would match. >> We will do one more submission of the NFSv4.1 I-D prior >> to the IETF meeting. >> >> Note ongoing discussions around the device id mapping management >> will result in some amount of change in the dot-x in the >> next submission. >> >> 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 Wed Nov 14 14:31:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsNxV-0002lz-17; Wed, 14 Nov 2007 14:31:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsNxS-0002gE-Ga for nfsv4@ietf.org; Wed, 14 Nov 2007 14:31:31 -0500 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 1IsNxS-0001Yo-4w for nfsv4@ietf.org; Wed, 14 Nov 2007 14:31:30 -0500 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 lAEJVTho028555; Wed, 14 Nov 2007 14:31:29 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 14 Nov 2007 14:31:29 -0500 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] I-Ds submitted (NFSv4.1 (draft16) and NFSv4.1 dotx (draft00)) Date: Wed, 14 Nov 2007 14:31:25 -0500 Message-ID: In-Reply-To: <880506A3-5523-4BF1-A1BA-2AE40C280B7F@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] I-Ds submitted (NFSv4.1 (draft16) and NFSv4.1 dotx (draft00)) Thread-Index: Acgm9IDQaL5TrxZaT1GxXi0GHDbNCgAAGcuw From: "Halevy, Benny" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Hmm, you're right. It's probably a pilot error on my side. Benny=20 -----Original Message----- From: Spencer.Shepler@Sun.COM [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Wednesday, November 14, 2007 9:28 PM To: Halevy, Benny Cc: NFSv4 Subject: Re: [nfsv4] I-Ds submitted (NFSv4.1 (draft16) and NFSv4.1 dotx (draft00)) On Nov 14, 2007, at 6:42 AM, Benny Halevy wrote: > Spencer, I see that the source files for generating the .x are no=20 > longer in http://www.nfsv4-editor.org/draft-16/draft-16.tar.gz > Can you make them available please? ? I downloaded from the link, extracted and did "make". It built both drafts: draft-ietf-nfsv4-minorversion1-16.txt -and- draft-ietf-nfsv4-minorversion1-dot-x-00.txt and the dotx file is also present (nfsv41.x). Everything is there. Spencer > > Benny > > On Nov. 12, 2007, 9:58 +0200, Spencer Shepler=20 > wrote: >> You will note that there have been two I-Ds submitted. >> The next in the evolution of NFSv4.1 and a new I-D that represents=20 >> the dot-x matching the NFSv4.1 draft. >> >> Mike has set up the dot-x I-D such that it can be self-extracting for >> those that want the original XDR description. >> >> I submitted both of these now such that they would match. >> We will do one more submission of the NFSv4.1 I-D prior to the IETF=20 >> meeting. >> >> Note ongoing discussions around the device id mapping management will >> result in some amount of change in the dot-x in the next submission. >> >> 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 IlawilloughbyBurnette@metacritic.com Wed Nov 14 15:29:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsOrN-0006Fs-VO; Wed, 14 Nov 2007 15:29:19 -0500 Received: from [121.175.185.65] (helo=admin.kornet) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsOrN-0000aa-IA; Wed, 14 Nov 2007 15:29:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host56024947.metacritic.com (8.13.1/8.13.1) with SMTP id OgjN3Z7G43.234895.Ui3.Pbw.3123373300134 for ; Thu, 15 Nov 2007 05:28:45 -0900 Message-ID: <166f701c826fd$064892e0$41b9af79@admin> From: "Rosalyn Swenson" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_166F3_01C826FD.064892E0-- From JonathonabroadStrickland@slashdot.org Wed Nov 14 20:50:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsTrp-0000Uv-77; Wed, 14 Nov 2007 20:50:05 -0500 Received: from pool-71-124-58-209.chi01.dsl-w.verizon.net ([71.124.58.209] helo=harthome.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsTrn-00043D-Hb; Wed, 14 Nov 2007 20:50:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host42122280.slashdot.org (8.13.1/8.13.1) with SMTP id NNUflkNq39.485926.CHl.1fE.8364470752092 for ; Wed, 14 Nov 2007 20:49:40 +0500 Message-ID: <1a8501c82729$d8264bf0$6701a8c0@harthome> From: "Pete Strickland" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1A81_01C82729.D8264BF0-- From nfsv4-bounces@ietf.org Wed Nov 14 21:26:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsUQh-0001Oq-Ex; Wed, 14 Nov 2007 21:26:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsUQf-0001NG-OJ for nfsv4@ietf.org; Wed, 14 Nov 2007 21:26:05 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsUQc-0000yn-Al for nfsv4@ietf.org; Wed, 14 Nov 2007 21:26:05 -0500 X-IronPort-AV: E=Sophos;i="4.21,418,1188802800"; d="scan'208";a="122531520" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 14 Nov 2007 18:25:31 -0800 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 lAF2PMrI025353 for ; Wed, 14 Nov 2007 18:25:30 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 12:55:29 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 12:55:29 -0800 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: Wed, 14 Nov 2007 15:55:28 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue in LAYOUTRETURN Thread-Index: AcgnAK+lIy9NMVjxTYyyjUHSdtl+vg== From: "Noveck, Dave" To: X-OriginalArrivalTime: 14 Nov 2007 20:55:29.0122 (UTC) FILETIME=[B04A9420:01C82700] X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [nfsv4] Issue in LAYOUTRETURN 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 editing this to deal with another issue, I noted the following: The server MAY require that the principal, security flavor, and applicable, the GSS mechanism, combination that acquired the layout also be the one to issue LAYOUTRETURN. This might not be possible if credentials for the principal are no longer available. The server MAY allow the machine credential or SSV credential (see ) to issue DELEGRETURN. If the client does the former without doing the latter, it is=20 going to have a heck of a time doing LAYOUTRETURN_FSID or LAYOUTRETURN_ALL. Do we want to say something about this. Depending on your interpretation of: However, if it is a subset, the recall is not complete until the full recalled scope has been returned. Recalled scope refers to the byte range in the case of LAYOUTRETURN4_FILE, use of LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. it may not be possible to respond to LAYOUTRECALL of ALL, if the requirement is that the client actually do a completing=20 LAYOUTRETURN4_ALL, rather than simply returning each and=20 every layout he holds. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 14 22:36:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsVWk-0006D3-Sz; Wed, 14 Nov 2007 22:36:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsVWh-00069X-P1 for nfsv4@ietf.org; Wed, 14 Nov 2007 22:36:25 -0500 Received: from web38112.mail.mud.yahoo.com ([209.191.124.139]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IsVWf-0002dP-Af for nfsv4@ietf.org; Wed, 14 Nov 2007 22:36:23 -0500 Received: (qmail 73676 invoked by uid 60001); 15 Nov 2007 03:36:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Yfph3SFsewivUqN1e+gpprwrzKebR6YvsD/VJD4pFFwLNiE5hqhjI8LPvTdThrlSxtk9aJ/I1Y88xKAwgmXFAob8fZnYp7wm9U2a0kgpYZcXollUaMHrj3UNWHhTpXZ0p5Kk5usuJnmweBr+8nHCKjwPHaFYuuRAXpMHjYUx91E=; X-YMail-OSG: jPFIr.UVM1lPpPiCoaFKuqgP2n7F9PRJKt9oav4zxsdtADnsKainHeFFWTDi8sLrtw-- Received: from [198.95.226.230] by web38112.mail.mud.yahoo.com via HTTP; Wed, 14 Nov 2007 19:36:20 PST Date: Wed, 14 Nov 2007 19:36:20 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] Issue in LAYOUTRETURN To: "Noveck, Dave" , nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <718630.72051.qm@web38112.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > In editing this to deal with another issue, I noted the following: > > The server MAY require that the principal, security flavor, and > applicable, the GSS mechanism, combination that acquired the > layout also be the one to issue LAYOUTRETURN. This might not be > possible if credentials for the principal are no longer > available. The server MAY allow the machine credential or SSV > credential (see ) to issue > DELEGRETURN. ^^^^^^^^^^^^ Is DELEGRETURN really meant here, or is it LAYOUTRETURN? > > If the client does the former without doing the latter, it is > going to have a heck of a time doing LAYOUTRETURN_FSID or > LAYOUTRETURN_ALL. Do we want to say something about this. Makes no difference to me. I'm sure some clients will fail to take advantage of mechanism no matter what we write down. > > Depending on your interpretation of: > > However, > if it is a subset, the recall is not complete until the full > recalled scope has been returned. Recalled scope refers to the > byte range in the case of LAYOUTRETURN4_FILE, use of > LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. > > it may not be possible to respond to LAYOUTRECALL of ALL, if > the requirement is that the client actually do a completing > LAYOUTRETURN4_ALL, rather than simply returning each and > every layout he holds. Beats me. This _FILE and _ALL stuff looks quarter baked to me. > > _______________________________________________ > 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 Nov 14 23:07: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 1IsW0e-000246-G7; Wed, 14 Nov 2007 23:07:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsW0d-000240-3b for nfsv4@ietf.org; Wed, 14 Nov 2007 23:07:19 -0500 Received: from web38110.mail.mud.yahoo.com ([209.191.124.137]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IsW0a-0003Pk-LK for nfsv4@ietf.org; Wed, 14 Nov 2007 23:07:19 -0500 Received: (qmail 65096 invoked by uid 60001); 15 Nov 2007 04:07:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=pNfp5ujZ2YnW+0cm5UFjLGB6yGPiRrny1Suh1Mbg7LrW7QsDItSCMhRkByKwCXrbylZHtYM+cqbvHUq4Zdl496koGWZjeR/K3NBDrnA/f+S6Y3njbqyc2Y1VXEosLJ7uWMlRhSsM969au0BMt0lcD6XOl4P4xtcM3HmhwTaPKuY=; X-YMail-OSG: Dc5rNDoVM1n7T5td_tEQx1oJVHJjadFCLb9ziJimScBHgeoPwIUAw6mtaC0pTecEhTkVusLz_Q-- Received: from [198.95.226.230] by web38110.mail.mud.yahoo.com via HTTP; Wed, 14 Nov 2007 20:07:16 PST Date: Wed, 14 Nov 2007 20:07:16 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] File Layout Questions (Layouts of the same file and Packing) To: Anatoly Pinchuk , email2mre-ietf@yahoo.com, nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <54531.64117.qm@web38110.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Anatoly Pinchuk wrote: > --- Anatoly Pinchuk wrote: > > > 1. If the client file layouts can have different stripe unit sizes > we > > need more than just a text clarification. In that case the layout > > structure should include additional information to calculate a data > > file offset for dense packing. Offset returned in layout4 structure > > and stripe unit size is not enough to do the calculation. Here is > an > > example: > > > > There are devices: > > struct nfsv4_1_file_layout_ds_addr4 > > dev0 = { // ID is 0 > > {0}, > > {{A}} > > }, > > dev1 = { // ID is 1 > > {0}, > > {{B}} > > }; > > > > File Layouts for a client file > > struct nfsv4_1_file_layout4 > > fl0 = { > > 0, deviceID 0 > > x, // stripe unit size of 0x400 is coded with x > > 0, > > fh0 > > }, > > fl1 = { > > 1, deviceID 1 > > y, // stripe unit size of 0x1000 and dense packing are coded > with > > y > > 0, > > fh1 > > }; > > > > fl0 and fl1 correspond to file ranges [0, 0x400-1] and [0x400, > > 0x1400-1]; > > > > Now a client requests layout for an offset of 0x800 and length > 0x400 > > and the reply is: > > > > struct layout4 > > lo = { > > 0x800, offset 0x800 > > 0x400, > > lo_iomode, // some IO mode > > lo_content // see below > > }; > > > > struct layout_content4 > > lo_content = { > > LAYOUT4_NFSV4_1_FILES, > > loc_body // see below > > }; > > loc_body contains fl1 defined above. > > > > So, the client knows the server (B) and the file handle (fh1) to do > > IO on. Offset for the fh1 is needed as well. The formula from > > paragraph 14.5 does not provide correct offset since > > > > data_file_offset = floor(file_offset / stripe_width) > > * stripe_unit_size + file_offset % stripe_unit_size = > > floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 = 0x800; > > > > and the correct offset is > > > > rel_off = (file_offset - layout_offset) = (0x800 - 0x400) = 0x400; > > data_file_offset = floor(rel_offset / stripe_width) > > * stripe_unit_size + rel_offset % stripe_unit_size = > > floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 = 0x400; Unless fh1 and fh0 are the same. This is a big problem and I don't have an immediate answer other than to suggest we remove dense packing from the protocol and rely on data server intelligence to pack stripe units. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From AntonyseminarianFuentes@closersounds.com Thu Nov 15 00:17:59 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsX71-0002GS-Mp; Thu, 15 Nov 2007 00:17:59 -0500 Received: from [201.141.95.15] (helo=631462bd666b438) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsX70-0001lt-Vh; Thu, 15 Nov 2007 00:17:59 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host29138135.closersounds.com (8.13.1/8.13.1) with SMTP id WiHmWnKK36.118375.GEY.cIz.5269649619891 for ; Wed, 14 Nov 2007 23:17:03 +0600 Message-ID: <111bc01c82746$d914eb80$2a04860a@631462bd666b438> From: "Ronny Morin" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_111B8_01C82746.D914EB80-- From nfsv4-bounces@ietf.org Thu Nov 15 00:19: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 1IsX8W-0005Gg-GX; Thu, 15 Nov 2007 00:19:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsX8U-0005Ex-O4 for nfsv4@ietf.org; Thu, 15 Nov 2007 00:19:30 -0500 Received: from web38115.mail.mud.yahoo.com ([209.191.124.142]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IsX8P-00056Q-SX for nfsv4@ietf.org; Thu, 15 Nov 2007 00:19:30 -0500 Received: (qmail 29741 invoked by uid 60001); 15 Nov 2007 05:19:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=YlXsOqVUKJt7sHZJMizKUOILeMa6SsmF5HPAS8qytEY591Mkutf58ZZbVyDER8p06fCtMNPsXzZWxDnH9eNUBFvdT25hAGfs3B+a+s1YI3fVZ0FATUqQcll+OkSHJ43ls9XKnodhcLzB4oZw/KVA/rQMXFBljpZSFZaoJ1WHbpQ=; X-YMail-OSG: Y39F2N0VM1leKnvk5KUPG8TMHYCd1OI97tVBiw1PPep0ZmRbd63suBThYzy9Z2GJ5vvztfqheA-- Received: from [198.95.226.230] by web38115.mail.mud.yahoo.com via HTTP; Wed, 14 Nov 2007 21:19:25 PST Date: Wed, 14 Nov 2007 21:19:25 -0800 (PST) From: Mike Eisler To: nfsv4@ietf.org In-Reply-To: <54531.64117.qm@web38110.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <391282.29333.qm@web38115.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [nfsv4] pNFS Dense Packing Problem X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org A majority of the editors agree we should remove DENSE packing from the NFSv4.1 pNFS file layout specification since as Anatoly points out, it doesn't work. I plan to start ripping it out in a few hours unless someone can convince us otherwise. --- Mike Eisler wrote: > > --- Anatoly Pinchuk wrote: > > > > --- Anatoly Pinchuk wrote: > > > > > 1. If the client file layouts can have different stripe unit > sizes > > we > > > need more than just a text clarification. In that case the layout > > > structure should include additional information to calculate a > data > > > file offset for dense packing. Offset returned in layout4 > structure > > > and stripe unit size is not enough to do the calculation. Here is > > an > > > example: > > > > > > There are devices: > > > struct nfsv4_1_file_layout_ds_addr4 > > > dev0 = { // ID is 0 > > > {0}, > > > {{A}} > > > }, > > > dev1 = { // ID is 1 > > > {0}, > > > {{B}} > > > }; > > > > > > File Layouts for a client file > > > struct nfsv4_1_file_layout4 > > > fl0 = { > > > 0, > > deviceID 0 > > > > x, // stripe unit size of 0x400 is coded with x > > > 0, > > > fh0 > > > }, > > > fl1 = { > > > 1, > > deviceID 1 > > > y, // stripe unit size of 0x1000 and dense packing are coded > > with > > > y > > > 0, > > > fh1 > > > }; > > > > > > fl0 and fl1 correspond to file ranges [0, 0x400-1] and [0x400, > > > 0x1400-1]; > > > > > > Now a client requests layout for an offset of 0x800 and length > > 0x400 > > > and the reply is: > > > > > > struct layout4 > > > lo = { > > > 0x800, > > offset 0x800 > > > > 0x400, > > > lo_iomode, // some IO mode > > > lo_content // see below > > > }; > > > > > > struct layout_content4 > > > lo_content = { > > > LAYOUT4_NFSV4_1_FILES, > > > loc_body // see below > > > }; > > > loc_body contains fl1 defined above. > > > > > > So, the client knows the server (B) and the file handle (fh1) to > do > > > IO on. Offset for the fh1 is needed as well. The formula from > > > paragraph 14.5 does not provide correct offset since > > > > > > data_file_offset = floor(file_offset / stripe_width) > > > * stripe_unit_size + file_offset % stripe_unit_size = > > > floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 = 0x800; > > > > > > and the correct offset is > > > > > > rel_off = (file_offset - layout_offset) = (0x800 - 0x400) = > 0x400; > > > data_file_offset = floor(rel_offset / stripe_width) > > > * stripe_unit_size + rel_offset % stripe_unit_size = > > > floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 = 0x400; > > Unless fh1 and fh0 are the same. > > This is a big problem and I don't have an immediate > answer other than to suggest we remove dense > packing from the protocol and rely on data server intelligence > to pack stripe units. > > > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From AugustusvladimirGood@lyricsfreak.com Thu Nov 15 01:45:22 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsYTa-0000pz-PY; Thu, 15 Nov 2007 01:45:22 -0500 Received: from 204.red-88-7-54.staticip.rima-tde.net ([88.7.54.204] helo=windowsd398d24) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsYTa-0004RH-8d; Thu, 15 Nov 2007 01:45:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host13053554.lyricsfreak.com (8.13.1/8.13.1) with SMTP id nmqm2cju35.693372.THw.D8r.2182187303317 for ; Thu, 15 Nov 2007 07:44:31 -0100 Message-ID: <94dcd01c82753$0be624a0$02f9a8c0@WINDOWSD398D24> From: "Chauncey Cash" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_94DC9_01C82753.0BE624A0-- From nfsv4-bounces@ietf.org Thu Nov 15 03:15: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 1IsZsU-0006Nf-1z; Thu, 15 Nov 2007 03:15:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsZsS-0006KN-H0 for nfsv4@ietf.org; Thu, 15 Nov 2007 03:15:08 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsZsP-0001TZ-TP for nfsv4@ietf.org; Thu, 15 Nov 2007 03:15:08 -0500 X-IronPort-AV: E=Sophos;i="4.21,419,1188802800"; d="scan'208";a="122592863" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 15 Nov 2007 00:15:04 -0800 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 lAF8F4V6028623; Thu, 15 Nov 2007 00:15:04 -0800 (PST) Received: from SACEXMV01.hq.netapp.com ([10.99.190.107]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 00:15:04 -0800 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] pNFS Dense Packing Problem Date: Thu, 15 Nov 2007 00:15:03 -0800 Message-ID: <01AE8AF878612047A442668306EAEB05013918D7@SACEXMV01.hq.netapp.com> In-reply-to: <391282.29333.qm@web38115.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] pNFS Dense Packing Problem Thread-Index: AcgnR2Zb6kkzqJ/VSmGcIA57hd5RAgAFJSYg References: <54531.64117.qm@web38110.mail.mud.yahoo.com> <391282.29333.qm@web38115.mail.mud.yahoo.com> From: "Muntz, Daniel" To: , X-OriginalArrivalTime: 15 Nov 2007 08:15:04.0148 (UTC) FILETIME=[A019C940:01C8275F] X-Spam-Score: -4.0 (----) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 Would it be correct to say that this decision is being made under these assumptions: 1) dense striping is less valuable than mixed stripe sizes 2) do not want to provide an option to choose either mixed stripe sizes _OR_ dense stripes per [file/fs/...] 3) mixed stripe sizes are believed to be supportable except for this conflict with dense striping (I'm still trying to convince myself on this point). -Dan > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 > Sent: Wednesday, November 14, 2007 9:19 PM > To: nfsv4@ietf.org > Subject: [nfsv4] pNFS Dense Packing Problem >=20 > A majority of the editors agree we should remove DENSE packing from > the NFSv4.1 pNFS file layout specification since as Anatoly=20 > points out, > it doesn't work. >=20 > I plan to start ripping it out in a few hours unless someone can > convince us otherwise. >=20 > --- Mike Eisler wrote: >=20 > >=20 > > --- Anatoly Pinchuk wrote: > >=20 > >=20 > > > --- Anatoly Pinchuk wrote: > > >=20 > > > > 1. If the client file layouts can have different stripe unit > > sizes > > > we > > > > need more than just a text clarification. In that case=20 > the layout > > > > structure should include additional information to calculate a > > data > > > > file offset for dense packing. Offset returned in layout4 > > structure > > > > and stripe unit size is not enough to do the=20 > calculation. Here is > > > an > > > > example: > > > > =20 > > > > There are devices: > > > > struct nfsv4_1_file_layout_ds_addr4 > > > > dev0 =3D { // ID is 0 > > > > {0}, > > > > {{A}} > > > > }, > > > > dev1 =3D { // ID is 1 > > > > {0}, > > > > {{B}} > > > > }; > > > > =20 > > > > File Layouts for a client file > > > > struct nfsv4_1_file_layout4 > > > > fl0 =3D { > > > > 0, > >=20 > > deviceID 0 > >=20 > > > > x, // stripe unit size of 0x400 is coded with x > > > > 0, > > > > fh0 > > > > }, > > > > fl1 =3D { > > > > 1, > >=20 > > deviceID 1 > > > > y, // stripe unit size of 0x1000 and dense packing are coded > > > with > > > > y > > > > 0, > > > > fh1 > > > > }; > > > > =20 > > > > fl0 and fl1 correspond to file ranges [0, 0x400-1] and [0x400, > > > > 0x1400-1]; > > > > =20 > > > > Now a client requests layout for an offset of 0x800 and length > > > 0x400 > > > > and the reply is: > > > > =20 > > > > struct layout4 > > > > lo =3D { > > > > 0x800, > >=20 > > offset 0x800 > >=20 > > > > 0x400, > > > > lo_iomode, // some IO mode > > > > lo_content // see below > > > > }; > > > > =20 > > > > struct layout_content4 > > > > lo_content =3D { > > > > LAYOUT4_NFSV4_1_FILES, > > > > loc_body // see below > > > > }; > > > > loc_body contains fl1 defined above. > > > > =20 > > > > So, the client knows the server (B) and the file handle (fh1) to > > do > > > > IO on. Offset for the fh1 is needed as well. The formula from > > > > paragraph 14.5 does not provide correct offset since > > > > =20 > > > > data_file_offset =3D floor(file_offset / stripe_width) > > > > * stripe_unit_size + file_offset % stripe_unit_size =3D > > > > floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 =3D 0x800; > > > > =20 > > > > and the correct offset is > > > >=20 > > > > rel_off =3D (file_offset - layout_offset) =3D (0x800 - 0x400) = =3D > > 0x400;=20 > > > > data_file_offset =3D floor(rel_offset / stripe_width) > > > > * stripe_unit_size + rel_offset % stripe_unit_size =3D > > > > floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 =3D 0x400; > >=20 > > Unless fh1 and fh0 are the same. > >=20 > > This is a big problem and I don't have an immediate > > answer other than to suggest we remove dense > > packing from the protocol and rely on data server intelligence > > to pack stripe units. > >=20 > >=20 > >=20 >=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 Thu Nov 15 04:45: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 1IsbHl-0002XM-55; Thu, 15 Nov 2007 04:45:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsbHk-0002WH-9L for nfsv4@ietf.org; Thu, 15 Nov 2007 04:45:20 -0500 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 1IsbHj-000396-L2 for nfsv4@ietf.org; Thu, 15 Nov 2007 04:45:20 -0500 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 lAF9jIpa016159; Thu, 15 Nov 2007 04:45:19 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 15 Nov 2007 04:45:18 -0500 Received: from fs1.bhalevy.com ([172.17.28.115]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 04:45:18 -0500 Message-ID: <473C152C.9070900@panasas.com> Date: Thu, 15 Nov 2007 11:45:16 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Muntz, Daniel" , email2mre-ietf@yahoo.com Subject: Re: [nfsv4] pNFS Dense Packing Problem References: <54531.64117.qm@web38110.mail.mud.yahoo.com> <391282.29333.qm@web38115.mail.mud.yahoo.com> <01AE8AF878612047A442668306EAEB05013918D7@SACEXMV01.hq.netapp.com> In-Reply-To: <01AE8AF878612047A442668306EAEB05013918D7@SACEXMV01.hq.netapp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2007 09:45:18.0676 (UTC) FILETIME=[3B693140:01C8276C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: Brent Welch , 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 The initial assumption AFAICT was that there is just one stripe (unit) size for the file and the data_file_offset calculation was based on that. This can be fixed by either allowing mixed stripe unit sizes and correcting the math in section 13.4.2. Interpreting the File Layout Using Dense Packing, or by eliminating mixed stripe sizes, e.g. by moving the stripe unit size to nfsv4_1_file_layouthint4, along side with nflh_stripe_count. BTW, if you allow mixed stripe sizes why don't you provide for mixed stripe counts? In CMU's model the file could be comprised of a concatenation of "patterns" each with it's own striping geometry, and frankly, intuitively this makes more sense to me than a set stripe count and variable stripe unit size... Anyhow, I'm not sure how mixed stripe unit sizes work with sparse packing and what's their use case. If supporting them isn't justified I'd rather eliminate that feature rather than dense packing. Benny On Nov. 15, 2007, 10:15 +0200, "Muntz, Daniel" wrote: > Would it be correct to say that this decision is being made under these > assumptions: > > 1) dense striping is less valuable than mixed stripe sizes > 2) do not want to provide an option to choose either mixed stripe sizes > _OR_ dense stripes per [file/fs/...] > 3) mixed stripe sizes are believed to be supportable except for this > conflict with dense striping (I'm still trying to convince myself on > this point). > > -Dan > >> -----Original Message----- >> From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] >> Sent: Wednesday, November 14, 2007 9:19 PM >> To: nfsv4@ietf.org >> Subject: [nfsv4] pNFS Dense Packing Problem >> >> A majority of the editors agree we should remove DENSE packing from >> the NFSv4.1 pNFS file layout specification since as Anatoly >> points out, >> it doesn't work. >> >> I plan to start ripping it out in a few hours unless someone can >> convince us otherwise. >> >> --- Mike Eisler wrote: >> >>> --- Anatoly Pinchuk wrote: >>> >>> >>>> --- Anatoly Pinchuk wrote: >>>> >>>>> 1. If the client file layouts can have different stripe unit >>> sizes >>>> we >>>>> need more than just a text clarification. In that case >> the layout >>>>> structure should include additional information to calculate a >>> data >>>>> file offset for dense packing. Offset returned in layout4 >>> structure >>>>> and stripe unit size is not enough to do the >> calculation. Here is >>>> an >>>>> example: >>>>> >>>>> There are devices: >>>>> struct nfsv4_1_file_layout_ds_addr4 >>>>> dev0 = { // ID is 0 >>>>> {0}, >>>>> {{A}} >>>>> }, >>>>> dev1 = { // ID is 1 >>>>> {0}, >>>>> {{B}} >>>>> }; >>>>> >>>>> File Layouts for a client file >>>>> struct nfsv4_1_file_layout4 >>>>> fl0 = { >>>>> 0, >>> deviceID 0 >>> >>>>> x, // stripe unit size of 0x400 is coded with x >>>>> 0, >>>>> fh0 >>>>> }, >>>>> fl1 = { >>>>> 1, >>> deviceID 1 >>>>> y, // stripe unit size of 0x1000 and dense packing are coded >>>> with >>>>> y >>>>> 0, >>>>> fh1 >>>>> }; >>>>> >>>>> fl0 and fl1 correspond to file ranges [0, 0x400-1] and [0x400, >>>>> 0x1400-1]; >>>>> >>>>> Now a client requests layout for an offset of 0x800 and length >>>> 0x400 >>>>> and the reply is: >>>>> >>>>> struct layout4 >>>>> lo = { >>>>> 0x800, >>> offset 0x800 >>> >>>>> 0x400, >>>>> lo_iomode, // some IO mode >>>>> lo_content // see below >>>>> }; >>>>> >>>>> struct layout_content4 >>>>> lo_content = { >>>>> LAYOUT4_NFSV4_1_FILES, >>>>> loc_body // see below >>>>> }; >>>>> loc_body contains fl1 defined above. >>>>> >>>>> So, the client knows the server (B) and the file handle (fh1) to >>> do >>>>> IO on. Offset for the fh1 is needed as well. The formula from >>>>> paragraph 14.5 does not provide correct offset since >>>>> >>>>> data_file_offset = floor(file_offset / stripe_width) >>>>> * stripe_unit_size + file_offset % stripe_unit_size = >>>>> floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 = 0x800; >>>>> >>>>> and the correct offset is >>>>> >>>>> rel_off = (file_offset - layout_offset) = (0x800 - 0x400) = >>> 0x400; >>>>> data_file_offset = floor(rel_offset / stripe_width) >>>>> * stripe_unit_size + rel_offset % stripe_unit_size = >>>>> floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 = 0x400; >>> Unless fh1 and fh0 are the same. >>> >>> This is a big problem and I don't have an immediate >>> answer other than to suggest we remove dense >>> packing from the protocol and rely on data server intelligence >>> to pack stripe units. >>> >>> >>> >> >> _______________________________________________ >> 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 Nov 15 07:30:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isdra-0006zF-Iy; Thu, 15 Nov 2007 07:30:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isdra-0006zA-09 for nfsv4@ietf.org; Thu, 15 Nov 2007 07:30:30 -0500 Received: from web38110.mail.mud.yahoo.com ([209.191.124.137]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IsdrX-0001AL-BC for nfsv4@ietf.org; Thu, 15 Nov 2007 07:30:29 -0500 Received: (qmail 47341 invoked by uid 60001); 15 Nov 2007 12:30:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=WZNfLWXhJYeEI5RKj+GSJ8Bdj710Bq/zCm2dL6inb1n/A/yViJumfGBu4hs5lwIPQNOXdLXBtKOI3+hcsUtXTrswu2q1JvKO0LeelJFOM8uKMFYl/I2tsERGR/kMFge+EDQAVacn0o9nhF7L7LS09iBYiYQFyZWTokqQ5BGdrmM=; X-YMail-OSG: 0tBKWeQVM1kPb2WCiHGZMGK_ir75MYLYt0RCR88D6XnGBo_AlIRnMcO1zlS.qWgy5pVOv5z40lpZT4DkltEiQAWyIdGiV8rzrsXOkvZekGh_PUfhru0- Received: from [198.95.226.230] by web38110.mail.mud.yahoo.com via HTTP; Thu, 15 Nov 2007 04:30:26 PST Date: Thu, 15 Nov 2007 04:30:26 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] pNFS Dense Packing Problem To: "Muntz, Daniel" , email2mre-ietf@yahoo.com, nfsv4@ietf.org In-Reply-To: <01AE8AF878612047A442668306EAEB05013918D7@SACEXMV01.hq.netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <732387.44318.qm@web38110.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Muntz, Daniel" wrote: > Would it be correct to say that this decision is being made under > these > assumptions: > > 1) dense striping is less valuable than mixed stripe sizes > 2) do not want to provide an option to choose either mixed stripe > sizes > _OR_ dense stripes per [file/fs/...] > 3) mixed stripe sizes are believed to be supportable except for this > conflict with dense striping (I'm still trying to convince myself on > this point). Dense packing and mixed stripe sizes are suppportable as explicit entries in the protocol. It requires making the specification text more complex, hence easier to misinterpret. Why do we have dense packing? 1. Some filesystems can't do holes well. 2. readahead I/O is harder to detect Dense packing can be done without making it part of the file layout: just implement data servers to map the sparse offsets to dense offsets. > > -Dan > > > -----Original Message----- > > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > > Sent: Wednesday, November 14, 2007 9:19 PM > > To: nfsv4@ietf.org > > Subject: [nfsv4] pNFS Dense Packing Problem > > > > A majority of the editors agree we should remove DENSE packing from > > the NFSv4.1 pNFS file layout specification since as Anatoly > > points out, > > it doesn't work. > > > > I plan to start ripping it out in a few hours unless someone can > > convince us otherwise. > > > > --- Mike Eisler wrote: > > > > > > > > --- Anatoly Pinchuk wrote: > > > > > > > > > > --- Anatoly Pinchuk wrote: > > > > > > > > > 1. If the client file layouts can have different stripe unit > > > sizes > > > > we > > > > > need more than just a text clarification. In that case > > the layout > > > > > structure should include additional information to calculate > a > > > data > > > > > file offset for dense packing. Offset returned in layout4 > > > structure > > > > > and stripe unit size is not enough to do the > > calculation. Here is > > > > an > > > > > example: > > > > > > > > > > There are devices: > > > > > struct nfsv4_1_file_layout_ds_addr4 > > > > > dev0 = { // ID is 0 > > > > > {0}, > > > > > {{A}} > > > > > }, > > > > > dev1 = { // ID is 1 > > > > > {0}, > > > > > {{B}} > > > > > }; > > > > > > > > > > File Layouts for a client file > > > > > struct nfsv4_1_file_layout4 > > > > > fl0 = { > > > > > 0, > > > > > > deviceID 0 > > > > > > > > x, // stripe unit size of 0x400 is coded with x > > > > > 0, > > > > > fh0 > > > > > }, > > > > > fl1 = { > > > > > 1, > > > > > > deviceID 1 > > > > > y, // stripe unit size of 0x1000 and dense packing are > coded > > > > with > > > > > y > > > > > 0, > > > > > fh1 > > > > > }; > > > > > > > > > > fl0 and fl1 correspond to file ranges [0, 0x400-1] and > [0x400, > > > > > 0x1400-1]; > > > > > > > > > > Now a client requests layout for an offset of 0x800 and > length > > > > 0x400 > > > > > and the reply is: > > > > > > > > > > struct layout4 > > > > > lo = { > > > > > 0x800, > > > > > > offset 0x800 > > > > > > > > 0x400, > > > > > lo_iomode, // some IO mode > > > > > lo_content // see below > > > > > }; > > > > > > > > > > struct layout_content4 > > > > > lo_content = { > > > > > LAYOUT4_NFSV4_1_FILES, > > > > > loc_body // see below > > > > > }; > > > > > loc_body contains fl1 defined above. > > > > > > > > > > So, the client knows the server (B) and the file handle (fh1) > to > > > do > > > > > IO on. Offset for the fh1 is needed as well. The formula from > > > > > paragraph 14.5 does not provide correct offset since > > > > > > > > > > data_file_offset = floor(file_offset / stripe_width) > > > > > * stripe_unit_size + file_offset % stripe_unit_size = > > > > > floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 = 0x800; > > > > > > > > > > and the correct offset is > > > > > > > > > > rel_off = (file_offset - layout_offset) = (0x800 - 0x400) = > > > 0x400; > > > > > data_file_offset = floor(rel_offset / stripe_width) > > > > > * stripe_unit_size + rel_offset % stripe_unit_size = > > > > > floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 = 0x400; > > > > > > Unless fh1 and fh0 are the same. > > > > > > This is a big problem and I don't have an immediate > > > answer other than to suggest we remove dense > > > packing from the protocol and rely on data server intelligence > > > to pack stripe units. > > > > > > > > > > > > > > > _______________________________________________ > > 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 Nov 15 07:44: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 1Ise5Q-00069w-TM; Thu, 15 Nov 2007 07:44:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ise5P-00067g-Kf for nfsv4@ietf.org; Thu, 15 Nov 2007 07:44:47 -0500 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 1Ise5L-0001ku-K1 for nfsv4@ietf.org; Thu, 15 Nov 2007 07:44:47 -0500 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 lAFCdLTb018678; Thu, 15 Nov 2007 07:39:21 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 15 Nov 2007 07:39:21 -0500 Received: from fs1.bhalevy.com ([172.17.28.115]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 07:39:20 -0500 Message-ID: <473C3DF7.10400@panasas.com> Date: Thu, 15 Nov 2007 14:39:19 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Noveck, Dave" Subject: Re: [nfsv4] LAYOUTGET minlength References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2007 12:39:20.0975 (UTC) FILETIME=[8B8191F0:01C82784] X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: Marc Eshel , 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 Nov. 14, 2007, 18:07 +0200, "Noveck, Dave" wrote: >> It is just a way for the client to tell the server to deiced how >> much to return. > > Exactly. It's saying whatever the server decides is OK with you. > I'd prefer not to do that. > >> server prefers that the client don't use layout it can decline >> the request for a layout > > Doesn't the client have any preferences here? The idea of length=0,minlength=0 is that the client does not need the layout right now. Without having that, the server may provisionally allocate storage space for no reason as the application may not write at all to the file or write to some byte range not covered by the initial guess. With length=0,minlength=0 you leave that up to the server which may return, for example in our case, the layout with capabilities that allow you only to do getattrs to the objects so you can make as much preparations, e.g. connect with the respective OSDs, get each object's attributes, in advance, without doing any I/O. So the layout will describe the file but will not allow any I/O. How about allowing minlength == 0 only for length == 0? > >> If you don't use layout for small files and most of the files >> are small you are going to overload your MDS. > > I think you need to distinguish small files and small layouts. If > a file is 50 bytes and I get a 64K layout, then I'm cool sending a > 50-byte READ to the DS. If the file is 64K and I get a 50 byte > layout, the DS is not going to be my choice. If the file and > the layout are both 50 bytes, I'm not sure. I'd probably decide > to use a different server. If you care, set minlength != 0, if not, then don't and let the server make the choice. minlength==0 helps with allowing the server to return a layout for no bytes and avoiding any unneeded provisional allocations. Benny > > > > -----Original Message----- > From: Marc Eshel [mailto:eshel@almaden.ibm.com] > Sent: Wednesday, November 14, 2007 10:11 AM > To: Noveck, Dave > Cc: Benny Halevy; NFSv4 > Subject: RE: [nfsv4] LAYOUTGET minlength > > I think this a fine idea. It is just a way for the client to tell the > server to deiced how much to return. If it is a read for a small file > and the server prefers that the client don't use layout it can decline > the request for a layout, but I think that in general it is better to > use layout for every file so we get load balancing. If you don't use > layout for small files and most of the files are small you are going to > overload your MDS. > Marc. > > "Noveck, Dave" wrote on 11/14/2007 06:29:46 AM: > >> I guess I don't have any objection to allowing this to be zero but I >> think it is a mistake on the part of client to send this value as zero > >> or anything below around 64K. >> >> Although I'm not asking for the spec to say this, my view is that if >> you send very low values, then you "SHOULD have your head examined." >> >> Accessing the data server directly is an optmization and the layout >> lengths you get should not make it a pessimization. >> If the layout lengths are so short that it is, you should read and >> write to the MDS. A value of zero, which suggests that you want any >> length for communication with the DS, no matter how small, in >> preference to communication with the MDS, suggests a very different >> view of the matter. We can't legislate performance characteristics >> (or at least I'd prefer not to have to draft the requisite >> legislation), but I would hope that clients not assume the sort of >> very slow MDS that would justify this strategy and that servers would >> not drive them to it. >> >> "for which the length doesn't matter, as the client has no bytes to >> read or write at this point." seems to ignore important issues. >> Despite the fact that no read or write is physically pending, clients >> will have buffer sizes and other existing performance characteristics >> that give some idea of where the cross-over point for MDS-vs-DS access > >> is. Given that, I would say that there would be some non-zero length >> where the client would in effect say "If you can't give me at least N >> bytes, then don't bother". Saying that one byte is OK whether by >> sending one or zero as the minlength would seem to call for the >> aformentioned mental status examination. >> >> In the implementations I would be doing, even if the client asked for >> zero, he would get a considerable length, but he would also get that >> if he asked for one byte. >> >> -----Original Message----- >> From: Benny Halevy [mailto:bhalevy@panasas.com] >> Sent: Wednesday, November 14, 2007 8:49 AM >> To: NFSv4 >> Subject: [nfsv4] LAYOUTGET minlength >> >> Following a discussion we had in the last Bakeathon I propose the >> following wording changes: >> >> 1. Allow zero minlength. >> The motivation is to send an opportunistic LAYOUTGET for >> iomode=open_mode and offset=length=minlength=0 along with OPEN so that > >> the server can return an initial layout starting from offset 0 for >> which the length doesn't matter, as the client has no bytes to read or > >> write at this point. >> >> diff -Npu a/nfsv41_middle_pnfs.xml b/nfsv41_middle_pnfs.xml >> --- a/nfsv41_middle_pnfs.xml >> +++ b/nfsv41_middle_pnfs.xml >> @@ -454,9 +454,8 @@ >> the requested byte range. A field within the LAYOUTGET request, >> loga_minlength, specifies the minimum overlap that MUST exist >> between the requested layout and the layout returned by the >> metadata >> - server. The loga_minlength field should be at least one. As needed > >> a >> - client may make multiple LAYOUTGET requests; these will result in >> - multiple overlapping, non-conflicting layouts. >> + server. As needed, a client may make multiple LAYOUTGET requests; >> + these will result in multiple overlapping, non-conflicting layouts. >> >> >> There is no required ordering between getting a layout and >> performing >> >> 2. clarify how loga_minlength relates to the requested offset There >> was agreement among the bakeathon participants that the minlength >> bytes that the client wants should start from the requested offset >> rather than just any minlength bytes in the requested byte-range. >> >> diff -Npu a/nfsv41_middle_op_layoutget.xml >> b/nfsv41_middle_op_layoutget.xml >> --- a/nfsv41_middle_op_layoutget.xml >> +++ b/nfsv41_middle_op_layoutget.xml >> @@ -69,7 +69,8 @@ >> the loga_iomode. The client must be prepared to get a layout >> that does not align exactly with its request. There MUST be at >> least an overlap of loga_minlength between the layout returned >> - by the server and the client's request, or the server SHOULD >> + by the server and the client's request, starting from > loga_offset >> + to loga_offset + loga_minlength, or the server SHOULD >> reject the request. See for >> more details. >> >> >> 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 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 15 07:46: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 1Ise6x-0000P9-Ov; Thu, 15 Nov 2007 07:46:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ise6w-0000Hs-9o for nfsv4@ietf.org; Thu, 15 Nov 2007 07:46:22 -0500 Received: from web38112.mail.mud.yahoo.com ([209.191.124.139]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ise6r-0001of-AN for nfsv4@ietf.org; Thu, 15 Nov 2007 07:46:22 -0500 Received: (qmail 70278 invoked by uid 60001); 15 Nov 2007 12:46:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=E+SEbB5ioAO2FXEd3bNFuCbQTzA5g+voRGvaozs8ZjVsNXayRacqTuHcHIGRcpIu+mnrgc1ctb4bjBb+ITk44gfbovQPS191KJssrkad0SmG3tE/CEJqrLmPrRFuuoh8Mv2icqIpMtEhO/GXeLtp2rbwqcKj+aRkuBzmQuAIaW0=; X-YMail-OSG: 49zdHXwVM1mO0Um9Zl.VY3ZETk7aMe1Ys8bLOzlR.V1NNq.XQOtHibWKIs2FgsGLEBGY.sw04BPkH7mhyVbE6PdEXwpWsVy4SI0HE.ZhOXA10fiWs6E- Received: from [198.95.226.230] by web38112.mail.mud.yahoo.com via HTTP; Thu, 15 Nov 2007 04:46:16 PST Date: Thu, 15 Nov 2007 04:46:16 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] pNFS Dense Packing Problem To: nfsv4@ietf.org In-Reply-To: <473C152C.9070900@panasas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <780754.70076.qm@web38112.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Benny Halevy wrote: > The initial assumption AFAICT was that there is just one stripe > (unit) size > for the file and the data_file_offset calculation was based on that. Apparently. > This can be fixed by either allowing mixed stripe unit sizes and > correcting > the math in section 13.4.2. Interpreting the File Layout Using Dense > Packing, > or by eliminating mixed stripe sizes, e.g. by moving the stripe unit > size > to nfsv4_1_file_layouthint4, along side with nflh_stripe_count. BTW, The stripe unit size can't be in the hint, because the hint is write only. > if you > allow mixed stripe sizes why don't you provide for mixed stripe > counts? We do provide mixed stripe counts. ``The number of elements in nflda_stripe_indices is always equal to the stripe count.'' We can have multiple instances data types of type nfsv4_1_file_layout4 in a layout, and there is one nflda_stripe_indices field per instance of nfsv4_1_file_layout4. > In CMU's model the file could be comprised of a concatenation of > "patterns" > each with it's own striping geometry, and frankly, intuitively this Which is what we have today. > makes > more sense to me than a set stripe count and variable stripe unit > size... > Anyhow, I'm not sure how mixed stripe unit sizes work with sparse > packing and what's their use case. If supporting them isn't justified As long as the array of elements of type layout4 don't overlap, I believe mixed stripe unit sizes work fine for sparse packing. Anyway, I never wanted mixed stripe unit sizes; the consensus was to have them. Given that consensus, I'm saying dense packing has to be deleted. > I'd rather eliminate that feature rather than dense packing. > > Benny > > On Nov. 15, 2007, 10:15 +0200, "Muntz, Daniel" > wrote: > > Would it be correct to say that this decision is being made under > these > > assumptions: > > > > 1) dense striping is less valuable than mixed stripe sizes > > 2) do not want to provide an option to choose either mixed stripe > sizes > > _OR_ dense stripes per [file/fs/...] > > 3) mixed stripe sizes are believed to be supportable except for > this > > conflict with dense striping (I'm still trying to convince myself > on > > this point). > > > > -Dan > > > >> -----Original Message----- > >> From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > >> Sent: Wednesday, November 14, 2007 9:19 PM > >> To: nfsv4@ietf.org > >> Subject: [nfsv4] pNFS Dense Packing Problem > >> > >> A majority of the editors agree we should remove DENSE packing > from > >> the NFSv4.1 pNFS file layout specification since as Anatoly > >> points out, > >> it doesn't work. > >> > >> I plan to start ripping it out in a few hours unless someone can > >> convince us otherwise. > >> > >> --- Mike Eisler wrote: > >> > >>> --- Anatoly Pinchuk wrote: > >>> > >>> > >>>> --- Anatoly Pinchuk wrote: > >>>> > >>>>> 1. If the client file layouts can have different stripe unit > >>> sizes > >>>> we > >>>>> need more than just a text clarification. In that case > >> the layout > >>>>> structure should include additional information to calculate a > >>> data > >>>>> file offset for dense packing. Offset returned in layout4 > >>> structure > >>>>> and stripe unit size is not enough to do the > >> calculation. Here is > >>>> an > >>>>> example: > >>>>> > >>>>> There are devices: > >>>>> struct nfsv4_1_file_layout_ds_addr4 > >>>>> dev0 = { // ID is 0 > >>>>> {0}, > >>>>> {{A}} > >>>>> }, > >>>>> dev1 = { // ID is 1 > >>>>> {0}, > >>>>> {{B}} > >>>>> }; > >>>>> > >>>>> File Layouts for a client file > >>>>> struct nfsv4_1_file_layout4 > >>>>> fl0 = { > >>>>> 0, > >>> deviceID 0 > >>> > >>>>> x, // stripe unit size of 0x400 is coded with x > >>>>> 0, > >>>>> fh0 > >>>>> }, > >>>>> fl1 = { > >>>>> 1, > >>> deviceID 1 > >>>>> y, // stripe unit size of 0x1000 and dense packing are > coded > >>>> with > >>>>> y > >>>>> 0, > >>>>> fh1 > >>>>> }; > >>>>> > >>>>> fl0 and fl1 correspond to file ranges [0, 0x400-1] and [0x400, > >>>>> 0x1400-1]; > >>>>> > >>>>> Now a client requests layout for an offset of 0x800 and length > >>>> 0x400 > >>>>> and the reply is: > >>>>> > >>>>> struct layout4 > >>>>> lo = { > >>>>> 0x800, > >>> offset 0x800 > >>> > >>>>> 0x400, > >>>>> lo_iomode, // some IO mode > >>>>> lo_content // see below > >>>>> }; > >>>>> > >>>>> struct layout_content4 > >>>>> lo_content = { > >>>>> LAYOUT4_NFSV4_1_FILES, > >>>>> loc_body // see below > >>>>> }; > >>>>> loc_body contains fl1 defined above. > >>>>> > >>>>> So, the client knows the server (B) and the file handle (fh1) > to > >>> do > >>>>> IO on. Offset for the fh1 is needed as well. The formula from > >>>>> paragraph 14.5 does not provide correct offset since > >>>>> > >>>>> data_file_offset = floor(file_offset / stripe_width) > >>>>> * stripe_unit_size + file_offset % stripe_unit_size = > >>>>> floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 = 0x800; > >>>>> > >>>>> and the correct offset is > >>>>> > >>>>> rel_off = (file_offset - layout_offset) = (0x800 - 0x400) = > >>> 0x400; > >>>>> data_file_offset = floor(rel_offset / stripe_width) > >>>>> * stripe_unit_size + rel_offset % stripe_unit_size = > >>>>> floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 = 0x400; > >>> Unless fh1 and fh0 are the same. > >>> > >>> This is a big problem and I don't have an immediate > >>> answer other than to suggest we remove dense > >>> packing from the protocol and rely on data server intelligence > >>> to pack stripe units. > >>> > >>> > >>> > >> > >> _______________________________________________ > >> 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 Nov 15 08:25: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 1Isej3-0001Xq-2h; Thu, 15 Nov 2007 08:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isej2-0001Xg-E2 for nfsv4@ietf.org; Thu, 15 Nov 2007 08:25:44 -0500 Received: from web38110.mail.mud.yahoo.com ([209.191.124.137]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Iseiz-00033v-VN for nfsv4@ietf.org; Thu, 15 Nov 2007 08:25:44 -0500 Received: (qmail 68398 invoked by uid 60001); 15 Nov 2007 13:25:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=6By+hpFZ+C1KHUhT5qXoESKlAgyPMOMnmJKOoEVjqwDjaky4T6uVqfk4wjKor+EshoIDeihY230HhRYsk/h6ypOra++SRjFcgpoOY2DWqplL9QBGYsJ43OsNvTtUlGrfduKxSUj+6etHMQ6gatFddrrZ4Qjk1dUVxhx+bmEwQaQ=; X-YMail-OSG: zgGc3pAVM1nJmFbOfyh7SsNJ3J3lW3fFrvh3r_AJkQ3.BQr4_9V2GMQogll_3odyQ0ikYR.d4DtER6KACY0t8i_6Kg142v5ccwkmI.tnN6LaiTI- Received: from [198.95.226.230] by web38110.mail.mud.yahoo.com via HTTP; Thu, 15 Nov 2007 05:25:40 PST Date: Thu, 15 Nov 2007 05:25:40 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] LAYOUTGET minlength To: Benny Halevy , NFSv4 In-Reply-To: <473AFCD1.8060708@panasas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <143562.67946.qm@web38110.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Benny Halevy wrote: > Following a discussion we had in the last Bakeathon > I propose the following wording changes: > > 1. Allow zero minlength. > The motivation is to send an opportunistic LAYOUTGET for > iomode=open_mode and offset=length=minlength=0 along with OPEN > so that the server can return an initial layout starting from offset > 0 > for which the length doesn't matter, as the client has no bytes to > read or write at this point. Why doesn't minlength=length=1 work? Here's my preference: delete minlength. The text about minlength and overlap never made any sense. > > diff -Npu a/nfsv41_middle_pnfs.xml b/nfsv41_middle_pnfs.xml > --- a/nfsv41_middle_pnfs.xml > +++ b/nfsv41_middle_pnfs.xml > @@ -454,9 +454,8 @@ > the requested byte range. A field within the LAYOUTGET request, > loga_minlength, specifies the minimum overlap that MUST exist > between the requested layout and the layout returned by the > metadata > - server. The loga_minlength field should be at least one. As > needed a > - client may make multiple LAYOUTGET requests; these will result in > - multiple overlapping, non-conflicting layouts. > + server. As needed, a client may make multiple LAYOUTGET requests; > + these will result in multiple overlapping, non-conflicting > layouts. > > > There is no required ordering between getting a layout and > performing > > 2. clarify how loga_minlength relates to the requested offset > There was agreement among the bakeathon participants that the > minlength > bytes that the client wants should start from the requested offset > rather > than just any minlength bytes in the requested byte-range. > > diff -Npu a/nfsv41_middle_op_layoutget.xml > b/nfsv41_middle_op_layoutget.xml > --- a/nfsv41_middle_op_layoutget.xml > +++ b/nfsv41_middle_op_layoutget.xml > @@ -69,7 +69,8 @@ > the loga_iomode. The client must be prepared to get a layout > that does not align exactly with its request. There MUST be at > least an overlap of loga_minlength between the layout returned > - by the server and the client's request, or the server SHOULD > + by the server and the client's request, starting from > loga_offset > + to loga_offset + loga_minlength, or the server SHOULD > reject the request. See > for > more details. > > > 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 Thu Nov 15 08: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 1IsesC-0000ya-Pp; Thu, 15 Nov 2007 08:35:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsesB-0000so-7R for nfsv4@ietf.org; Thu, 15 Nov 2007 08:35:11 -0500 Received: from web38108.mail.mud.yahoo.com ([209.191.124.135]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsesA-0003LP-O1 for nfsv4@ietf.org; Thu, 15 Nov 2007 08:35:11 -0500 Received: (qmail 2374 invoked by uid 60001); 15 Nov 2007 13:35:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=mtZIGyd6GAW4Zpb5WCfwROOMWGWt5e9qHyAe/icsZ5uKobnWttKkE+qhfBqRXnATz/Mu+L5iGxBEAnGwt9p4t/Ed4kg0Mi3RrSChaxIM8iYb59BY/xsuY4cxVLwiPvFosQUn8tspCXknSgzUx008/mZPR8XODMwX8ai/Q1xktoI=; X-YMail-OSG: WwD0buYVM1kaBEGFLm4OFlTDaLyiN0Z3V.Y2A.y7TFsJETc51x_8we758iEt0IDECH5QDJEsYh3HheqYL3ov2RjsJ8W0CpBKo_Q1KdLQe0SKxkw- Received: from [198.95.226.230] by web38108.mail.mud.yahoo.com via HTTP; Thu, 15 Nov 2007 05:35:07 PST Date: Thu, 15 Nov 2007 05:35:07 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] draft-ietf-nfsv4-minorversion1-16 LAYOUTRETURN question To: "William A. \(Andy\) Adamson" , NFSv4 In-Reply-To: <89c397150711140921p72368255s7c9076be9fa4aae5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <521784.66342.qm@web38108.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "William A. (Andy) Adamson" wrote: > Sorry if I missed the discussion on this point. > > The last paragraph of section 18.44.3 (LAYOUTRETURN) > draft-ietf-nfsv4-minorversion1-16.txt: > > The server MAY require that the principal, security flavor, and > applicable, the GSS mechanism, combination that acquired the > layout > also be the one to issue LAYOUTRETURN. his might not be possible > if > credentials for the principal are no longer available. The server > MAY allow the machine credential or SSV credential (see > Section 18.35) to issue DELEGRETURN. > > > Why is it allowed for a client-wide layout to be attached to a user? > This paragraph suggests that the layout is somehow attached to user > credentials. The layout, and therefore the layoutreturn, is of client > scope and so any user credentials should be acceptable to any pnfs > server. > It is attached to whoever obtained the layout via LAYOUTGET. If the layout is client wide, then use a client wide credential to get the layout, so that cred can return the layout. > Also. Why is it that the pNFS server is not required to allow machine > credentials?!?!? The client and server negotiate this when EXCHANGE_ID is called. It is worth a read. This all goes back to an email Rick Macklem sent about how does a client recover when it used Kerberos creds for a normal user to OPEN a file, and now wants to CLOSE and has no Kerberos creds for the user to issue the CLOSE with. The client can use a machine cred or SSV cred to issue CLOSE with. > > -->Andy > > _______________________________________________ > 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 Nov 15 08:40: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 1IsexW-0001BV-Uv; Thu, 15 Nov 2007 08:40:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsexW-00019W-0H for nfsv4@ietf.org; Thu, 15 Nov 2007 08:40:42 -0500 Received: from web38114.mail.mud.yahoo.com ([209.191.124.141]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IsexS-0003dE-Lb for nfsv4@ietf.org; Thu, 15 Nov 2007 08:40:41 -0500 Received: (qmail 59317 invoked by uid 60001); 15 Nov 2007 13:40:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=WpSa7xXjMx5pXKWdcLGVTI/2EsyzXu+q/xeXQslT0g7Ed151tIc/kKHYUr2a0r5p2/kDc4V28SbGbJRKr6U5iM7OLcVWeqknBKZ6L7Z8WWcxUxJ7nemhP7B0nWeCMfLGlAYgD6BnIIqeBDE/CV1d/wb0VEhrSKoPFqVD/OxIupI=; X-YMail-OSG: Mh94tboVM1kdaD7TIbJ12nxQS5ipXyEWRrKngnWO23Krt7MsUmhSh3Xvj.38_IOKkE43HA-- Received: from [198.95.226.230] by web38114.mail.mud.yahoo.com via HTTP; Thu, 15 Nov 2007 05:40:38 PST Date: Thu, 15 Nov 2007 05:40:38 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] LAYOUTGET minlength To: "Noveck, Dave" , Benny Halevy , NFSv4 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <236230.58398.qm@web38114.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > I guess I don't have any objection to allowing this to be zero > but I think it is a mistake on the part of client to send this > value as zero or anything below around 64K. What if I have 100 million thumbnail images that are under 64K? Distributing lots of little files is what pNFS is good at, or at least should be good at. The post-Austin rework of the files-based layout and deviceID->device address stuff was done in part to preserve that feature. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 15 08:48: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 1Isf4w-0004n0-4h; Thu, 15 Nov 2007 08:48:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isf4u-0004lk-88 for nfsv4@ietf.org; Thu, 15 Nov 2007 08:48:20 -0500 Received: from web38105.mail.mud.yahoo.com ([209.191.124.132]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Isf4t-00042P-R9 for nfsv4@ietf.org; Thu, 15 Nov 2007 08:48:20 -0500 Received: (qmail 31404 invoked by uid 60001); 15 Nov 2007 13:48:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=UnZPjai4YvbTxaT+rnzQ+r+av8mGeCFOPtIASmGLBvilPNNtdu4fwqkvDM5MxNcVxCPSczEbGonZmIFdInE0+gjTEWREXP4ERfJXVFsxvVNvL7Hi/JjKsxqUgVZlPlKNCx/XFPkhBlcU5JRt0iGPzXt/QWKbrA6XkBmI4X83qvY=; X-YMail-OSG: M4MNQKIVM1k1S1TDFkcaLxA_i9y3yp7iSbipgsV8FURItEg1uoM6EmFV2DZT2H4zd8QlFtNedQ-- Received: from [198.95.226.230] by web38105.mail.mud.yahoo.com via HTTP; Thu, 15 Nov 2007 05:48:19 PST Date: Thu, 15 Nov 2007 05:48:19 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] Question about layout hints & persistent session reply cache To: Bill Baker , nfsv4@ietf.org In-Reply-To: <473A17B0.6040109@Sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <363789.31382.qm@web38105.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Bill Baker wrote: > > Greetings, > > I was reviewing the spec regarding the client's use of > a layout_hint during file creation. The wording in section > 12.5.2 is clear: > > "a metadata server that supports the layout_hint attribute > MUST support a persistent session reply cache" > > This is not consistent with the apparent consensus on the > wg alias, initially raised on 06/20/07, "pNFS: Open issues (from > chapter 12 & 13 reviews)" and then further discussed on 7/16/07. Agreed. I will fix this now. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 15 08:48: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 1Isf56-00057f-Lq; Thu, 15 Nov 2007 08:48:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isf55-00055E-DY for nfsv4@ietf.org; Thu, 15 Nov 2007 08:48:31 -0500 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 1Isf52-00043M-VR for nfsv4@ietf.org; Thu, 15 Nov 2007 08:48:31 -0500 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 lAFDmSvo019689; Thu, 15 Nov 2007 08:48:28 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 15 Nov 2007 08:48:28 -0500 Received: from fs1.bhalevy.com ([172.17.28.115]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 08:48:26 -0500 Message-ID: <473C4E28.7080102@panasas.com> Date: Thu, 15 Nov 2007 15:48:24 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: email2mre-ietf@yahoo.com Subject: Re: [nfsv4] LAYOUTGET minlength References: <143562.67946.qm@web38110.mail.mud.yahoo.com> In-Reply-To: <143562.67946.qm@web38110.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2007 13:48:26.0456 (UTC) FILETIME=[3267C580:01C8278E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Nov. 15, 2007, 15:25 +0200, Mike Eisler wrote: > --- Benny Halevy wrote: > >> Following a discussion we had in the last Bakeathon >> I propose the following wording changes: >> >> 1. Allow zero minlength. >> The motivation is to send an opportunistic LAYOUTGET for >> iomode=open_mode and offset=length=minlength=0 along with OPEN >> so that the server can return an initial layout starting from offset >> 0 >> for which the length doesn't matter, as the client has no bytes to >> read or write at this point. > > Why doesn't minlength=length=1 work? because for writes, you don't want the server to provisionally allocate anything at this point. > > Here's my preference: delete minlength. The text about minlength > and overlap never made any sense. I'm OK with that. But I'd still prefer to require that the returned layout MUST cover the requested offset, i.e.: lo_offset <= loga_offset && lo_offset + lo_length >= loga_offset + ((loga_length != 0) ? 1 : 0); Benny > > >> diff -Npu a/nfsv41_middle_pnfs.xml b/nfsv41_middle_pnfs.xml >> --- a/nfsv41_middle_pnfs.xml >> +++ b/nfsv41_middle_pnfs.xml >> @@ -454,9 +454,8 @@ >> the requested byte range. A field within the LAYOUTGET request, >> loga_minlength, specifies the minimum overlap that MUST exist >> between the requested layout and the layout returned by the >> metadata >> - server. The loga_minlength field should be at least one. As >> needed a >> - client may make multiple LAYOUTGET requests; these will result in >> - multiple overlapping, non-conflicting layouts. >> + server. As needed, a client may make multiple LAYOUTGET requests; >> + these will result in multiple overlapping, non-conflicting >> layouts. >> >> >> There is no required ordering between getting a layout and >> performing >> >> 2. clarify how loga_minlength relates to the requested offset >> There was agreement among the bakeathon participants that the >> minlength >> bytes that the client wants should start from the requested offset >> rather >> than just any minlength bytes in the requested byte-range. >> >> diff -Npu a/nfsv41_middle_op_layoutget.xml >> b/nfsv41_middle_op_layoutget.xml >> --- a/nfsv41_middle_op_layoutget.xml >> +++ b/nfsv41_middle_op_layoutget.xml >> @@ -69,7 +69,8 @@ >> the loga_iomode. The client must be prepared to get a layout >> that does not align exactly with its request. There MUST be at >> least an overlap of loga_minlength between the layout returned >> - by the server and the client's request, or the server SHOULD >> + by the server and the client's request, starting from >> loga_offset >> + to loga_offset + loga_minlength, or the server SHOULD >> reject the request. See >> for >> more details. >> >> >> 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 Thu Nov 15 08:58: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 1IsfEc-0005SY-QF; Thu, 15 Nov 2007 08:58:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsfEb-0005Py-Lu for nfsv4@ietf.org; Thu, 15 Nov 2007 08:58:21 -0500 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 1IsfEb-000526-6g for nfsv4@ietf.org; Thu, 15 Nov 2007 08:58:21 -0500 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 lAFDwKqg019770; Thu, 15 Nov 2007 08:58:20 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 15 Nov 2007 08:58:20 -0500 Received: from fs1.bhalevy.com ([172.17.28.115]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 08:58:20 -0500 Message-ID: <473C507A.2080200@panasas.com> Date: Thu, 15 Nov 2007 15:58:18 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: email2mre-ietf@yahoo.com, "Noveck, Dave" Subject: Re: [nfsv4] Issue in LAYOUTRETURN References: <718630.72051.qm@web38112.mail.mud.yahoo.com> In-Reply-To: <718630.72051.qm@web38112.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2007 13:58:20.0393 (UTC) FILETIME=[946B5D90:01C8278F] 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 On Nov. 15, 2007, 5:36 +0200, Mike Eisler wrote: > --- "Noveck, Dave" wrote: > >> In editing this to deal with another issue, I noted the following: >> >> The server MAY require that the principal, security flavor, and >> applicable, the GSS mechanism, combination that acquired the >> layout also be the one to issue LAYOUTRETURN. This might not be >> possible if credentials for the principal are no longer >> available. The server MAY allow the machine credential or SSV >> credential (see ) to issue >> DELEGRETURN. > ^^^^^^^^^^^^ > > Is DELEGRETURN really meant here, or is it LAYOUTRETURN? It looks like a typo to me. Anyhow I don't understand the motivation for such requirement for LAYOUTRETURN. I'd be happier if the server will be required to allow the machine or SSV creds to issue LAYOUTRETURN and probably also DELEGRETURN as the layout and the delegation may used by the client host for any user. They use OPEN and ACCESS to authenticate and authorize each user but they are not required to get a LAYOUT and/or delegation on each user's behalf. > >> If the client does the former without doing the latter, it is >> going to have a heck of a time doing LAYOUTRETURN_FSID or >> LAYOUTRETURN_ALL. Do we want to say something about this. > > Makes no difference to me. I'm sure some clients will fail to take > advantage of mechanism no matter what we write down. > >> Depending on your interpretation of: >> >> However, >> if it is a subset, the recall is not complete until the full >> recalled scope has been returned. Recalled scope refers to the >> byte range in the case of LAYOUTRETURN4_FILE, use of >> LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. >> >> it may not be possible to respond to LAYOUTRECALL of ALL, if >> the requirement is that the client actually do a completing >> LAYOUTRETURN4_ALL, rather than simply returning each and >> every layout he holds. > > Beats me. This _FILE and _ALL stuff looks quarter baked to me. FWIW, the way I implemented the linux client is that for RECALL FSID or ALL it first returns all layouts in the recalled scope and then it send the corresponding RETURN_FSID or RETURN_ALL that completes the layoutrecall process. At this point the client knows of no file it has a layout for with the recalled layout_type, iomode, and fsid in the RECALL_FSID case. It is possible though that the client threw away such a layout without previously returning it and the "wildcard" return will clean that up also on the server side. 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 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 15 09:07: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 1IsfNX-0000cL-SW; Thu, 15 Nov 2007 09:07:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsfNV-0000Zs-KQ for nfsv4@ietf.org; Thu, 15 Nov 2007 09:07:33 -0500 Received: from web38115.mail.mud.yahoo.com ([209.191.124.142]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsfNV-0005gu-7B for nfsv4@ietf.org; Thu, 15 Nov 2007 09:07:33 -0500 Received: (qmail 24003 invoked by uid 60001); 15 Nov 2007 14:07:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=dp5RwYPy6MmkhzYU8S/jnXYjLZoupLs2nPvNC/nwoNxsfGtCSM09hUwpcyXlyHY3NhuLKYiDGezdIYQQ688epWkDh1UL+esbUQBtTMoiYciVsLT065dZ/9dix762gb+Ybck1GfYbzKy9QmU/EBV4zkGrov3CPaWrBD/ljbJMkM0=; X-YMail-OSG: jMnkOdsVM1lRMbdKJRecZjPDp5D3qDDQoOeC98odJdUWHZcQzpve2Nol2fdO9RB.iexhp5Wh6A-- Received: from [198.95.226.230] by web38115.mail.mud.yahoo.com via HTTP; Thu, 15 Nov 2007 06:07:32 PST Date: Thu, 15 Nov 2007 06:07:32 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] Issue in LAYOUTRETURN To: nfsv4@ietf.org In-Reply-To: <473C507A.2080200@panasas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <657321.23510.qm@web38115.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com 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 Nov. 15, 2007, 5:36 +0200, Mike Eisler > wrote: > > --- "Noveck, Dave" wrote: > > > >> In editing this to deal with another issue, I noted the following: > >> > >> The server MAY require that the principal, security flavor, > and > >> applicable, the GSS mechanism, combination that acquired the > >> layout also be the one to issue LAYOUTRETURN. This might not > be > >> possible if credentials for the principal are no longer > >> available. The server MAY allow the machine credential or SSV > >> credential (see ) to issue > >> DELEGRETURN. > > ^^^^^^^^^^^^ > > > > Is DELEGRETURN really meant here, or is it LAYOUTRETURN? > > It looks like a typo to me. Anyhow I don't understand the motivation Yep. Fixed. > for such requirement for LAYOUTRETURN. I'd be happier if the server Andy a similar question which I responded to. > will be required to allow the machine or SSV creds to issue The protocol does allow the client to ask the server to allow this. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 15 09:17: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 1IsfX7-0006lN-6r; Thu, 15 Nov 2007 09:17:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsfX5-0006cl-J6 for nfsv4@ietf.org; Thu, 15 Nov 2007 09:17:27 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsfX3-0005tF-69 for nfsv4@ietf.org; Thu, 15 Nov 2007 09:17:27 -0500 X-IronPort-AV: E=Sophos;i="4.21,420,1188802800"; d="scan'208";a="122659550" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 15 Nov 2007 06:16:54 -0800 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 lAFEGrBK013365; Thu, 15 Nov 2007 06:16:53 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 06:16:53 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 06:16:53 -0800 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] LAYOUTGET minlength Date: Thu, 15 Nov 2007 09:16:50 -0500 Message-ID: In-Reply-To: <236230.58398.qm@web38114.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] LAYOUTGET minlength Thread-Index: AcgnjSb6kVkrzdobS4i5ofWxPfDTfQABFRzw From: "Noveck, Dave" To: , "Benny Halevy" , "NFSv4" X-OriginalArrivalTime: 15 Nov 2007 14:16:53.0304 (UTC) FILETIME=[2BC41B80:01C82792] X-Spam-Score: -4.0 (----) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 if I have 100 million thumbnail images that are under 64K? Then fine. What's the problem? The layouts tell you where (on what machine) the first 64K of each of those would go, you read them, with appropriate parallelism and everything is OK.=20 -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Thursday, November 15, 2007 8:41 AM To: Noveck, Dave; Benny Halevy; NFSv4 Subject: RE: [nfsv4] LAYOUTGET minlength --- "Noveck, Dave" wrote: > I guess I don't have any objection to allowing this to be zero but I=20 > think it is a mistake on the part of client to send this value as zero > or anything below around 64K. What if I have 100 million thumbnail images that are under 64K? Distributing lots of little files is what pNFS is good at, or at least should be good at. The post-Austin rework of the files-based layout and deviceID->device address stuff was done in part to preserve that feature. _______________________________________________ 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 DeannemphysematousReagan@orgonics.com Thu Nov 15 10:22:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgYT-00062e-Fn; Thu, 15 Nov 2007 10:22:57 -0500 Received: from [190.25.226.198] (helo=internet3) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsgYT-0000iR-2i; Thu, 15 Nov 2007 10:22:57 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host37078317.orgonics.com (8.13.1/8.13.1) with SMTP id B4grjdjd68.955031.VkJ.cie.6738493356227 for ; Thu, 15 Nov 2007 10:22:31 +0500 Message-ID: <1f44e01c8279b$65ab7a10$0500a8c0@internet3> From: "Sharlene Sams" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1F44A_01C8279B.65AB7A10-- From Lizardosyqb@angels-and-demons.com Thu Nov 15 11:26:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshXu-00071C-MC for nfsv4-archive@lists.ietf.org; Thu, 15 Nov 2007 11:26:26 -0500 Received: from [190.161.190.64] (helo=[190.161.190.64]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IshXu-0004Oz-0t for nfsv4-archive@lists.ietf.org; Thu, 15 Nov 2007 11:26:26 -0500 Received: by 10.63.222.183 with SMTP id stZZodslSJnVq; Thu, 15 Nov 2007 13:26:05 -0300 (GMT) Received: by 192.168.226.8 with SMTP id lJLaTpuWjDcomJ.0413062901784; Thu, 15 Nov 2007 13:26:03 -0300 (GMT) Message-ID: <000b01c827a4$35724460$40bea1be@pcc7cc9a9c6f6a> From: "Alexey Lizardo" To: nfsv4-archive@lists.ietf.org Subject: retteshs Date: Thu, 15 Nov 2007 13:26:00 -0300 Message-ID: <000b01c827a4$35724460$40bea1be@pcc7cc9a9c6f6a> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.2 (++++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db they'll keep turning you down until you enlarge your cock Corvaughn azhamriwe http://ailandaj.com/ From some9stephon77@alfa.telenordia.se Thu Nov 15 12:48:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isiov-0004NM-Lj for nfsv4-archive@lists.ietf.org; Thu, 15 Nov 2007 12:48:05 -0500 Received: from [77.46.228.120] (helo=77.46.228.120) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isiou-0000Vw-Mn for nfsv4-archive@lists.ietf.org; Thu, 15 Nov 2007 12:48:05 -0500 Received: from [77.46.228.120] by lvtkn.alfa.telenordia.se; Thu, 15 Nov 2007 17:48:03 +0000 Message-ID: <000901c827af$018ae4f2$23c5dca1@hejui> From: "hoyt kell" To: "Claudette Redmond" Subject: Perfect gift for yourself or a loved one Date: Thu, 15 Nov 2007 16:00:40 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C827AF.0185C327" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C827AF.0185C327 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices!=20 http://popullatrave.net/ ------=_NextPart_000_0006_01C827AF.0185C327 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices! =

http://popullatrave.net/ ------=_NextPart_000_0006_01C827AF.0185C327-- From ElbertdigressZimmerman@peopleenespanol.com Thu Nov 15 14:08:40 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isk4u-0005Tr-0x; Thu, 15 Nov 2007 14:08:40 -0500 Received: from 97.red-81-37-135.dynamicip.rima-tde.net ([81.37.135.97] helo=kamyale) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Isk4t-00042P-4Q; Thu, 15 Nov 2007 14:08:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host29301118.peopleenespanol.com (8.13.1/8.13.1) with SMTP id GSLdO1sC86.075005.IbX.RXw.2243858667922 for ; Thu, 15 Nov 2007 20:07:33 -0100 Message-ID: <1b8f101c827ba$eba50540$2101a8c0@KAMYALE> From: "Rogelio Brock" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1B8ED_01C827BA.EBA50540-- From nfsv4-bounces@ietf.org Thu Nov 15 14:46: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 1IskfR-0002pr-1N; Thu, 15 Nov 2007 14:46:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IskfQ-0002pH-Ce for nfsv4@ietf.org; Thu, 15 Nov 2007 14:46:24 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IskfM-0004Fq-Ve for nfsv4@ietf.org; Thu, 15 Nov 2007 14:46:24 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAFJkKW8008891 for ; Thu, 15 Nov 2007 19:46:20 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRK002019UL4W00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 15 Nov 2007 12:46:20 -0700 (MST) Received: from [192.168.0.4] ([129.150.37.213]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRK00DBDC92GZB0@mail-amer.sun.com>; Thu, 15 Nov 2007 12:46:15 -0700 (MST) Date: Thu, 15 Nov 2007 13:47:00 -0600 From: Spencer Shepler Subject: Re: [nfsv4] LAYOUTGET minlength In-reply-to: <473C4E28.7080102@panasas.com> To: Benny Halevy Message-id: <1F4C8453-A54A-4BA4-B90B-0C8C42F53F2D@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: <143562.67946.qm@web38110.mail.mud.yahoo.com> <473C4E28.7080102@panasas.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: email2mre-ietf@yahoo.com, 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 Nov 15, 2007, at 7:48 AM, Benny Halevy wrote: > On Nov. 15, 2007, 15:25 +0200, Mike Eisler ietf@yahoo.com> wrote: >> --- Benny Halevy wrote: >> >>> Following a discussion we had in the last Bakeathon >>> I propose the following wording changes: >>> >>> 1. Allow zero minlength. >>> The motivation is to send an opportunistic LAYOUTGET for >>> iomode=open_mode and offset=length=minlength=0 along with OPEN >>> so that the server can return an initial layout starting from offset >>> 0 >>> for which the length doesn't matter, as the client has no bytes to >>> read or write at this point. >> >> Why doesn't minlength=length=1 work? > > because for writes, you don't want the server to provisionally > allocate > anything at this point. > >> >> Here's my preference: delete minlength. The text about minlength >> and overlap never made any sense. > > I'm OK with that. > > But I'd still prefer to require that the returned layout MUST cover > the requested offset, i.e.: > lo_offset <= loga_offset && > lo_offset + lo_length >= loga_offset + ((loga_length != 0) ? 1 : 0); Did you intend: lo_offset <= loga_offset && lo_offset + lo_length >= loga_offset + (loga_length != 0) ? loga_length : 1 In other words the returned layout's length must be at least equal to the length originally requested? I am of the opinion that the server should be able to return less that what was requested and this behavior would be useful. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 15 15:06: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 1Iskyf-00008q-2A; Thu, 15 Nov 2007 15:06:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iskye-0008T0-3k for nfsv4@ietf.org; Thu, 15 Nov 2007 15:06:16 -0500 Received: from p01c11o142.mxlogic.net ([208.65.144.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IskyZ-0004wA-NE for nfsv4@ietf.org; Thu, 15 Nov 2007 15:06:15 -0500 Received: from unknown [63.110.244.103] (EHLO us-email.terastack.bluearc.com) by p01c11o142.mxlogic.net (mxl_mta-5.2.0-1) with ESMTP id 3b6ac374.2501725104.217744.00-020.p01c11o142.mxlogic.net (envelope-from ); Thu, 15 Nov 2007 13:06:11 -0700 (MST) 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] pNFS Dense Packing Problem Date: Thu, 15 Nov 2007 12:06:10 -0800 Message-ID: In-Reply-To: <54531.64117.qm@web38110.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] pNFS Dense Packing Problem Thread-Index: AcgnPQLU87QKnFLhQuCKijaw9tl66QAhLjsg References: <54531.64117.qm@web38110.mail.mud.yahoo.com> From: "Anatoly Pinchuk" To: X-Spam: [F=0.0122068372; S=0.012(2007110801)] X-MAIL-FROM: X-SOURCE-IP: [63.110.244.103] X-Spam-Score: -1.0 (-) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 think answers to the following questions might help to decide on a fate of dense packing. - Do we need dense packing at all?=20 - If answer is yes, why would we prefer a client to do the offset translation?=20 - If there is meaning to have the translation in the client, is it possible (difficult) to change the layout structure to make such translation possible?=20 =20 It seems that enough rationale was provided to confirm that dense packing is a valuable feature. Also, there is a reason to keep the translation inside the client since it will offload the server. As for the layout structure, a relative offset field can be added to it and, therefore, data file offset can be calculated. -Anatoly > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf at yahoo.com]=20 > Sent: Wednesday, November 14, 2007 9:19 PM > To: nfsv4 at ietf.org > Subject: [nfsv4] pNFS Dense Packing Problem >=20 > A majority of the editors agree we should remove DENSE packing from > the NFSv4.1 pNFS file layout specification since as Anatoly=20 > points out, > it doesn't work. >=20 > I plan to start ripping it out in a few hours unless someone can > convince us otherwise. > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 15 16:18: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 1Ism6K-0004Sj-R1; Thu, 15 Nov 2007 16:18:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ism6J-0004QU-9l for nfsv4@ietf.org; Thu, 15 Nov 2007 16:18:15 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ism6G-0006vH-Qo for nfsv4@ietf.org; Thu, 15 Nov 2007 16:18:15 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAFLIBhj014775 for ; Thu, 15 Nov 2007 21:18:11 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRK00101EYUY900@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 15 Nov 2007 14:18:11 -0700 (MST) Received: from [192.168.0.4] ([129.150.37.213]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRK00IESGHUOC00@mail-amer.sun.com>; Thu, 15 Nov 2007 14:17:55 -0700 (MST) Date: Thu, 15 Nov 2007 15:18:40 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Issue in LAYOUTRETURN In-reply-to: To: "Noveck, Dave" Message-id: <3C48955F-1896-4AAD-ABDA-05421FBD78DA@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 References: X-Spam-Score: -1.0 (-) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Nov 14, 2007, at 2:55 PM, Noveck, Dave wrote: > In editing this to deal with another issue, I noted the following: > > The server MAY require that the principal, security flavor, and > applicable, the GSS mechanism, combination that acquired the > layout also be the one to issue LAYOUTRETURN. This might not be > possible if credentials for the principal are no longer > available. The server MAY allow the machine credential or SSV > credential (see ) to issue > DELEGRETURN. > > If the client does the former without doing the latter, it is > going to have a heck of a time doing LAYOUTRETURN_FSID or > LAYOUTRETURN_ALL. Do we want to say something about this. > > Depending on your interpretation of: > > However, > if it is a subset, the recall is not complete until the full > recalled scope has been returned. Recalled scope refers to the > byte range in the case of LAYOUTRETURN4_FILE, use of > LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. > > it may not be possible to respond to LAYOUTRECALL of ALL, if > the requirement is that the client actually do a completing > LAYOUTRETURN4_ALL, rather than simply returning each and > every layout he holds. I would prefer that we view the "FSID" and "ALL" variants of the recall and return processing as a shorthand reference to the individual layout detail. Therefore, if the server does a recall of "ALL", then the client can return the individual layouts or it can to the return of "ALL". Conversely, if the server recalls an individual layout, the client can do a return of "ALL" and have it satisfy the recall processing. Half-baked??. It seems valuable to a client in the event of a client dealing with an unmount of a filesystem or shutdown of the system. Of course, we don't have a corresponding CLOSE("ALL) or DELEGRETURN("ALL) so maybe that would argue that without the symmetry the feature isn't needed and may lead to lazy/broken client implementations. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 15 16:28: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 1IsmG1-0006ZQ-7o; Thu, 15 Nov 2007 16:28:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsmDa-0003ds-Fb for nfsv4@ietf.org; Thu, 15 Nov 2007 16:25:46 -0500 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsmDa-0000ac-3p for nfsv4@ietf.org; Thu, 15 Nov 2007 16:25:46 -0500 Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IsmDY-0004am-CN; Thu, 15 Nov 2007 22:25:44 +0100 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx9.uio.no) by mail-mx9.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IsmDY-0004Mx-2t; Thu, 15 Nov 2007 22:25:44 +0100 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx9.uio.no with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IsmDX-0004MI-Iz; Thu, 15 Nov 2007 22:25:43 +0100 Subject: Re: [nfsv4] Issue in LAYOUTRETURN From: Trond Myklebust To: Spencer Shepler In-Reply-To: <3C48955F-1896-4AAD-ABDA-05421FBD78DA@sun.com> References: <3C48955F-1896-4AAD-ABDA-05421FBD78DA@sun.com> Content-Type: text/plain Date: Thu, 15 Nov 2007 16:25:42 -0500 Message-Id: <1195161942.8905.52.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.2, required=12.0, autolearn=disabled, AWL=-0.194) X-UiO-Scanned: B2C77CAC85E5224B46B5D4E772687396F3E4C4DA X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -1 maxlevel 200 minaction 2 bait 0 mail/h: 383 total 5162530 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Thu, 2007-11-15 at 15:18 -0600, Spencer Shepler wrote: > Half-baked??. It seems valuable to a client in the event of > a client dealing with an unmount of a filesystem or shutdown > of the system. Of course, we don't have a corresponding > CLOSE("ALL) or DELEGRETURN("ALL) so maybe that would argue > that without the symmetry the feature isn't needed and may > lead to lazy/broken client implementations. Delegations aren't necessarily tied to user open state. There is value for a client to keep holding delegations to often-used files (for instance shared libraries) even if nobody happens to have a file open at the moment. For such cases, being able to issue a single return at umount is valuable; particularly so for read delegations, where there is no dirty state to worry about. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 15 16:28: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 1IsmGT-0006xH-16; Thu, 15 Nov 2007 16:28:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsmGR-0006vp-9Q for nfsv4@ietf.org; Thu, 15 Nov 2007 16:28:43 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsmGQ-0000g4-HZ for nfsv4@ietf.org; Thu, 15 Nov 2007 16:28:43 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAFLSguM020396 for ; Thu, 15 Nov 2007 21:28:42 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRK00C01GWNFE00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Thu, 15 Nov 2007 14:28:42 -0700 (MST) Received: from [192.168.0.4] ([129.150.37.213]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRK00ILGGZTOC00@mail-amer.sun.com>; Thu, 15 Nov 2007 14:28:41 -0700 (MST) Date: Thu, 15 Nov 2007 15:29:28 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Issue in LAYOUTRETURN In-reply-to: <1195161942.8905.52.camel@heimdal.trondhjem.org> To: Trond Myklebust Message-id: <8DB03B29-9BEF-4C56-9901-5F8275655733@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: <3C48955F-1896-4AAD-ABDA-05421FBD78DA@sun.com> <1195161942.8905.52.camel@heimdal.trondhjem.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Nov 15, 2007, at 3:25 PM, Trond Myklebust wrote: > > On Thu, 2007-11-15 at 15:18 -0600, Spencer Shepler wrote: >> Half-baked??. It seems valuable to a client in the event of >> a client dealing with an unmount of a filesystem or shutdown >> of the system. Of course, we don't have a corresponding >> CLOSE("ALL) or DELEGRETURN("ALL) so maybe that would argue >> that without the symmetry the feature isn't needed and may >> lead to lazy/broken client implementations. > > Delegations aren't necessarily tied to user open state. There is value > for a client to keep holding delegations to often-used files (for > instance shared libraries) even if nobody happens to have a file > open at > the moment. For such cases, being able to issue a single return at > umount is valuable; particularly so for read delegations, where > there is > no dirty state to worry about. One could argue that a SETCLIENTID or EXCHANGE_ID is a method of exacting that DELEGRETURN. :-) Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 15 16:32: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 1IsmJm-0008Jz-S9; Thu, 15 Nov 2007 16:32:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsmJl-0008Iv-Cu for nfsv4@ietf.org; Thu, 15 Nov 2007 16:32:09 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsmJf-0007Zo-Vd for nfsv4@ietf.org; Thu, 15 Nov 2007 16:32:09 -0500 Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IsmJe-0006YI-MZ; Thu, 15 Nov 2007 22:32:02 +0100 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 1IsmJe-00066n-EL; Thu, 15 Nov 2007 22:32:02 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IsmJe-00066W-1D; Thu, 15 Nov 2007 22:32:02 +0100 Subject: Re: [nfsv4] Issue in LAYOUTRETURN From: Trond Myklebust To: Spencer Shepler In-Reply-To: <8DB03B29-9BEF-4C56-9901-5F8275655733@Sun.COM> References: <3C48955F-1896-4AAD-ABDA-05421FBD78DA@sun.com> <1195161942.8905.52.camel@heimdal.trondhjem.org> <8DB03B29-9BEF-4C56-9901-5F8275655733@Sun.COM> Content-Type: text/plain Date: Thu, 15 Nov 2007 16:32:00 -0500 Message-Id: <1195162320.8905.55.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.2, required=12.0, autolearn=disabled, AWL=-0.175) X-UiO-Scanned: BBE2DAFD42CB4FC0259D552A596D59CD7186113E X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -1 maxlevel 200 minaction 2 bait 0 mail/h: 457 total 5162604 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Thu, 2007-11-15 at 15:29 -0600, Spencer Shepler wrote: > One could argue that a SETCLIENTID or EXCHANGE_ID is a method of > exacting that DELEGRETURN. :-) Only if you're prepared to set up one clientid per filesystem you mount. :-) Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 15 16:47: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 1IsmY9-0008La-5E; Thu, 15 Nov 2007 16:47:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsmY7-0008EZ-Fy for nfsv4@ietf.org; Thu, 15 Nov 2007 16:46:59 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsmY4-0007yc-TE for nfsv4@ietf.org; Thu, 15 Nov 2007 16:46:59 -0500 X-IronPort-AV: E=Sophos;i="4.21,422,1188802800"; d="scan'208";a="122814853" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 15 Nov 2007 13:46:41 -0800 Received: from sacexrs02.hq.netapp.com (sacexrs02.hq.netapp.com [10.99.190.106]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id lAFLke40012667; Thu, 15 Nov 2007 13:46:40 -0800 (PST) Received: from SACEXMV01.hq.netapp.com ([10.99.190.107]) by sacexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 13:46:40 -0800 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] pNFS Dense Packing Problem Date: Thu, 15 Nov 2007 13:46:39 -0800 Message-ID: <01AE8AF878612047A442668306EAEB05013919B9@SACEXMV01.hq.netapp.com> In-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] pNFS Dense Packing Problem Thread-Index: AcgnPQLU87QKnFLhQuCKijaw9tl66QAhLjsgAALr3jA= References: <54531.64117.qm@web38110.mail.mud.yahoo.com> From: "Muntz, Daniel" To: "Anatoly Pinchuk" , X-OriginalArrivalTime: 15 Nov 2007 21:46:40.0507 (UTC) FILETIME=[01647CB0:01C827D1] X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Who wants multiple stripe unit sizes and what are they doing with them? One thing that comes to mind is perhaps mixed stripe sizes are being used as an analogue to extents in physical file systems (or perhaps to directly map to extents, or similar structures, in an underlying physical fs on the DS). Other mixed stripe size applications could be implemented as a fixed "base" stripe size, and an appropriate application of the layout mechanism to create stripe groups to emulate mixed stripe sizes (with the restriction that the possible "stripe sizes" are multiples of the "base stripe size"). I get the impression that the multiple stripe size stuff is, to quote Eisler on an unrelated topic, "1/4 baked." If including them has provably broken a relatively simple part of the pNFS protocol, what else are we going to hit in more complex areas (locking, restriping, replicas, ...)? Are there white-papers, or research demonstrating the benefit outweighs the complexity and overhead introduced? Is this a 90/10 situation (or a 99.999/.001) where a huge percentage of users would be just as well off with a fixed stripe size? W.r.t. dense packing, even _if_ the fs gets the hole-making correct in the first place, there are always opportunities for holes to become allocated disk blocks. Perhaps support for multiple stripe sizes could be OPTIONAL on the client. It's an ugly thought, but then the market can decide. Clients that don't support them can read/write through the MDS, or the server could hide multiple stripe sizes from these clients (now _there's_ some added complexity on the server side... :-) -Dan -----Original Message----- From: Anatoly Pinchuk [mailto:apinchuk@bluearc.com]=20 Sent: Thursday, November 15, 2007 12:06 PM To: nfsv4@ietf.org Subject: RE: [nfsv4] pNFS Dense Packing Problem I think answers to the following questions might help to decide on a fate of dense packing. - Do we need dense packing at all?=20 - If answer is yes, why would we prefer a client to do the offset translation?=20 - If there is meaning to have the translation in the client, is it possible (difficult) to change the layout structure to make such translation possible?=20 =20 It seems that enough rationale was provided to confirm that dense packing is a valuable feature. Also, there is a reason to keep the translation inside the client since it will offload the server. As for the layout structure, a relative offset field can be added to it and, therefore, data file offset can be calculated. -Anatoly > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf at yahoo.com] > Sent: Wednesday, November 14, 2007 9:19 PM > To: nfsv4 at ietf.org > Subject: [nfsv4] pNFS Dense Packing Problem >=20 > A majority of the editors agree we should remove DENSE packing from=20 > the NFSv4.1 pNFS file layout specification since as Anatoly points=20 > out, it doesn't work. >=20 > I plan to start ripping it out in a few hours unless someone can=20 > convince us otherwise. > _______________________________________________ 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 Nov 15 17:23: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 1Isn7Q-0006mY-3j; Thu, 15 Nov 2007 17:23:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isn7O-0006m0-6R for nfsv4@ietf.org; Thu, 15 Nov 2007 17:23:26 -0500 Received: from p01c11o144.mxlogic.net ([208.65.144.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isn7J-0000oH-9F for nfsv4@ietf.org; Thu, 15 Nov 2007 17:23:26 -0500 Received: from unknown [63.110.244.103] (EHLO p01c11o144.mxlogic.net) by p01c11o144.mxlogic.net (mxl_mta-5.2.0-1) with ESMTP id 9d6cc374.1790245808.248932.00-503.p01c11o144.mxlogic.net (envelope-from ); Thu, 15 Nov 2007 15:23:21 -0700 (MST) Received: from unknown [63.110.244.103] by p01c11o144.mxlogic.net (mxl_mta-5.2.0-1) with SMTP id 7d6cc374.2241309616.248846.00-008.p01c11o144.mxlogic.net (envelope-from ); Thu, 15 Nov 2007 15:23:19 -0700 (MST) 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] pNFS Dense Packing Problem Date: Thu, 15 Nov 2007 14:22:56 -0800 Message-ID: In-Reply-To: <01AE8AF878612047A442668306EAEB05013919B9@SACEXMV01.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] pNFS Dense Packing Problem Thread-Index: AcgnPQLU87QKnFLhQuCKijaw9tl66QAhLjsgAALr3jAAAUNNIA== References: <54531.64117.qm@web38110.mail.mud.yahoo.com> <01AE8AF878612047A442668306EAEB05013919B9@SACEXMV01.hq.netapp.com> From: "Anatoly Pinchuk" To: "Muntz, Daniel" , X-Spam: [F=0.0100000000; S=0.010(2007110801)] X-MAIL-FROM: X-SOURCE-IP: [63.110.244.103] X-Spam-Score: -1.0 (-) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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 Multiple stripe unit sizes can be utilized in some server implementations. Also, probably, it is not so difficult to support. Real problem though is not multiple stripe unit sizes (I just used them to provide example) but inability of a client to correctly translate offset in case of dense packing and more than one layout per client file. In other words, if we say that all stripe unit sizes are equal, problem does not go away. -Anatoly -----Original Message----- From: Muntz, Daniel [mailto:Dan.Muntz@netapp.com]=20 Sent: Thursday, November 15, 2007 1:47 PM To: Anatoly Pinchuk; nfsv4@ietf.org Subject: RE: [nfsv4] pNFS Dense Packing Problem Who wants multiple stripe unit sizes and what are they doing with them? One thing that comes to mind is perhaps mixed stripe sizes are being used as an analogue to extents in physical file systems (or perhaps to directly map to extents, or similar structures, in an underlying physical fs on the DS). Other mixed stripe size applications could be implemented as a fixed "base" stripe size, and an appropriate application of the layout mechanism to create stripe groups to emulate mixed stripe sizes (with the restriction that the possible "stripe sizes" are multiples of the "base stripe size"). I get the impression that the multiple stripe size stuff is, to quote Eisler on an unrelated topic, "1/4 baked." If including them has provably broken a relatively simple part of the pNFS protocol, what else are we going to hit in more complex areas (locking, restriping, replicas, ...)? Are there white-papers, or research demonstrating the benefit outweighs the complexity and overhead introduced? Is this a 90/10 situation (or a 99.999/.001) where a huge percentage of users would be just as well off with a fixed stripe size? W.r.t. dense packing, even _if_ the fs gets the hole-making correct in the first place, there are always opportunities for holes to become allocated disk blocks. Perhaps support for multiple stripe sizes could be OPTIONAL on the client. It's an ugly thought, but then the market can decide. Clients that don't support them can read/write through the MDS, or the server could hide multiple stripe sizes from these clients (now _there's_ some added complexity on the server side... :-) -Dan -----Original Message----- From: Anatoly Pinchuk [mailto:apinchuk@bluearc.com]=20 Sent: Thursday, November 15, 2007 12:06 PM To: nfsv4@ietf.org Subject: RE: [nfsv4] pNFS Dense Packing Problem I think answers to the following questions might help to decide on a fate of dense packing. - Do we need dense packing at all?=20 - If answer is yes, why would we prefer a client to do the offset translation?=20 - If there is meaning to have the translation in the client, is it possible (difficult) to change the layout structure to make such translation possible?=20 =20 It seems that enough rationale was provided to confirm that dense packing is a valuable feature. Also, there is a reason to keep the translation inside the client since it will offload the server. As for the layout structure, a relative offset field can be added to it and, therefore, data file offset can be calculated. -Anatoly > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf at yahoo.com] > Sent: Wednesday, November 14, 2007 9:19 PM > To: nfsv4 at ietf.org > Subject: [nfsv4] pNFS Dense Packing Problem >=20 > A majority of the editors agree we should remove DENSE packing from=20 > the NFSv4.1 pNFS file layout specification since as Anatoly points=20 > out, it doesn't work. >=20 > I plan to start ripping it out in a few hours unless someone can=20 > convince us otherwise. > _______________________________________________ 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 Nov 15 22:23: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 1Isrnz-0002Bj-Ts; Thu, 15 Nov 2007 22:23:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isrnx-00025K-Ji for nfsv4@ietf.org; Thu, 15 Nov 2007 22:23:41 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isrnt-0002ed-4C for nfsv4@ietf.org; Thu, 15 Nov 2007 22:23:41 -0500 X-IronPort-AV: E=Sophos;i="4.21,423,1188802800"; d="scan'208";a="122897195" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 15 Nov 2007 19:23:21 -0800 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 lAG3NLgn020488; Thu, 15 Nov 2007 19:23:21 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 19:23:20 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 19:23:20 -0800 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] Issue in LAYOUTRETURN Date: Thu, 15 Nov 2007 22:23:18 -0500 Message-ID: In-Reply-To: <1195162320.8905.55.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Issue in LAYOUTRETURN Thread-Index: AcgnzwLh+oOcpJugTYO4ZO+Ma7bxdwAMNimg From: "Noveck, Dave" To: "Trond Myklebust" , "Spencer Shepler" X-OriginalArrivalTime: 16 Nov 2007 03:23:20.0535 (UTC) FILETIME=[098C2670:01C82800] X-Spam-Score: -4.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 And you're prepared to close all files, release all byte-range locks, at the same time. =20 -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Thursday, November 15, 2007 4:32 PM To: Spencer Shepler Cc: Noveck, Dave; nfsv4@ietf.org Subject: Re: [nfsv4] Issue in LAYOUTRETURN On Thu, 2007-11-15 at 15:29 -0600, Spencer Shepler wrote: > One could argue that a SETCLIENTID or EXCHANGE_ID is a method of=20 > exacting that DELEGRETURN. :-) Only if you're prepared to set up one clientid per filesystem you mount. :-) 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 AidaberraBurgos@wikipedia.org Thu Nov 15 23:17:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsseK-0001RM-JD; Thu, 15 Nov 2007 23:17:48 -0500 Received: from 201.160.230.216.cable.dyn.cableonline.com.mx ([201.160.230.216] helo=desktop.cpe.tij.cablemas.com.mx) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsseK-00008U-5E; Thu, 15 Nov 2007 23:17:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host96887618.wikipedia.org (8.13.1/8.13.1) with SMTP id azAxPuoS76.149661.00t.vpm.6061731863387 for ; Thu, 15 Nov 2007 20:17:03 +0800 Message-ID: <1f52e01c82807$9abe1610$d8e6a0c9@desktop> From: "Josie Trotter" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1F52A_01C82807.9ABE1610-- From LatishacavilClinton@canon-europe.com Fri Nov 16 00:41:31 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IstxL-0004YC-IS; Fri, 16 Nov 2007 00:41:31 -0500 Received: from pool-72-76-198-148.nwrknj.east.verizon.net ([72.76.198.148] helo=crystaltaylor.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IstxK-0005kq-V1; Fri, 16 Nov 2007 00:41:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host99091770.canon-europe.com (8.13.1/8.13.1) with SMTP id 1G3RC9gq95.395093.N0i.ovl.2092161704039 for ; Fri, 16 Nov 2007 00:41:05 +0500 Message-ID: <4a78701c82813$563cbd50$2f01a8c0@crystaltaylor> From: "Eliza Christie" To: Subject: Your life Date: Fri, 16 Nov 2007 00:41:05 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_4A783_01C82813.563CBD50" 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: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_4A783_01C82813.563CBD50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_4A783_01C82813.563CBD50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_4A783_01C82813.563CBD50-- From nfsv4-bounces@ietf.org Fri Nov 16 01:51: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 1Isv3K-0006eO-Qs; Fri, 16 Nov 2007 01:51:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isv3J-0006b4-W1 for nfsv4@ietf.org; Fri, 16 Nov 2007 01:51:46 -0500 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 1Isv3J-0000mh-E2 for nfsv4@ietf.org; Fri, 16 Nov 2007 01:51:45 -0500 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 lAG6pdZd010108; Fri, 16 Nov 2007 01:51:40 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 16 Nov 2007 01:51:39 -0500 Received: from fs1.bhalevy.com ([172.17.28.115]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Nov 2007 01:51:39 -0500 Message-ID: <473D3DFA.2070407@panasas.com> Date: Fri, 16 Nov 2007 08:51:38 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Spencer Shepler Subject: Re: [nfsv4] LAYOUTGET minlength References: <143562.67946.qm@web38110.mail.mud.yahoo.com> <473C4E28.7080102@panasas.com> <1F4C8453-A54A-4BA4-B90B-0C8C42F53F2D@sun.com> In-Reply-To: <1F4C8453-A54A-4BA4-B90B-0C8C42F53F2D@sun.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2007 06:51:39.0819 (UTC) FILETIME=[23B387B0:01C8281D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: email2mre-ietf@yahoo.com, 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 Nov. 15, 2007, 21:47 +0200, Spencer Shepler wrote: > On Nov 15, 2007, at 7:48 AM, Benny Halevy wrote: > >> On Nov. 15, 2007, 15:25 +0200, Mike Eisler > ietf@yahoo.com> wrote: >>> --- Benny Halevy wrote: >>> >>>> Following a discussion we had in the last Bakeathon >>>> I propose the following wording changes: >>>> >>>> 1. Allow zero minlength. >>>> The motivation is to send an opportunistic LAYOUTGET for >>>> iomode=open_mode and offset=length=minlength=0 along with OPEN >>>> so that the server can return an initial layout starting from offset >>>> 0 >>>> for which the length doesn't matter, as the client has no bytes to >>>> read or write at this point. >>> Why doesn't minlength=length=1 work? >> because for writes, you don't want the server to provisionally >> allocate >> anything at this point. >> >>> Here's my preference: delete minlength. The text about minlength >>> and overlap never made any sense. >> I'm OK with that. >> >> But I'd still prefer to require that the returned layout MUST cover >> the requested offset, i.e.: >> lo_offset <= loga_offset && >> lo_offset + lo_length >= loga_offset + ((loga_length != 0) ? 1 : 0); > > Did you intend: > > lo_offset <= loga_offset && > lo_offset + lo_length >= loga_offset + (loga_length != 0) ? > loga_length : 1 > > In other words the returned layout's length must be at least > equal to the length originally requested? No, that's not always possible for the server. The requirement above is just the minimum the server must return (in the success case). I should probably have stated that as "The returned layout MUST cover the requested offset and at least one more byte if loga_length is greater than zero" > > I am of the opinion that the server should be able to > return less that what was requested and this behavior > would be useful. Ditto. To make forward progress the client must be prepared to get less than what it requested. My rational for: lo_offset + lo_length >= loga_offset + ((loga_length != 0) ? 1 : 0); if if the client indicated a loga_length != 0 then the server should return a layout covering at least 1 byte after loga_offset, to allow forward progress (of course 1 byte is not very practical in most case and I count on servers to do a better job if they want to survive :) otherwise, if loga_length was zero, the server MAY return a layout describing the file only at offset == loga_offset. > > Spencer > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From MariettarecentParra@williecrawford.com Fri Nov 16 02:15:46 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsvQY-0002bz-Az; Fri, 16 Nov 2007 02:15:46 -0500 Received: from pc-98-94-83-200.cm.vtr.net ([200.83.94.98] helo=via92dnetq7mkt) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsvQX-00022W-9K; Fri, 16 Nov 2007 02:15:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host42414030.williecrawford.com (8.13.1/8.13.1) with SMTP id SyPDOs6T81.304807.7yP.Cyj.3949406322210 for ; Fri, 16 Nov 2007 04:14:50 +0400 Message-ID: <36a0a01c82820$822d23c0$625e53c8@via92dnetq7mkt> From: "Leonor Herrington" To: Subject: Your order Date: Fri, 16 Nov 2007 04:14:50 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_36A06_01C82820.822D23C0" 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: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_36A06_01C82820.822D23C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_36A06_01C82820.822D23C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_36A06_01C82820.822D23C0-- From NicholasorthodoxySanders@gasupreme.us Fri Nov 16 03:44:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IswoO-00045m-Ct; Fri, 16 Nov 2007 03:44:28 -0500 Received: from 207-255-53-013-dhcp.jst.pa.atlanticbb.net ([207.255.53.13] helo=mates) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IswoO-0007CB-2V; Fri, 16 Nov 2007 03:44:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host57836480.gasupreme.us (8.13.1/8.13.1) with SMTP id HdHvM5oS10.609024.V3P.xWZ.2123630102579 for ; Fri, 16 Nov 2007 03:43:58 +0500 Message-ID: <7b02501c8282c$e3aff210$42c6fea9@mates> From: "Roy Howard" To: Subject: Your health Date: Fri, 16 Nov 2007 03:43:58 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_7B021_01C8282C.E3AFF210" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_7B021_01C8282C.E3AFF210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_7B021_01C8282C.E3AFF210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_7B021_01C8282C.E3AFF210-- From Pyaebjn@panozzogroup.com Fri Nov 16 04:35:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isxbv-0004z8-Sq for nfsv4-archive@lists.ietf.org; Fri, 16 Nov 2007 04:35:39 -0500 Received: from [201.29.95.212] (helo=20151233179.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isxbv-0001uD-8B for nfsv4-archive@lists.ietf.org; Fri, 16 Nov 2007 04:35:39 -0500 Received: from ESCRITORIO ([110.118.105.97] helo=ESCRITORIO) by 20151233179.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1dMspn-000TIN-BK for nfsv4-archive@lists.ietf.org; Fri, 16 Nov 2007 07:35:48 -0200 Message-ID: <000a01c82834$0b8bc960$b3e933c9@ESCRITORIO> From: "Mrugesh Pyae" To: nfsv4-archive@lists.ietf.org Subject: tkark Date: Fri, 16 Nov 2007 07:35:37 -0200 Message-ID: <000a01c82834$0b8bc960$b3e933c9@ESCRITORIO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db No girls laugh at me now, haha, i laugh at them Juraj Schlader http://www.battx.com/ From nfsv4-bounces@ietf.org Fri Nov 16 05:36: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 1IsyZ0-0005ou-J6; Fri, 16 Nov 2007 05:36:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsyYz-0005ni-Jn for nfsv4@ietf.org; Fri, 16 Nov 2007 05:36:41 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsyYw-0001Cb-SR for nfsv4@ietf.org; Fri, 16 Nov 2007 05:36:41 -0500 X-IronPort-AV: E=Sophos;i="4.21,425,1188802800"; d="scan'208";a="122971999" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 16 Nov 2007 02:36:38 -0800 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 lAGAZhdY010567; Fri, 16 Nov 2007 02:36:37 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 02:22:55 -0800 Received: from exsvl03.hq.netapp.com ([10.56.8.64]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 17:25:51 -0800 Received: from [10.34.24.132] ([10.34.24.132]) by exsvl03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 17:25:51 -0800 Message-ID: <473CF19F.5030102@netapp.com> Date: Thu, 15 Nov 2007 17:25:51 -0800 From: Garth Goodson User-Agent: Icedove 1.5.0.12 (X11/20070730) MIME-Version: 1.0 To: email2mre-ietf@yahoo.com Subject: Re: [nfsv4] pNFS Dense Packing Problem References: <391282.29333.qm@web38115.mail.mud.yahoo.com> In-Reply-To: <391282.29333.qm@web38115.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2007 01:25:51.0779 (UTC) FILETIME=[A0295730:01C827EF] X-Spam-Score: -4.0 (----) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 Mike Eisler wrote: > A majority of the editors agree we should remove DENSE packing from > the NFSv4.1 pNFS file layout specification since as Anatoly points out, > it doesn't work. > > I plan to start ripping it out in a few hours unless someone can > convince us otherwise. > Granted I haven't paid as much attention to the new layout structure, but when it was defined previously it wasn't a problem to support most of these options, with one exception described below. If you wanted to use different stripe units for different sections of the file you would get different layouts that covered those portions. As long as the FHs were different you could even use DENSE and SPARSE layouts on different portions of the file and this may be true today as well. The one exception (with the old layout scheme) is that you couldn't have different stripe widths for data servers covered by the same layout. We felt this a reasonable compromise. I'm guessing that the motivation to support this is to be able to offload more work to some servers and less to others which may be useful in some heterogeneous storage environments. It seems that the new layout scheme isn't the end-all solution we were hoping for. However, at some point the layout definition will need to stop changing -- we won't ever agree on all the changes it requires to support everyone's needs, and I'm afraid it just becomes more complicated with minimal returns... As far as I recall, the IBM GPFS guys wanted dense layouts as that is how GPFS stores the data. Using either DENSE layouts or converting SPARSE to DENSE on the data server requires full knowledge of the layout, so this shouldn't be a major stumbling block. Maybe Marc Eshel can weigh in. -Garth > --- Mike Eisler wrote: > >> --- Anatoly Pinchuk wrote: >> >> >>> --- Anatoly Pinchuk wrote: >>> >>>> 1. If the client file layouts can have different stripe unit >> sizes >>> we >>>> need more than just a text clarification. In that case the layout >>>> structure should include additional information to calculate a >> data >>>> file offset for dense packing. Offset returned in layout4 >> structure >>>> and stripe unit size is not enough to do the calculation. Here is >>> an >>>> example: >>>> >>>> There are devices: >>>> struct nfsv4_1_file_layout_ds_addr4 >>>> dev0 = { // ID is 0 >>>> {0}, >>>> {{A}} >>>> }, >>>> dev1 = { // ID is 1 >>>> {0}, >>>> {{B}} >>>> }; >>>> >>>> File Layouts for a client file >>>> struct nfsv4_1_file_layout4 >>>> fl0 = { >>>> 0, >> deviceID 0 >> >>>> x, // stripe unit size of 0x400 is coded with x >>>> 0, >>>> fh0 >>>> }, >>>> fl1 = { >>>> 1, >> deviceID 1 >>>> y, // stripe unit size of 0x1000 and dense packing are coded >>> with >>>> y >>>> 0, >>>> fh1 >>>> }; >>>> >>>> fl0 and fl1 correspond to file ranges [0, 0x400-1] and [0x400, >>>> 0x1400-1]; >>>> >>>> Now a client requests layout for an offset of 0x800 and length >>> 0x400 >>>> and the reply is: >>>> >>>> struct layout4 >>>> lo = { >>>> 0x800, >> offset 0x800 >> >>>> 0x400, >>>> lo_iomode, // some IO mode >>>> lo_content // see below >>>> }; >>>> >>>> struct layout_content4 >>>> lo_content = { >>>> LAYOUT4_NFSV4_1_FILES, >>>> loc_body // see below >>>> }; >>>> loc_body contains fl1 defined above. >>>> >>>> So, the client knows the server (B) and the file handle (fh1) to >> do >>>> IO on. Offset for the fh1 is needed as well. The formula from >>>> paragraph 14.5 does not provide correct offset since >>>> >>>> data_file_offset = floor(file_offset / stripe_width) >>>> * stripe_unit_size + file_offset % stripe_unit_size = >>>> floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 = 0x800; >>>> >>>> and the correct offset is >>>> >>>> rel_off = (file_offset - layout_offset) = (0x800 - 0x400) = >> 0x400; >>>> data_file_offset = floor(rel_offset / stripe_width) >>>> * stripe_unit_size + rel_offset % stripe_unit_size = >>>> floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 = 0x400; >> Unless fh1 and fh0 are the same. >> >> This is a big problem and I don't have an immediate >> answer other than to suggest we remove dense >> packing from the protocol and rely on data server intelligence >> to pack stripe units. >> >> >> > > > _______________________________________________ > 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 Nov 16 05:46: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 1IsyiT-0000aN-FP; Fri, 16 Nov 2007 05:46:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsyiR-0000UT-WA for nfsv4@ietf.org; Fri, 16 Nov 2007 05:46:28 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsyiO-0001eI-K8 for nfsv4@ietf.org; Fri, 16 Nov 2007 05:46:27 -0500 X-IronPort-AV: E=Sophos;i="4.21,425,1188802800"; d="scan'208";a="122974510" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 16 Nov 2007 02:46:23 -0800 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 lAGAk6TV016144; Fri, 16 Nov 2007 02:46:14 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 02:28:59 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 06:39:48 -0800 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] draft-ietf-nfsv4-minorversion1-16 LAYOUTRETURN question Date: Thu, 15 Nov 2007 09:39:47 -0500 Message-ID: In-Reply-To: <89c397150711140921p72368255s7c9076be9fa4aae5@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] draft-ietf-nfsv4-minorversion1-16 LAYOUTRETURN question Thread-Index: Acgm4u6UBjb5F1ZORAmNVwrDQFrIHAAsjVNQ From: "Noveck, Dave" To: "William A. \(Andy\) Adamson" , "NFSv4" X-OriginalArrivalTime: 15 Nov 2007 14:39:48.0950 (UTC) FILETIME=[5FB70760:01C82795] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 If you want to run your server so "nobody" can return layouts that were gotten on your behalf, then the protocol allows you=20 to. But some people might want to restrict that and the protocol allows them to do that.=20 -----Original Message----- From: William A. (Andy) Adamson [mailto:andros@citi.umich.edu]=20 Sent: Wednesday, November 14, 2007 12:21 PM To: NFSv4 Subject: [nfsv4] draft-ietf-nfsv4-minorversion1-16 LAYOUTRETURN question Sorry if I missed the discussion on this point. The last paragraph of section 18.44.3 (LAYOUTRETURN) draft-ietf-nfsv4-minorversion1-16.txt: The server MAY require that the principal, security flavor, and applicable, the GSS mechanism, combination that acquired the layout also be the one to issue LAYOUTRETURN. his might not be possible if credentials for the principal are no longer available. The server MAY allow the machine credential or SSV credential (see Section 18.35) to issue DELEGRETURN. Why is it allowed for a client-wide layout to be attached to a user? This paragraph suggests that the layout is somehow attached to user credentials. The layout, and therefore the layoutreturn, is of client scope and so any user credentials should be acceptable to any pnfs server. Also. Why is it that the pNFS server is not required to allow machine credentials?!?!? -->Andy _______________________________________________ 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 WilfordindicateHebert@closer.com Fri Nov 16 09:27:02 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It29u-0007Gn-91; Fri, 16 Nov 2007 09:27:02 -0500 Received: from 239.red-83-45-50.dynamicip.rima-tde.net ([83.45.50.239] helo=b40f032be01449a) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1It29t-0003ZS-P2; Fri, 16 Nov 2007 09:27:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host54371657.closer.com (8.13.1/8.13.1) with SMTP id 5syteBfW87.239116.bWS.9fA.0560773894367 for ; Fri, 16 Nov 2007 10:26:28 +0500 Message-ID: <2b3a01c82865$1d7c6a40$808afea9@B40F032BE01449A> From: "Dalton Hendricks" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_2B36_01C82865.1D7C6A40-- From nfsv4-bounces@ietf.org Fri Nov 16 10:25: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 1It348-0005WL-Bv; Fri, 16 Nov 2007 10:25:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It347-0005VM-FE for nfsv4@ietf.org; Fri, 16 Nov 2007 10:25:07 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It343-00038V-My for nfsv4@ietf.org; Fri, 16 Nov 2007 10:25:07 -0500 X-IronPort-AV: E=Sophos;i="4.21,426,1188802800"; d="scan'208";a="123041462" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 16 Nov 2007 07:24:51 -0800 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 lAGFO3JS006253; Fri, 16 Nov 2007 07:24:50 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 07:24:45 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 07:24:45 -0800 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] LAYOUTGET minlength Date: Fri, 16 Nov 2007 10:24:44 -0500 Message-ID: In-Reply-To: <473D3DFA.2070407@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] LAYOUTGET minlength Thread-Index: AcgoPCnJaPv1Ks0nQQmtbhON1m9YpwAJkoBw From: "Noveck, Dave" To: "Benny Halevy" , "Spencer Shepler" X-OriginalArrivalTime: 16 Nov 2007 15:24:45.0668 (UTC) FILETIME=[D17F4A40:01C82864] X-Spam-Score: -4.0 (----) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: email2mre-ietf@yahoo.com, 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 > Ditto. To make forward progress the client must be prepared to get less > than what it requested.=20 To make forward progress the client must be prepared to get zero, because=20 he is not guaranteed to get any particular amount even if that amount is one byte. The client must be prepared to read and write through the MDS. Some of the discussion here seems to assume that a layout and IO to the DS is a sine qua non when you have pNFS active, and I don't think that is right. If the client gets one byte and does not take the hint and use the MDS, then it is not going to survive. I think it makes sense for the client to be able to tell the server in advance what his useful minimum will be, so if the server can't provide it, the client doesn't have a useless layout to return. -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Friday, November 16, 2007 1:52 AM To: Spencer Shepler Cc: email2mre-ietf@yahoo.com; NFSv4 Subject: Re: [nfsv4] LAYOUTGET minlength On Nov. 15, 2007, 21:47 +0200, Spencer Shepler wrote: > On Nov 15, 2007, at 7:48 AM, Benny Halevy wrote: >=20 >> On Nov. 15, 2007, 15:25 +0200, Mike Eisler > ietf@yahoo.com> wrote: >>> --- Benny Halevy wrote: >>> >>>> Following a discussion we had in the last Bakeathon >>>> I propose the following wording changes: >>>> >>>> 1. Allow zero minlength. >>>> The motivation is to send an opportunistic LAYOUTGET for >>>> iomode=3Dopen_mode and offset=3Dlength=3Dminlength=3D0 along with = OPEN >>>> so that the server can return an initial layout starting from offset >>>> 0 >>>> for which the length doesn't matter, as the client has no bytes to >>>> read or write at this point. >>> Why doesn't minlength=3Dlength=3D1 work? >> because for writes, you don't want the server to provisionally =20 >> allocate >> anything at this point. >> >>> Here's my preference: delete minlength. The text about minlength >>> and overlap never made any sense. >> I'm OK with that. >> >> But I'd still prefer to require that the returned layout MUST cover >> the requested offset, i.e.: >> lo_offset <=3D loga_offset && >> lo_offset + lo_length >=3D loga_offset + ((loga_length !=3D 0) ? 1 : = 0); >=20 > Did you intend: >=20 > lo_offset <=3D loga_offset && > lo_offset + lo_length >=3D loga_offset + (loga_length !=3D 0) ? =20 > loga_length : 1 >=20 > In other words the returned layout's length must be at least > equal to the length originally requested? No, that's not always possible for the server. The requirement above is just the minimum the server must return (in the success case). I should probably have stated that as "The returned layout MUST cover the requested offset and at least one more byte if loga_length is greater than zero" >=20 > I am of the opinion that the server should be able to > return less that what was requested and this behavior > would be useful. Ditto. To make forward progress the client must be prepared to get less than what it requested. My rational for: lo_offset + lo_length >=3D loga_offset + ((loga_length !=3D 0) ? 1 : 0); if if the client indicated a loga_length !=3D 0 then the server should return a layout covering at least 1 byte after loga_offset, to allow forward progress (of course 1 byte is not very practical in most case and I count on servers to do a better job if they want to survive :) otherwise, if loga_length was zero, the server MAY return a layout describing the file only at offset =3D=3D loga_offset. >=20 > Spencer >=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 Nov 16 11:02: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 1It3eV-0001wN-DT; Fri, 16 Nov 2007 11:02:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3eT-0001iL-TM for nfsv4@ietf.org; Fri, 16 Nov 2007 11:02:41 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It3eR-00071Y-4C for nfsv4@ietf.org; Fri, 16 Nov 2007 11:02:41 -0500 X-IronPort-AV: E=Sophos;i="4.21,426,1188802800"; d="scan'208";a="123053543" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 16 Nov 2007 08:02:37 -0800 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 lAGG2YF5019206; Fri, 16 Nov 2007 08:02:36 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 08:02:30 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 08:02:30 -0800 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] Issue in LAYOUTRETURN Date: Fri, 16 Nov 2007 11:02:29 -0500 Message-ID: In-Reply-To: <3C48955F-1896-4AAD-ABDA-05421FBD78DA@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Issue in LAYOUTRETURN Thread-Index: AcgoOtxFPbhmVuFtSEOE3lhOIbl18AALQdeA From: "Noveck, Dave" To: "Spencer Shepler" X-OriginalArrivalTime: 16 Nov 2007 16:02:30.0310 (UTC) FILETIME=[17543C60:01C8286A] X-Spam-Score: -4.0 (----) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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 would prefer that we view the "FSID" and "ALL" variants of > the recall and return processing as a shorthand reference to > the individual layout detail. Therefore, if the server > does a recall of "ALL", then the client can return the > individual layouts or it can to the return of "ALL".=20 I would prefer that interpretation as well. However, it conflicts, at least in spirit, with the following from LAYOUTRECALL: However, the last LAYOUTRETURN in a sequence of returns, MUST specify the full range being recalled (see Section 12.5.4.1 for details). I think we should rethink this for draft-18. The reasoning in Section 12.5.4.1 doesn't convince me and the working group should come to a consensus on this issue. > Half-baked??. It seems valuable to a client in the event of > a client dealing with an unmount of a filesystem or shutdown > of the system.=20 I think we need to separate three different questions. 1. How baked, i.e. clearly specified without conflicts with=20 other pieces of the spec, this is. 2. How good this will taste, i.e. convenient and useful it will be, when it is fully baked. 3. How necessary it is, i.e. whether without it there will be severe difficulty in doing pNFS implementations. I think we are at the point where things should not go into the protocol where they are not OK, with respect to 1+2. Soon, we will need to raise that bar and insist that changes not=20 go in unless that are OK with regard to 1+3. If the bar remains at 1+2, we will never close. With this group of people, we will always be able to improve the protocol, and come up with things that, when well-baked, will taste fine, and we will be able to=20 get them well-baked, through group discussion. But the result=20 will be the finest protocol that never actually got finished. =20 None of us would like that. -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Thursday, November 15, 2007 4:19 PM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: Re: [nfsv4] Issue in LAYOUTRETURN On Nov 14, 2007, at 2:55 PM, Noveck, Dave wrote: > In editing this to deal with another issue, I noted the following: > > The server MAY require that the principal, security flavor, and > applicable, the GSS mechanism, combination that acquired the > layout also be the one to issue LAYOUTRETURN. This might not be > possible if credentials for the principal are no longer > available. The server MAY allow the machine credential or SSV > credential (see ) to issue > DELEGRETURN. > > If the client does the former without doing the latter, it is > going to have a heck of a time doing LAYOUTRETURN_FSID or > LAYOUTRETURN_ALL. Do we want to say something about this. > > Depending on your interpretation of: > > However, > if it is a subset, the recall is not complete until the full > recalled scope has been returned. Recalled scope refers to the > byte range in the case of LAYOUTRETURN4_FILE, use of > LAYOUTRETURN4_FSID, or the use of LAYOUTRETURN4_ALL. > > it may not be possible to respond to LAYOUTRECALL of ALL, if > the requirement is that the client actually do a completing > LAYOUTRETURN4_ALL, rather than simply returning each and > every layout he holds. I would prefer that we view the "FSID" and "ALL" variants of the recall and return processing as a shorthand reference to the individual layout detail. Therefore, if the server does a recall of "ALL", then the client can return the individual layouts or it can to the return of "ALL". Conversely, if the server recalls an individual layout, the client can do a return of "ALL" and have it satisfy the recall processing. Half-baked??. It seems valuable to a client in the event of a client dealing with an unmount of a filesystem or shutdown of the system. Of course, we don't have a corresponding CLOSE("ALL) or DELEGRETURN("ALL) so maybe that would argue that without the symmetry the feature isn't needed and may lead to lazy/broken client implementations. 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 Fri Nov 16 12:04: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 1It4c2-0002lc-BA; Fri, 16 Nov 2007 12:04:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4c0-0002lK-44 for nfsv4@ietf.org; Fri, 16 Nov 2007 12:04:12 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It4bw-00052A-KC for nfsv4@ietf.org; Fri, 16 Nov 2007 12:04:12 -0500 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id lAGH3s31021182 for ; Fri, 16 Nov 2007 12:03:54 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.6) with ESMTP id lAGH3sd4476138 for ; Fri, 16 Nov 2007 12:03:54 -0500 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 lAGH3sWh017469 for ; Fri, 16 Nov 2007 12:03:54 -0500 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 lAGH3slp017466; Fri, 16 Nov 2007 12:03:54 -0500 In-Reply-To: <473CF19F.5030102@netapp.com> To: Garth Goodson MIME-Version: 1.0 Subject: Re: [nfsv4] pNFS Dense Packing Problem X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Marc Eshel Date: Fri, 16 Nov 2007 09:03:48 -0800 X-MIMETrack: Serialize by Router on D01ML604/01/M/IBM(Release 8.0|August 02, 2007) at 11/16/2007 12:03:53, Serialize complete at 11/16/2007 12:03:53 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: -4.0 (----) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 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 Garth Goodson wrote on 11/15/2007 05:25:51 PM: > > > Mike Eisler wrote: > > A majority of the editors agree we should remove DENSE packing from > > the NFSv4.1 pNFS file layout specification since as Anatoly points out, > > it doesn't work. > > > > I plan to start ripping it out in a few hours unless someone can > > convince us otherwise. > > > > Granted I haven't paid as much attention to the new layout structure, > but when it was defined previously it wasn't a problem to support most > of these options, with one exception described below. > > If you wanted to use different stripe units for different sections of > the file you would get different layouts that covered those portions. > As long as the FHs were different you could even use DENSE and SPARSE > layouts on different portions of the file and this may be true today as > well. > > The one exception (with the old layout scheme) is that you couldn't have > different stripe widths for data servers covered by the same layout. We > felt this a reasonable compromise. I'm guessing that the motivation to > support this is to be able to offload more work to some servers and less > to others which may be useful in some heterogeneous storage environments. > > It seems that the new layout scheme isn't the end-all solution we were > hoping for. However, at some point the layout definition will need to > stop changing -- we won't ever agree on all the changes it requires to > support everyone's needs, and I'm afraid it just becomes more > complicated with minimal returns... > > As far as I recall, the IBM GPFS guys wanted dense layouts as that is > how GPFS stores the data. Using either DENSE layouts or converting > SPARSE to DENSE on the data server requires full knowledge of the > layout, so this shouldn't be a major stumbling block. Maybe Marc Eshel > can weigh in. Right now we actually use the SPARSE layout, but we can see that DENSE layout might be useful for some other configuration of the server that we might evolve to in the future. In short we would like to have it but not at the cost of more delays in completing this draft. Marc. > -Garth > > > --- Mike Eisler wrote: > > > >> --- Anatoly Pinchuk wrote: > >> > >> > >>> --- Anatoly Pinchuk wrote: > >>> > >>>> 1. If the client file layouts can have different stripe unit > >> sizes > >>> we > >>>> need more than just a text clarification. In that case the layout > >>>> structure should include additional information to calculate a > >> data > >>>> file offset for dense packing. Offset returned in layout4 > >> structure > >>>> and stripe unit size is not enough to do the calculation. Here is > >>> an > >>>> example: > >>>> > >>>> There are devices: > >>>> struct nfsv4_1_file_layout_ds_addr4 > >>>> dev0 = { // ID is 0 > >>>> {0}, > >>>> {{A}} > >>>> }, > >>>> dev1 = { // ID is 1 > >>>> {0}, > >>>> {{B}} > >>>> }; > >>>> > >>>> File Layouts for a client file > >>>> struct nfsv4_1_file_layout4 > >>>> fl0 = { > >>>> 0, > >> deviceID 0 > >> > >>>> x, // stripe unit size of 0x400 is coded with x > >>>> 0, > >>>> fh0 > >>>> }, > >>>> fl1 = { > >>>> 1, > >> deviceID 1 > >>>> y, // stripe unit size of 0x1000 and dense packing are coded > >>> with > >>>> y > >>>> 0, > >>>> fh1 > >>>> }; > >>>> > >>>> fl0 and fl1 correspond to file ranges [0, 0x400-1] and [0x400, > >>>> 0x1400-1]; > >>>> > >>>> Now a client requests layout for an offset of 0x800 and length > >>> 0x400 > >>>> and the reply is: > >>>> > >>>> struct layout4 > >>>> lo = { > >>>> 0x800, > >> offset 0x800 > >> > >>>> 0x400, > >>>> lo_iomode, // some IO mode > >>>> lo_content // see below > >>>> }; > >>>> > >>>> struct layout_content4 > >>>> lo_content = { > >>>> LAYOUT4_NFSV4_1_FILES, > >>>> loc_body // see below > >>>> }; > >>>> loc_body contains fl1 defined above. > >>>> > >>>> So, the client knows the server (B) and the file handle (fh1) to > >> do > >>>> IO on. Offset for the fh1 is needed as well. The formula from > >>>> paragraph 14.5 does not provide correct offset since > >>>> > >>>> data_file_offset = floor(file_offset / stripe_width) > >>>> * stripe_unit_size + file_offset % stripe_unit_size = > >>>> floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 = 0x800; > >>>> > >>>> and the correct offset is > >>>> > >>>> rel_off = (file_offset - layout_offset) = (0x800 - 0x400) = > >> 0x400; > >>>> data_file_offset = floor(rel_offset / stripe_width) > >>>> * stripe_unit_size + rel_offset % stripe_unit_size = > >>>> floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 = 0x400; > >> Unless fh1 and fh0 are the same. > >> > >> This is a big problem and I don't have an immediate > >> answer other than to suggest we remove dense > >> packing from the protocol and rely on data server intelligence > >> to pack stripe units. > >> > >> > >> > > > > > > _______________________________________________ > > 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 MadihaPiironen@nankai-shuhan.co.jp Fri Nov 16 12:05:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It4d5-0003zb-EW for nfsv4-archive@lists.ietf.org; Fri, 16 Nov 2007 12:05:19 -0500 Received: from i59f5eba8.versanet.de ([89.245.235.168]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It4d4-0003lM-U9 for nfsv4-archive@lists.ietf.org; Fri, 16 Nov 2007 12:05:19 -0500 Received: from your-c61lshcy87 ([187.166.128.11] helo=your-c61lshcy87) by i59F5EBA8.versanet.de ( sendmail 8.13.3/8.13.1) with esmtpa id 1QztrS-000YRO-CY for nfsv4-archive@lists.ietf.org; Fri, 16 Nov 2007 18:05:24 -0800 Message-ID: <000901c828be$499778a0$a8ebf559@yourc61lshcy87> From: "Madiha Piironen" To: Subject: ivideps Date: Fri, 16 Nov 2007 18:05:12 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C8287B.3B75BF40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.7 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0009_01C8287B.3B75BF40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thicken your penis - Increase the girth (width) of your penis moseh rehmann http://www.cenglur.com/ ------=_NextPart_000_0009_01C8287B.3B75BF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thicken your penis - Increase the girth = (width) of your penis
moseh rehmann
http://www.cenglur.com/
= ------=_NextPart_000_0009_01C8287B.3B75BF40-- From nfsv4-bounces@ietf.org Fri Nov 16 13:08: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 1It5cJ-0001iG-L0; Fri, 16 Nov 2007 13:08:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It5cI-0001gq-It for nfsv4@ietf.org; Fri, 16 Nov 2007 13:08:34 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It5cD-0003y4-V2 for nfsv4@ietf.org; Fri, 16 Nov 2007 13:08:34 -0500 Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAGI8T9K018193; Fri, 16 Nov 2007 13:08:29 -0500 (EST) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Fri, 16 Nov 2007 13:08:29 -0500 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAGI7xQ7005547; Fri, 16 Nov 2007 13:08:28 -0500 (EST) From: Black_David@emc.com Received: from corpussmtp3.corp.emc.com ([10.254.64.53]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 13:07:58 -0500 Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 13:05:18 -0500 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] Issue in LAYOUTRETURN Date: Fri, 16 Nov 2007 13:05:16 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [nfsv4] Issue in LAYOUTRETURN Thread-index: AcgoOtxFPbhmVuFtSEOE3lhOIbl18AALQdeAAAR8CTA= References: <3C48955F-1896-4AAD-ABDA-05421FBD78DA@sun.com> To: X-OriginalArrivalTime: 16 Nov 2007 18:05:18.0416 (UTC) FILETIME=[3F0FFD00:01C8287B] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 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-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: -4.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 Dave,=20 > > I would prefer that we view the "FSID" and "ALL" variants of > > the recall and return processing as a shorthand reference to > > the individual layout detail. Therefore, if the server > > does a recall of "ALL", then the client can return the > > individual layouts or it can to the return of "ALL".=20 >=20 > I would prefer that interpretation as well. >=20 > However, it conflicts, at least in spirit, with the following > from LAYOUTRECALL: >=20 > However, the last LAYOUTRETURN in a sequence of > returns, MUST specify the full range being recalled (see > Section 12.5.4.1 for details). >=20 > I think we should rethink this for draft-18. The reasoning > in Section 12.5.4.1 doesn't convince me and the working group > should come to a consensus on this issue. If a client can free up the layouts at different times, it can return the individual layouts earlier than doing the ALL return. Doing ALL as the final return helps deal with possible state mismatches (different views on which layouts are held) between client and server. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer 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 PriscillaplastisolPoe@peoplespot.com Fri Nov 16 13:36:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It63X-0000ik-O7; Fri, 16 Nov 2007 13:36:43 -0500 Received: from pool-71-174-164-37.bstnma.east.verizon.net ([71.174.164.37] helo=tristan.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1It63X-0006N3-EH; Fri, 16 Nov 2007 13:36:43 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host14981000.peoplespot.com (8.13.1/8.13.1) with SMTP id gxGpUnpr02.282295.7kY.NLI.5991799860831 for ; Fri, 16 Nov 2007 13:36:04 +0500 Message-ID: <4554701c8287f$9d8277b0$2f01a8c0@tristan> From: "Tracey Stroud" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_45543_01C8287F.9D8277B0-- From KeishabushelClifford@williebird.com Fri Nov 16 16:45:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It90M-0005u0-9C; Fri, 16 Nov 2007 16:45:38 -0500 Received: from anice-157-1-33-123.w90-28.abo.wanadoo.fr ([90.28.48.123] helo=ad8f0c33986614) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1It90L-0002kW-Pe; Fri, 16 Nov 2007 16:45:38 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host35833637.williebird.com (8.13.1/8.13.1) with SMTP id 2SucDNdo26.931744.Q0F.9PR.2309954353875 for ; Fri, 16 Nov 2007 22:44:35 -0100 Message-ID: <2807801c82899$f6f2e540$5701a8c0@ad8f0c33986614> From: "Jayne Moseley" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_28074_01C82899.F6F2E540-- From nfsv4-bounces@ietf.org Fri Nov 16 17:37: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 1It9p0-0007oG-Jf; Fri, 16 Nov 2007 17:37:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It9oz-0007lB-Es for nfsv4@ietf.org; Fri, 16 Nov 2007 17:37:57 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It9ov-0005B9-Rq for nfsv4@ietf.org; Fri, 16 Nov 2007 17:37:57 -0500 X-IronPort-AV: E=Sophos;i="4.21,428,1188802800"; d="scan'208";a="123165618" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 16 Nov 2007 14:37:23 -0800 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 lAGMbMea004916; Fri, 16 Nov 2007 14:37:22 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 14:37:22 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 14:37:22 -0800 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] Issue in LAYOUTRETURN Date: Fri, 16 Nov 2007 17:37:20 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Issue in LAYOUTRETURN Thread-Index: AcgoOtxFPbhmVuFtSEOE3lhOIbl18AALQdeAAAR8CTAACXS94A== From: "Noveck, Dave" To: X-OriginalArrivalTime: 16 Nov 2007 22:37:22.0411 (UTC) FILETIME=[40EBF3B0:01C828A1] X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 have trouble believing that even with this approach to matching of LAYOUTRETURN and CB_RECALLLAYOUT we can survive a situation in which the client and server have divergent views of what layouts are held. In particular, the addition of stateids to this logic, doesn't seem very consistent with a protocol intended to have the client and=20 server allow such differences to develop and somehow accommodate them. I do a LAYOUTGET and I get a stateid, which I then use in a subsequent LAYOUTGET, but I send it with seqid zero to accommodate the possiblity of parallel LAYOUTGET's. The seqids on the stateids coming back are not going to coherent if the server has not maintained information, including stateids, on the layouts he thinks (or rather know) I have. Similarly with voluntary LAYOUTRETURN's. =20 If we want to design the protocol so that such diveregences in layout knowledge can be accommodated, I think we need some careful review, to make sure that the protocol as a whole can work in the presence=20 of such divergences. =20 -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: Friday, November 16, 2007 1:05 PM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: RE: [nfsv4] Issue in LAYOUTRETURN Dave,=20 > > I would prefer that we view the "FSID" and "ALL" variants of the=20 > > recall and return processing as a shorthand reference to the=20 > > individual layout detail. Therefore, if the server does a recall of > > "ALL", then the client can return the individual layouts or it can=20 > > to the return of "ALL". >=20 > I would prefer that interpretation as well. >=20 > However, it conflicts, at least in spirit, with the following from=20 > LAYOUTRECALL: >=20 > However, the last LAYOUTRETURN in a sequence of > returns, MUST specify the full range being recalled (see > Section 12.5.4.1 for details). >=20 > I think we should rethink this for draft-18. The reasoning in Section > 12.5.4.1 doesn't convince me and the working group should come to a=20 > consensus on this issue. If a client can free up the layouts at different times, it can return the individual layouts earlier than doing the ALL return. Doing ALL as the final return helps deal with possible state mismatches (different views on which layouts are held) between client and server. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer 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 Sat Nov 17 23:45:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itc0d-0003RW-LB; Sat, 17 Nov 2007 23:43:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itc0c-0003RR-I8 for nfsv4@ietf.org; Sat, 17 Nov 2007 23:43:50 -0500 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 1Itc0a-0008C4-Ah for nfsv4@ietf.org; Sat, 17 Nov 2007 23:43:50 -0500 Received: from medlicott.panasas.com (cassoulet.panasas.com [172.17.1.122]) by cassoulet.panasas.com (8.13.1/8.13.1) with ESMTP id lAI4himk022928; Sat, 17 Nov 2007 23:43:45 -0500 Received: from 172.17.132.188 ([172.17.132.188] helo=medlicott.panasas.com) by ASSP-nospam; 17 Nov 2007 23:43:44 -0500 Received: from panasas.com (localhost.localdomain [127.0.0.1]) by medlicott.panasas.com (8.13.5/8.13.7) with ESMTP id lAI4hZuY027938; Sat, 17 Nov 2007 20:43:35 -0800 Message-Id: <200711180443.lAI4hZuY027938@medlicott.panasas.com> To: Benny Halevy Subject: Re: [nfsv4] pNFS Dense Packing Problem In-reply-to: <473C152C.9070900@panasas.com> References: <54531.64117.qm@web38110.mail.mud.yahoo.com> <391282.29333.qm@web38115.mail.mud.yahoo.com> <01AE8AF878612047A442668306EAEB05013918D7@SACEXMV01.hq.netapp.com> <473C152C.9070900@panasas.com> Comments: In-reply-to Benny Halevy message dated "Thu, 15 Nov 2007 11:45:16 +0200." From: Brent Welch X-URL: http://www.panasas.com/ X-Face: "HxE|?EnC9fVMV8f70H83&{fgLE.|FZ^$>@Q(yb#N, Eh~N]e&]=>r5~UnRml1:4EglY{9B+ :'wJq$@c_C!l8@<$t,{YUr4K,QJGHSvS~U]H`<+L*x?eGzSk>XH\W:AK\j?@?c1o Date: Sat, 17 Nov 2007 20:43:35 -0800 X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: email2mre-ietf@yahoo.com, Brent Welch , 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 FWIW, in our experience, which is all with dense packing, is that the data servers can naturally do read-ahead w/out knowledge of the striping. Having large holes in the sparse striping will likely complicate read-ahead on the data servers. This seems like a common case that you'd like to get right, as opposed to variable stripe units and stripe widths within the same file. Is the motivation for that the transition from small files to large files? If you are striping RAID-0 across data servers, can't you just grow the stripe width as the files transition from small to large? The math on the client is trivial with dense packing, unless of course you change the striping in different file offsets. Seems like an odd complication for both sparse and dense striping. >>>Benny Halevy said: > > The initial assumption AFAICT was that there is just one stripe (unit) size > for the file and the data_file_offset calculation was based on that. > This can be fixed by either allowing mixed stripe unit sizes and correcting > the math in section 13.4.2. Interpreting the File Layout Using Dense Packin g, > or by eliminating mixed stripe sizes, e.g. by moving the stripe unit size > to nfsv4_1_file_layouthint4, along side with nflh_stripe_count. BTW, if you > allow mixed stripe sizes why don't you provide for mixed stripe counts? > In CMU's model the file could be comprised of a concatenation of "patterns" > each with it's own striping geometry, and frankly, intuitively this makes > more sense to me than a set stripe count and variable stripe unit size... > Anyhow, I'm not sure how mixed stripe unit sizes work with sparse > packing and what's their use case. If supporting them isn't justified > I'd rather eliminate that feature rather than dense packing. > > Benny > > On Nov. 15, 2007, 10:15 +0200, "Muntz, Daniel" wrote: > > Would it be correct to say that this decision is being made under these > > assumptions: > > > > 1) dense striping is less valuable than mixed stripe sizes > > 2) do not want to provide an option to choose either mixed stripe sizes > > _OR_ dense stripes per [file/fs/...] > > 3) mixed stripe sizes are believed to be supportable except for this > > conflict with dense striping (I'm still trying to convince myself on > > this point). > > > > -Dan > > > >> -----Original Message----- > >> From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > >> Sent: Wednesday, November 14, 2007 9:19 PM > >> To: nfsv4@ietf.org > >> Subject: [nfsv4] pNFS Dense Packing Problem > >> > >> A majority of the editors agree we should remove DENSE packing from > >> the NFSv4.1 pNFS file layout specification since as Anatoly > >> points out, > >> it doesn't work. > >> > >> I plan to start ripping it out in a few hours unless someone can > >> convince us otherwise. > >> > >> --- Mike Eisler wrote: > >> > >>> --- Anatoly Pinchuk wrote: > >>> > >>> > >>>> --- Anatoly Pinchuk wrote: > >>>> > >>>>> 1. If the client file layouts can have different stripe unit > >>> sizes > >>>> we > >>>>> need more than just a text clarification. In that case > >> the layout > >>>>> structure should include additional information to calculate a > >>> data > >>>>> file offset for dense packing. Offset returned in layout4 > >>> structure > >>>>> and stripe unit size is not enough to do the > >> calculation. Here is > >>>> an > >>>>> example: > >>>>> > >>>>> There are devices: > >>>>> struct nfsv4_1_file_layout_ds_addr4 > >>>>> dev0 = { // ID is 0 > >>>>> {0}, > >>>>> {{A}} > >>>>> }, > >>>>> dev1 = { // ID is 1 > >>>>> {0}, > >>>>> {{B}} > >>>>> }; > >>>>> > >>>>> File Layouts for a client file > >>>>> struct nfsv4_1_file_layout4 > >>>>> fl0 = { > >>>>> 0, > >>> deviceID 0 > >>> > >>>>> x, // stripe unit size of 0x400 is coded with x > >>>>> 0, > >>>>> fh0 > >>>>> }, > >>>>> fl1 = { > >>>>> 1, > >>> deviceID 1 > >>>>> y, // stripe unit size of 0x1000 and dense packing are coded > >>>> with > >>>>> y > >>>>> 0, > >>>>> fh1 > >>>>> }; > >>>>> > >>>>> fl0 and fl1 correspond to file ranges [0, 0x400-1] and [0x400, > >>>>> 0x1400-1]; > >>>>> > >>>>> Now a client requests layout for an offset of 0x800 and length > >>>> 0x400 > >>>>> and the reply is: > >>>>> > >>>>> struct layout4 > >>>>> lo = { > >>>>> 0x800, > >>> offset 0x800 > >>> > >>>>> 0x400, > >>>>> lo_iomode, // some IO mode > >>>>> lo_content // see below > >>>>> }; > >>>>> > >>>>> struct layout_content4 > >>>>> lo_content = { > >>>>> LAYOUT4_NFSV4_1_FILES, > >>>>> loc_body // see below > >>>>> }; > >>>>> loc_body contains fl1 defined above. > >>>>> > >>>>> So, the client knows the server (B) and the file handle (fh1) to > >>> do > >>>>> IO on. Offset for the fh1 is needed as well. The formula from > >>>>> paragraph 14.5 does not provide correct offset since > >>>>> > >>>>> data_file_offset = floor(file_offset / stripe_width) > >>>>> * stripe_unit_size + file_offset % stripe_unit_size = > >>>>> floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 = 0x800; > >>>>> > >>>>> and the correct offset is > >>>>> > >>>>> rel_off = (file_offset - layout_offset) = (0x800 - 0x400) = > >>> 0x400; > >>>>> data_file_offset = floor(rel_offset / stripe_width) > >>>>> * stripe_unit_size + rel_offset % stripe_unit_size = > >>>>> floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 = 0x400; > >>> Unless fh1 and fh0 are the same. > >>> > >>> This is a big problem and I don't have an immediate > >>> answer other than to suggest we remove dense > >>> packing from the protocol and rely on data server intelligence > >>> to pack stripe units. > >>> > >>> > >>> > >> > >> _______________________________________________ > >> 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 > > -- Brent Welch Director, Software Architecture, Panasas Inc The Leader in Parallel Storage www.panasas.com welch@panasas.com _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sun Nov 18 00:18: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 1ItcYL-0003aT-Nr; Sun, 18 Nov 2007 00:18:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItcYK-0003X8-Bf for nfsv4@ietf.org; Sun, 18 Nov 2007 00:18:40 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItcYJ-0004SF-KO for nfsv4@ietf.org; Sun, 18 Nov 2007 00:18:40 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAI5Ico0001575 for ; Sun, 18 Nov 2007 05:18:38 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRO00201RYOQQ00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Sat, 17 Nov 2007 22:18:38 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-171-64.dsl.austtx.sbcglobal.net [71.145.171.64]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRO00FI8S31LM00@mail-amer.sun.com>; Sat, 17 Nov 2007 22:18:38 -0700 (MST) Date: Sat, 17 Nov 2007 23:19:29 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Issue in LAYOUTRETURN In-reply-to: To: "Noveck, Dave" Message-id: <4A3FA24D-EEEB-41E5-8D7D-4E0A76082FF7@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: b7b9551d71acde901886cc48bfc088a6 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 Nov 16, 2007, at 4:37 PM, Noveck, Dave wrote: > I have trouble believing that even with this approach to matching of > LAYOUTRETURN and CB_RECALLLAYOUT we can survive a situation in which > the client and server have divergent views of what layouts are held. > In particular, the addition of stateids to this logic, doesn't seem > very consistent with a protocol intended to have the client and > server allow such differences to develop and somehow accommodate > them. > > I do a LAYOUTGET and I get a stateid, which I then use in a subsequent > LAYOUTGET, but I send it with seqid zero to accommodate the possiblity > of parallel LAYOUTGET's. The seqids on the stateids coming back > are not going to coherent if the server has not maintained > information, > including stateids, on the layouts he thinks (or rather know) I have. > Similarly with voluntary LAYOUTRETURN's. > > If we want to design the protocol so that such diveregences in layout > knowledge can be accommodated, I think we need some careful review, > to make sure that the protocol as a whole can work in the presence > of such divergences. To support Dave's observations in differing language. Byte range file locking isn't expected to diverge and layouts should be treated no differently. If we are planning for failure, that is what we will receive and deserve. Spencer > > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, November 16, 2007 1:05 PM > To: Noveck, Dave > Cc: nfsv4@ietf.org > Subject: RE: [nfsv4] Issue in LAYOUTRETURN > > Dave, > >>> I would prefer that we view the "FSID" and "ALL" variants of the >>> recall and return processing as a shorthand reference to the >>> individual layout detail. Therefore, if the server does a recall of > >>> "ALL", then the client can return the individual layouts or it can >>> to the return of "ALL". >> >> I would prefer that interpretation as well. >> >> However, it conflicts, at least in spirit, with the following from >> LAYOUTRECALL: >> >> However, the last LAYOUTRETURN in a sequence of >> returns, MUST specify the full range being recalled (see >> Section 12.5.4.1 for details). >> >> I think we should rethink this for draft-18. The reasoning in >> Section > >> 12.5.4.1 doesn't convince me and the working group should come to a >> consensus on this issue. > > If a client can free up the layouts at different times, it can return > the individual layouts earlier than doing the ALL return. > Doing ALL as the final return helps deal with possible state > mismatches > (different views on which layouts are held) between client and server. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > 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 Sun Nov 18 10:22: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 1Itlz1-000880-0q; Sun, 18 Nov 2007 10:22:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itlyz-00087k-Bd for nfsv4@ietf.org; Sun, 18 Nov 2007 10:22:49 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itlyw-0006RP-0X for nfsv4@ietf.org; Sun, 18 Nov 2007 10:22:49 -0500 X-IronPort-AV: E=Sophos;i="4.21,433,1188802800"; d="scan'208";a="123620531" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 18 Nov 2007 07:22:15 -0800 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 lAIFMESP029697; Sun, 18 Nov 2007 07:22:14 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Nov 2007 07:22:14 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Nov 2007 07:22:14 -0800 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] Issue in LAYOUTRETURN Date: Sun, 18 Nov 2007 10:22:12 -0500 Message-ID: In-Reply-To: <4A3FA24D-EEEB-41E5-8D7D-4E0A76082FF7@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Issue in LAYOUTRETURN Thread-Index: Acgpoo2YydxN/4/yRkmIkL+1r34mawAUcJmA From: "Noveck, Dave" To: "Spencer Shepler" X-OriginalArrivalTime: 18 Nov 2007 15:22:14.0199 (UTC) FILETIME=[CC0A7470:01C829F6] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 There are a couple of differences between layouts and byte-range locks that I think are important here: Layouts are recallable, leading to a worry that a server, by recalling some set of byte ranges, may impose on the client a complicated set of discontiguous ranges, which it might be inconvenient for the client to remember. The server, unlike the case of locks, may respond to a request=20 with something different than the client requested, leading to more complex information for the client to save. Layouts, at least potentially, are going to be used more=20 intensively than byte-range locks, making expansion of the size of data involved, for both the client and the server, more of an issue. The current spec has some places where it tries to address these issues by suggesting as David indicates that we try to accommodate the inconsistencies that would arise by simply allowing the client and the server to each forget layout information at will. I have some worries about whether that can be made to work in all cases,=20 even without layout stateids. But it seems to me that with layout=20 stateids, it gets harder. I think we need to decide what we want to do about this issue and the choices I know about are: Make this ability to independently forget layout information the centerpiece of the protocol, and drop layout stateids. Figure out how to have that ability work together with=20 stateids, convince ourselves we have done it, and clearly explain in the spec, how that works. Go to a strict agreement model as Spencer is suggesting and explain the protocol from that standpoint. =20 -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Sunday, November 18, 2007 12:19 AM To: Noveck, Dave Cc: Black_David@emc.com; nfsv4@ietf.org Subject: Re: [nfsv4] Issue in LAYOUTRETURN On Nov 16, 2007, at 4:37 PM, Noveck, Dave wrote: > I have trouble believing that even with this approach to matching of=20 > LAYOUTRETURN and CB_RECALLLAYOUT we can survive a situation in which=20 > the client and server have divergent views of what layouts are held. > In particular, the addition of stateids to this logic, doesn't seem=20 > very consistent with a protocol intended to have the client and server > allow such differences to develop and somehow accommodate them. > > I do a LAYOUTGET and I get a stateid, which I then use in a subsequent > LAYOUTGET, but I send it with seqid zero to accommodate the possiblity > of parallel LAYOUTGET's. The seqids on the stateids coming back are=20 > not going to coherent if the server has not maintained information,=20 > including stateids, on the layouts he thinks (or rather know) I have. > Similarly with voluntary LAYOUTRETURN's. > > If we want to design the protocol so that such diveregences in layout=20 > knowledge can be accommodated, I think we need some careful review, to > make sure that the protocol as a whole can work in the presence of=20 > such divergences. To support Dave's observations in differing language. Byte range file locking isn't expected to diverge and layouts should be treated no differently. If we are planning for failure, that is what we will receive and deserve. Spencer > > > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, November 16, 2007 1:05 PM > To: Noveck, Dave > Cc: nfsv4@ietf.org > Subject: RE: [nfsv4] Issue in LAYOUTRETURN > > Dave, > >>> I would prefer that we view the "FSID" and "ALL" variants of the=20 >>> recall and return processing as a shorthand reference to the=20 >>> individual layout detail. Therefore, if the server does a recall of > >>> "ALL", then the client can return the individual layouts or it can=20 >>> to the return of "ALL". >> >> I would prefer that interpretation as well. >> >> However, it conflicts, at least in spirit, with the following from >> LAYOUTRECALL: >> >> However, the last LAYOUTRETURN in a sequence of >> returns, MUST specify the full range being recalled (see >> Section 12.5.4.1 for details). >> >> I think we should rethink this for draft-18. The reasoning in=20 >> Section > >> 12.5.4.1 doesn't convince me and the working group should come to a=20 >> consensus on this issue. > > If a client can free up the layouts at different times, it can return=20 > the individual layouts earlier than doing the ALL return. > Doing ALL as the final return helps deal with possible state=20 > mismatches (different views on which layouts are held) between client=20 > and server. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer 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 francesckian6@bahriasoft.com Sun Nov 18 10:35:04 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItmAq-0005Is-KL for nfsv4-archive@lists.ietf.org; Sun, 18 Nov 2007 10:35:04 -0500 Received: from ppp-124.121.178.69.revip2.asianet.co.th ([124.121.178.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItmAp-0002dv-KY for nfsv4-archive@lists.ietf.org; Sun, 18 Nov 2007 10:35:04 -0500 Received: from [124.121.178.69] by cwlote.bahriasoft.com; Sun, 18 Nov 2007 15:36:12 +0000 Message-ID: <000a01c829f8$06071303$c10481ae@ffutrq> From: "baldwin mora" To: "Gilda Babb" Subject: We specialize in the sales of brand-name quality Date: Sun, 18 Nov 2007 13:48:49 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C829F8.06013D9B" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C829F8.06013D9B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices!=20 http://prereeraplay.net/ ------=_NextPart_000_0007_01C829F8.06013D9B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Rolex Watches and More…Great Products, Great Prices! =

http://prereeraplay.net/ ------=_NextPart_000_0007_01C829F8.06013D9B-- From nfsv4-bounces@ietf.org Sun Nov 18 14:20:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itpgf-00055Q-7d; Sun, 18 Nov 2007 14:20:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItpgZ-0004yr-7g; Sun, 18 Nov 2007 14:20:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItpgY-0000of-Qn; Sun, 18 Nov 2007 14:20:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 6CE62175BD; Sun, 18 Nov 2007 19:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItpgX-0000QF-VR; Sun, 18 Nov 2007 14:20:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 14:20:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: nfsv4@ietf.org Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-pnfs-block-05.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 : pNFS Block/Volume Layout Author(s) : D. Black, et al. Filename : draft-ietf-nfsv4-pnfs-block-05.txt Pages : 26 Date : 2007-11-18 Parallel NFS (pNFS) extends NFSv4 to allow clients to directly access file data on the storage used by the NFSv4 server. This ability to bypass the server for data access can increase both performance and parallelism, but requires additional client functionality for data access, some of which is dependent on the class of storage used. The main pNFS operations draft specifies storage-class-independent extensions to NFS; this draft specifies the additional extensions (primarily data structures) for use of pNFS with block and volume based storage. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-pnfs-block-05.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-pnfs-block-05.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-pnfs-block-05.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-11-18141106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nfsv4-pnfs-block-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nfsv4-pnfs-block-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18141106.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 Mon Nov 19 03:50:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2Ka-0001zB-Kp; Mon, 19 Nov 2007 03:50:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2KQ-0001tE-Vd; Mon, 19 Nov 2007 03:50:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu2KQ-0006RS-Il; Mon, 19 Nov 2007 03:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7C40D2AC5D; Mon, 19 Nov 2007 08:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu2KQ-0007P1-8g; Mon, 19 Nov 2007 03:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 03:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: nfsv4@ietf.org Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-minorversion1-17.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-17.txt Pages : 538 Date : 2007-11-19 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-17.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-17.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-17.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-11-19034506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nfsv4-minorversion1-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nfsv4-minorversion1-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19034506.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 Mon Nov 19 03:50:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2Kh-0002Eq-Gn; Mon, 19 Nov 2007 03:50:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu2KT-0001tx-Br; Mon, 19 Nov 2007 03:50:05 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu2KQ-0000UR-K8; Mon, 19 Nov 2007 03:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6F79232905; Mon, 19 Nov 2007 08:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu2KQ-0007P7-A7; Mon, 19 Nov 2007 03:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 03:50:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: nfsv4@ietf.org Subject: [nfsv4] I-D Action:draft-ietf-nfsv4-minorversion1-dot-x-01.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 XDR Description Author(s) : S. Shepler, et al. Filename : draft-ietf-nfsv4-minorversion1-dot-x-01.txt Pages : 70 Date : 2007-11-19 This Internet-Draft provides the XDR description for NFSv4 minor version one. 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.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-dot-x-01.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-dot-x-01.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-dot-x-01.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-11-19034523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nfsv4-minorversion1-dot-x-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nfsv4-minorversion1-dot-x-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19034523.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 LeskittenFrye@porscheclub.com Mon Nov 19 05:09:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3Yr-0004iF-HW; Mon, 19 Nov 2007 05:09:01 -0500 Received: from pool-71-246-18-236.phlapa.fios.verizon.net ([71.246.18.236] helo=d21p5p61.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iu3Yr-0005HR-9z; Mon, 19 Nov 2007 05:09:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host75007185.porscheclub.com (8.13.1/8.13.1) with SMTP id C1dJXN7555.852137.aP9.oyr.4491549763562 for ; Mon, 19 Nov 2007 05:08:42 +0500 Message-ID: <21280401c82a94$3a00b370$0301a8c0@D21P5P61> From: "Gil Riggs" To: Subject: Your order Date: Mon, 19 Nov 2007 05:08:42 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_212800_01C82A94.3A00B370" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_212800_01C82A94.3A00B370 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_212800_01C82A94.3A00B370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_212800_01C82A94.3A00B370-- From Machalayilm@residentsagainstracism.net Mon Nov 19 13:06:11 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuB0d-0004ug-0I for nfsv4-archive@lists.ietf.org; Mon, 19 Nov 2007 13:06:11 -0500 Received: from chello084010227159.chello.pl ([84.10.227.159]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuB0c-0006mD-9f for nfsv4-archive@lists.ietf.org; Mon, 19 Nov 2007 13:06:10 -0500 Received: from 335b4148ce1d4f0 by residentsagainstracism.net with ASMTP id 7B66A544 for ; Mon, 19 Nov 2007 19:04:18 +0100 Received: from 335b4148ce1d4f0 ([164.148.145.108]) by residentsagainstracism.net with ESMTP id 2D35531DCCB6 for ; Mon, 19 Nov 2007 19:04:18 +0100 Message-ID: <000701c82ad6$8e3d5050$9fe30a54@335b4148ce1d4f0> From: "Farlo Machala" To: Subject: ajennuh Date: Mon, 19 Nov 2007 19:03:57 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C82ADE.F001B850" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 1.8 (+) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0005_01C82ADE.F001B850 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable Best ways to cure Impotenz Pauline Drye http://teacharea.com/ ------=_NextPart_000_0005_01C82ADE.F001B850 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Best ways to cure = Impotenz
Pauline Drye
http://teacharea.com/
------=_NextPart_000_0005_01C82ADE.F001B850-- From nfsv4-bounces@ietf.org Mon Nov 19 13:27:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBLE-0007Jg-MD; Mon, 19 Nov 2007 13:27:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBLD-0007JT-20 for nfsv4@ietf.org; Mon, 19 Nov 2007 13:27:27 -0500 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 1IuBLB-0001JX-DC for nfsv4@ietf.org; Mon, 19 Nov 2007 13:27:27 -0500 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 lAJIROZF020001 for ; Mon, 19 Nov 2007 13:27:24 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 19 Nov 2007 13:27:24 -0500 Received: from fs1.bhalevy.com ([172.17.28.115]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 13:27:24 -0500 Message-ID: <4741D58A.4040200@panasas.com> Date: Mon, 19 Nov 2007 20:27:22 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: nfsv4@ietf.org Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-minorversion1-17.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 18:27:24.0534 (UTC) FILETIME=[D4BAC960:01C82AD9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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 a few typo fixes below... Benny --- a/nfsv41_middle_errors.xml +++ b/nfsv41_middle_errors.xml @@ -418,7 +418,7 @@ request will be terminated. NFS4ERR_RECALLCONFLICT 10061 - A layout, delgation, or device map is unavailable due to a + A layout, delegation, or device map is unavailable due to a conflicting recall operation that is in progress. @@ -558,7 +558,7 @@ request will be terminated. NFS4ERR_WRONG_CRED 10082 - An operation mannipulating state was performed by a principal + An operation manipulating state was performed by a principal that was not allowed to modify that piece of state. NFS4ERR_WRONG_TYPE --- a/nfsv41_middle_file_layout.xml +++ b/nfsv41_middle_file_layout.xml @@ -273,7 +273,7 @@ COMMIT operations to the metadata server or data server, and the stripe unit size. If a server returns two or more overlapping layouts, each stripe unit size in - each overlapper layout MUST be the same. + each overlapping layout MUST be the same. --- a/nfsv41_middle_iana_considerations.xml +++ b/nfsv41_middle_iana_considerations.xml @@ -29,7 +29,7 @@
- The sub-section on the netaddr4 data srucure within the section + The sub-section on the netaddr4 data structure within the section "Structured Data Types" () discussed the r_netid field and the corresponding r_addr field within a netaddr4 structure. The NFS --- a/nfsv41_middle_op_layoutreturn.xml +++ b/nfsv41_middle_op_layoutreturn.xml @@ -33,9 +33,9 @@ If the set of layouts designated in the case of - LAYOUTRETURN4_FSID or LAYOUTRETURN4_ALL is empty, than no error + LAYOUTRETURN4_FSID or LAYOUTRETURN4_ALL is empty, then no error results. In the case of LAYOUTRETURN4_FILE, the byte range - specified is return evened if that is a subdivision of a layout + specified is returned even if that is a subdivision of a layout previously obtained with LAYOUTGET, a combination of multiple layouts previously obtained with LAYOUTGET, or a combination including some layouts previously obtained with LAYOUTGET, @@ -129,10 +129,10 @@ updated for this operation's processing; the current stateid will also be updated to match the returned value. If the last byte of any layout for the current file, client ID, and - layout type is being return and there are not remaining - pending CB_LAYOUTRECALL operation for which a LAYOUTRETURN - operation must be done as a completing operation, this satteid - value may be the speical stateid consisting of all zeros. + layout type is being returned and there are no remaining + pending CB_LAYOUTRECALL operations for which a LAYOUTRETURN + operation must be done as a completing operation, this stateid + value may be the special stateid consisting of all zeros. On success, the current filehandle retains its value. Internet-Drafts@ietf.org wrote: > 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-17.txt > Pages : 538 > Date : 2007-11-19 > > 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. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-17.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-17.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-17.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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Nov 19 14:30: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 1IuCKH-00029G-JA; Mon, 19 Nov 2007 14:30:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCKG-00028v-4e for nfsv4@ietf.org; Mon, 19 Nov 2007 14:30:32 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuCKF-0006NQ-7b for nfsv4@ietf.org; Mon, 19 Nov 2007 14:30:32 -0500 Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAJJUUSe009911; Mon, 19 Nov 2007 14:30:30 -0500 (EST) Received: from mailhub.lss.emc.com (nirah.lss.emc.com [10.254.144.13]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Mon, 19 Nov 2007 14:30:30 -0500 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.64.54]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAJJU8kr008801; Mon, 19 Nov 2007 14:30:27 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 14:29:59 -0500 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] Issue in LAYOUTRETURN Date: Mon, 19 Nov 2007 14:29:58 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [nfsv4] Issue in LAYOUTRETURN Thread-index: Acgpoo2YydxN/4/yRkmIkL+1r34mawAUcJmAADsAMoA= References: <4A3FA24D-EEEB-41E5-8D7D-4E0A76082FF7@sun.com> To: X-OriginalArrivalTime: 19 Nov 2007 19:29:59.0075 (UTC) FILETIME=[929C4730:01C82AE2] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 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-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 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, EMC has implementation experience from MPFS/FMP which suggests that moving from:=20 > Go to a strict agreement model as Spencer is suggesting and > explain the protocol from that standpoint. to at least: > Figure out how to have that ability work together with=20 > stateids, convince ourselves we have done it, and clearly > explain in the spec, how that works. has robustness and flexibility gains for client implementations. In the former case, when the server issues a return for a set of layouts and/or ranges, the client has to return *exactly* what the server thinks it has. Taken to its extreme limit, it can yield situations in which an out-of-sync client has no chance of working further with the server, and it imposes server communication costs on client decisions to drop otherwise-clean layout state. In the latter case, when the server issues a return for a set of layouts and/or ranges, the client has to get to a state in which it no longer has anything that needs to be returned and tell the server that it has reached that state. This allows some out-of- sync situations to be resolved cleanly, and allows some client optimizations to drop no-longer-needed state without having to talk to the server. =20 The server can't tell these two situations apart for a client that issues returns based on "I don't have any of those". Think about the responses to the Old Maid "Give me all your 8's" request - whether or not the recipient had any 8's beforehand, she will have no 8's when her response is complete, and the latter is what the server actually cares about (no outstanding layout or range covered by issued recall). Of course, the client *must* absolutely respect the stateid protocol as part of this - getting confused about the stateid is generally fatal to continued use of the state protected by the stateid. One new wrinkle here is that client discard of clean state need not affect the stateid, and that probably falls into your category of "convince ourselves we have done it, and clearly explain in the spec, how that works." The other new wrinkle is that if a client gets a recall for a layout that it has discarded, it needs to have a clean way to tell the server "I don't have that layout", and I believe that's already there as an error return to the callback. Thanks, --David =20 > -----Original Message----- > From: Noveck, Dave [mailto:Dave.Noveck@netapp.com]=20 > Sent: Sunday, November 18, 2007 10:22 AM > To: Spencer Shepler > Cc: Black, David; nfsv4@ietf.org > Subject: RE: [nfsv4] Issue in LAYOUTRETURN >=20 > There are a couple of differences between layouts and byte-range locks > that I think are important here: >=20 > Layouts are recallable, leading to a worry that a server, by > recalling some set of byte ranges, may impose on the client a > complicated set of discontiguous ranges, which it might be > inconvenient for the client to remember. >=20 > The server, unlike the case of locks, may respond to a request=20 > with something different than the client requested, leading to > more complex information for the client to save. >=20 > Layouts, at least potentially, are going to be used more=20 > intensively than byte-range locks, making expansion of the > size of data involved, for both the client and the server, > more of an issue. >=20 > The current spec has some places where it tries to address these > issues by suggesting as David indicates that we try to accommodate > the inconsistencies that would arise by simply allowing the client > and the server to each forget layout information at will. I have > some worries about whether that can be made to work in all cases,=20 > even without layout stateids. But it seems to me that with layout=20 > stateids, it gets harder. >=20 > I think we need to decide what we want to do about this issue and > the choices I know about are: >=20 > Make this ability to independently forget layout information > the centerpiece of the protocol, and drop layout stateids. >=20 > Figure out how to have that ability work together with=20 > stateids, convince ourselves we have done it, and clearly > explain in the spec, how that works. >=20 > Go to a strict agreement model as Spencer is suggesting and > explain the protocol from that standpoint. =20 >=20 > -----Original Message----- > From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 > Sent: Sunday, November 18, 2007 12:19 AM > To: Noveck, Dave > Cc: Black_David@emc.com; nfsv4@ietf.org > Subject: Re: [nfsv4] Issue in LAYOUTRETURN >=20 >=20 > On Nov 16, 2007, at 4:37 PM, Noveck, Dave wrote: >=20 > > I have trouble believing that even with this approach to=20 > matching of=20 > > LAYOUTRETURN and CB_RECALLLAYOUT we can survive a situation=20 > in which=20 > > the client and server have divergent views of what layouts are held. > > In particular, the addition of stateids to this logic, doesn't seem=20 > > very consistent with a protocol intended to have the client=20 > and server >=20 > > allow such differences to develop and somehow accommodate them. > > > > I do a LAYOUTGET and I get a stateid, which I then use in a=20 > subsequent >=20 > > LAYOUTGET, but I send it with seqid zero to accommodate the=20 > possiblity >=20 > > of parallel LAYOUTGET's. The seqids on the stateids coming=20 > back are=20 > > not going to coherent if the server has not maintained information,=20 > > including stateids, on the layouts he thinks (or rather=20 > know) I have. > > Similarly with voluntary LAYOUTRETURN's. > > > > If we want to design the protocol so that such diveregences=20 > in layout=20 > > knowledge can be accommodated, I think we need some careful=20 > review, to >=20 > > make sure that the protocol as a whole can work in the presence of=20 > > such divergences. >=20 > To support Dave's observations in differing language. Byte range file > locking isn't expected to diverge and layouts should be treated no > differently. If we are planning for failure, that is what we will > receive and deserve. >=20 > Spencer >=20 > > > > > > -----Original Message----- > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > Sent: Friday, November 16, 2007 1:05 PM > > To: Noveck, Dave > > Cc: nfsv4@ietf.org > > Subject: RE: [nfsv4] Issue in LAYOUTRETURN > > > > Dave, > > > >>> I would prefer that we view the "FSID" and "ALL" variants of the=20 > >>> recall and return processing as a shorthand reference to the=20 > >>> individual layout detail. Therefore, if the server does=20 > a recall of > > > >>> "ALL", then the client can return the individual layouts=20 > or it can=20 > >>> to the return of "ALL". > >> > >> I would prefer that interpretation as well. > >> > >> However, it conflicts, at least in spirit, with the following from > >> LAYOUTRECALL: > >> > >> However, the last LAYOUTRETURN in a sequence of > >> returns, MUST specify the full range being recalled (see > >> Section 12.5.4.1 for details). > >> > >> I think we should rethink this for draft-18. The reasoning in=20 > >> Section > > > >> 12.5.4.1 doesn't convince me and the working group should=20 > come to a=20 > >> consensus on this issue. > > > > If a client can free up the layouts at different times, it=20 > can return=20 > > the individual layouts earlier than doing the ALL return. > > Doing ALL as the final return helps deal with possible state=20 > > mismatches (different views on which layouts are held)=20 > between client=20 > > and server. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer EMC Corporation, 176=20 > South St., >=20 > > 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 >=20 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 19 14:39:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCSc-0005w1-DD; Mon, 19 Nov 2007 14:39:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCSa-0005vO-9P for nfsv4@ietf.org; Mon, 19 Nov 2007 14:39:08 -0500 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 1IuCSZ-0006mu-8b for nfsv4@ietf.org; Mon, 19 Nov 2007 14:39:08 -0500 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 lAJJd2UG021976; Mon, 19 Nov 2007 14:39:02 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 19 Nov 2007 14:39:02 -0500 Received: from fs1.bhalevy.com ([172.17.28.115]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 14:39:01 -0500 Message-ID: <4741E64C.5070705@panasas.com> Date: Mon, 19 Nov 2007 21:38:52 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: "Noveck, Dave" Subject: Re: [nfsv4] Issue in LAYOUTRETURN References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 19:39:01.0315 (UTC) FILETIME=[D5CF8930:01C82AE3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: Spencer Shepler , 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 Nov. 18, 2007, 17:22 +0200, "Noveck, Dave" wrote: > There are a couple of differences between layouts and byte-range locks > that I think are important here: > > Layouts are recallable, leading to a worry that a server, by > recalling some set of byte ranges, may impose on the client a > complicated set of discontiguous ranges, which it might be > inconvenient for the client to remember. > > The server, unlike the case of locks, may respond to a request > with something different than the client requested, leading to > more complex information for the client to save. > > Layouts, at least potentially, are going to be used more > intensively than byte-range locks, making expansion of the > size of data involved, for both the client and the server, > more of an issue. > > The current spec has some places where it tries to address these > issues by suggesting as David indicates that we try to accommodate > the inconsistencies that would arise by simply allowing the client > and the server to each forget layout information at will. I have > some worries about whether that can be made to work in all cases, > even without layout stateids. But it seems to me that with layout > stateids, it gets harder. > > I think we need to decide what we want to do about this issue and > the choices I know about are: > > Make this ability to independently forget layout information > the centerpiece of the protocol, and drop layout stateids. It's not exactly the way it is described right now. The client and server are allowed to simplify their layout state but only in one direction that results in the server assuming the client has more layouts than it thinks it has. This is encapsulated here: o It may be useful for clients to be able to discard layout information without calling LAYOUTRETURN. If conflicts that require callbacks are very rare, and a server can use a multi-file callback to recover per-client resources (e.g., via a FSID recall, or a multi-file recall within a single compound), the result may be significantly less client-server pNFS traffic. o It may be similarly useful for servers to maintain information about what ranges are held by a client on a coarse-grained basis, leading to the server's layout ranges being beyond those actually held by the client. In the extreme, a server could manage conflicts on a per-file basis, only issuing whole-file callbacks even though clients may request and be granted sub-file ranges. o In order to avoid errors, it is vital that a client not assign itself layout permissions beyond what the server has granted and that the server not forget layout permissions that have been granted. On the other hand, if a server believes that a client holds a layout that the client does not know about, it is useful for the client to cleanly indicate completion of the requested recall either by issuing a LAYOUTRETURN for the entire requested range or by returning an NFS4ERR_NOMATCHING_LAYOUT error to the CB_LAYOUTRECALL. Thus, in light of the above, it is useful for a server to be able to issue callbacks for layout ranges it has not granted to a client, and for a client to return ranges it does not hold. A pNFS client MUST always return layouts that comprise the full range specified by the recall. Note, the full recalled layout range need not be returned as part of a single operation, but may be returned in portions. This allows the client to stage the flushing of dirty data, layout commits, and returns. Also, it indicates to the metadata server that the client is making progress. ... In order to ensure client/server convergence with regard to layout state, the final LAYOUTRETURN operation in a sequence of LAYOUTRETURN operations for a particular recall, MUST specify the entire range being recalled, ... > > Figure out how to have that ability work together with > stateids, convince ourselves we have done it, and clearly > explain in the spec, how that works. > > Go to a strict agreement model as Spencer is suggesting and > explain the protocol from that standpoint. We've been advocating that for a long time. I think that having layout stateids allows us to implement a strict model though it will probably require the removal of RETURN_{FSID,ALL} from the protocol as the layout stateid is per-file. I guess that Mike Eisler would also want to get rid of RECALL_{FSID,ALL} in this occasion, but I'm not sure if this will be required. That depends on the semantics we define for the layout stateid given in the CB_LAYOUTRECALL args. If it has strict ordering semantics with respect to outstanding LAYOUTGETs and LAYOUTRETURNs then it will be a problem to correlate that stateid with any of the individual file layout's being recalled. That said, I'm not how this works together with the referring_call_list on CB_SEQUENCE. Ideally, I'll be very happy if the layout stateid on CB_LAYOUTRECALL can replace the sessions callback based mechanism for resolving the potential race as the former is simpler to implement. Benny > > -----Original Message----- > From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM] > Sent: Sunday, November 18, 2007 12:19 AM > To: Noveck, Dave > Cc: Black_David@emc.com; nfsv4@ietf.org > Subject: Re: [nfsv4] Issue in LAYOUTRETURN > > > On Nov 16, 2007, at 4:37 PM, Noveck, Dave wrote: > >> I have trouble believing that even with this approach to matching of >> LAYOUTRETURN and CB_RECALLLAYOUT we can survive a situation in which >> the client and server have divergent views of what layouts are held. >> In particular, the addition of stateids to this logic, doesn't seem >> very consistent with a protocol intended to have the client and server > >> allow such differences to develop and somehow accommodate them. >> >> I do a LAYOUTGET and I get a stateid, which I then use in a subsequent > >> LAYOUTGET, but I send it with seqid zero to accommodate the possiblity > >> of parallel LAYOUTGET's. The seqids on the stateids coming back are >> not going to coherent if the server has not maintained information, >> including stateids, on the layouts he thinks (or rather know) I have. >> Similarly with voluntary LAYOUTRETURN's. >> >> If we want to design the protocol so that such diveregences in layout >> knowledge can be accommodated, I think we need some careful review, to > >> make sure that the protocol as a whole can work in the presence of >> such divergences. > > To support Dave's observations in differing language. Byte range file > locking isn't expected to diverge and layouts should be treated no > differently. If we are planning for failure, that is what we will > receive and deserve. > > Spencer > >> >> -----Original Message----- >> From: Black_David@emc.com [mailto:Black_David@emc.com] >> Sent: Friday, November 16, 2007 1:05 PM >> To: Noveck, Dave >> Cc: nfsv4@ietf.org >> Subject: RE: [nfsv4] Issue in LAYOUTRETURN >> >> Dave, >> >>>> I would prefer that we view the "FSID" and "ALL" variants of the >>>> recall and return processing as a shorthand reference to the >>>> individual layout detail. Therefore, if the server does a recall of >>>> "ALL", then the client can return the individual layouts or it can >>>> to the return of "ALL". >>> I would prefer that interpretation as well. >>> >>> However, it conflicts, at least in spirit, with the following from >>> LAYOUTRECALL: >>> >>> However, the last LAYOUTRETURN in a sequence of >>> returns, MUST specify the full range being recalled (see >>> Section 12.5.4.1 for details). >>> >>> I think we should rethink this for draft-18. The reasoning in >>> Section >>> 12.5.4.1 doesn't convince me and the working group should come to a >>> consensus on this issue. >> If a client can free up the layouts at different times, it can return >> the individual layouts earlier than doing the ALL return. >> Doing ALL as the final return helps deal with possible state >> mismatches (different views on which layouts are held) between client >> and server. >> >> Thanks, >> --David >> ---------------------------------------------------- >> David L. Black, Distinguished Engineer 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 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 19 15:35: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 1IuDLV-0008Ce-Uw; Mon, 19 Nov 2007 15:35:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDLV-0008By-Bd for nfsv4@ietf.org; Mon, 19 Nov 2007 15:35:53 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuDLR-0002X7-Ut for nfsv4@ietf.org; Mon, 19 Nov 2007 15:35:53 -0500 X-IronPort-AV: E=Sophos;i="4.21,438,1188802800"; d="scan'208";a="124029272" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 19 Nov 2007 12:35:33 -0800 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 lAJKZWpo010745; Mon, 19 Nov 2007 12:35:32 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 12:35:33 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 12:35:32 -0800 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] I-D Action:draft-ietf-nfsv4-minorversion1-17.txt Date: Mon, 19 Nov 2007 15:35:31 -0500 Message-ID: In-Reply-To: <4741D58A.4040200@panasas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] I-D Action:draft-ietf-nfsv4-minorversion1-17.txt Thread-Index: Acgq2jM3ZuctCILpQn2MYXZiqAanagAEYC8g From: "Noveck, Dave" To: "Benny Halevy" , X-OriginalArrivalTime: 19 Nov 2007 20:35:32.0516 (UTC) FILETIME=[BB1FBE40:01C82AEB] X-Spam-Score: -4.0 (----) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 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 Done. Thanks. -----Original Message----- From: Benny Halevy [mailto:bhalevy@panasas.com]=20 Sent: Monday, November 19, 2007 1:27 PM To: nfsv4@ietf.org Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-minorversion1-17.txt a few typo fixes below... Benny --- a/nfsv41_middle_errors.xml +++ b/nfsv41_middle_errors.xml @@ -418,7 +418,7 @@ request will be terminated. NFS4ERR_RECALLCONFLICT 10061 - A layout, delgation, or device map is unavailable due to a + A layout, delegation, or device map is unavailable due to a conflicting recall operation that is in progress. @@ -558,7 +558,7 @@ request will be terminated. NFS4ERR_WRONG_CRED 10082 - An operation mannipulating state was performed by a principal + An operation manipulating state was performed by a principal that was not allowed to modify that piece of state. NFS4ERR_WRONG_TYPE --- a/nfsv41_middle_file_layout.xml +++ b/nfsv41_middle_file_layout.xml @@ -273,7 +273,7 @@ COMMIT operations to the metadata server or data server, and the stripe unit size. If a server returns two or more overlapping layouts, each stripe unit size in - each overlapper layout MUST be the same. + each overlapping layout MUST be the same. --- a/nfsv41_middle_iana_considerations.xml +++ b/nfsv41_middle_iana_considerations.xml @@ -29,7 +29,7 @@
- The sub-section on the netaddr4 data srucure within the section + The sub-section on the netaddr4 data structure within the section "Structured Data Types" () discussed the r_netid field and the corresponding r_addr field within a netaddr4 structure. The NFS --- a/nfsv41_middle_op_layoutreturn.xml +++ b/nfsv41_middle_op_layoutreturn.xml @@ -33,9 +33,9 @@ If the set of layouts designated in the case of - LAYOUTRETURN4_FSID or LAYOUTRETURN4_ALL is empty, than no error + LAYOUTRETURN4_FSID or LAYOUTRETURN4_ALL is empty, then no error results. In the case of LAYOUTRETURN4_FILE, the byte range - specified is return evened if that is a subdivision of a layout + specified is returned even if that is a subdivision of a layout previously obtained with LAYOUTGET, a combination of multiple layouts previously obtained with LAYOUTGET, or a combination including some layouts previously obtained with LAYOUTGET, @@ -129,10 +129,10 @@ updated for this operation's processing; the current stateid will also be updated to match the returned value. If the last byte of any layout for the current file, client ID, and - layout type is being return and there are not remaining - pending CB_LAYOUTRECALL operation for which a LAYOUTRETURN - operation must be done as a completing operation, this satteid - value may be the speical stateid consisting of all zeros. + layout type is being returned and there are no remaining + pending CB_LAYOUTRECALL operations for which a LAYOUTRETURN + operation must be done as a completing operation, this stateid + value may be the special stateid consisting of all zeros. On success, the current filehandle retains its value. Internet-Drafts@ietf.org wrote: > 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. >=20 >=20 > Title : NFSv4 Minor Version 1 > Author(s) : S. Shepler, et al. > Filename : draft-ietf-nfsv4-minorversion1-17.txt > Pages : 538 > Date : 2007-11-19 >=20 > 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. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-17.tx t >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP. Login with the=20 > username "anonymous" and a password of your e-mail address. After=20 > logging in, type "cd internet-drafts" and then > "get draft-ietf-nfsv4-minorversion1-17.txt". >=20 > 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 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-nfsv4-minorversion1-17.txt". >=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=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 Nov 19 17:08: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 1IuEn2-000057-Hk; Mon, 19 Nov 2007 17:08:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEn0-00004z-Q2 for nfsv4@ietf.org; Mon, 19 Nov 2007 17:08:22 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuEn0-0005AG-1x for nfsv4@ietf.org; Mon, 19 Nov 2007 17:08:22 -0500 X-IronPort-AV: E=Sophos;i="4.21,438,1188802800"; d="scan'208";a="124057727" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 19 Nov 2007 14:07:51 -0800 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 lAJM74ZH013930; Mon, 19 Nov 2007 14:07:50 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 14:07:42 -0800 Received: from exsvl03.hq.netapp.com ([10.56.8.64]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 14:07:41 -0800 Received: from [10.34.24.132] ([10.34.24.132]) by exsvl03.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 14:07:41 -0800 Message-ID: <4742092D.2080001@netapp.com> Date: Mon, 19 Nov 2007 14:07:41 -0800 From: Garth Goodson User-Agent: Icedove 1.5.0.12 (X11/20070730) MIME-Version: 1.0 To: email2mre-ietf@yahoo.com Subject: Re: [nfsv4] pNFS Dense Packing Problem References: <732387.44318.qm@web38110.mail.mud.yahoo.com> In-Reply-To: <732387.44318.qm@web38110.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Nov 2007 22:07:41.0474 (UTC) FILETIME=[9AA3C820:01C82AF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 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 Mike Eisler wrote: > --- "Muntz, Daniel" wrote: > >> Would it be correct to say that this decision is being made under >> these >> assumptions: >> >> 1) dense striping is less valuable than mixed stripe sizes >> 2) do not want to provide an option to choose either mixed stripe >> sizes >> _OR_ dense stripes per [file/fs/...] >> 3) mixed stripe sizes are believed to be supportable except for this >> conflict with dense striping (I'm still trying to convince myself on >> this point). > > Dense packing and mixed stripe sizes are suppportable as > explicit entries in the protocol. It requires > making the specification text more complex, hence easier to > misinterpret. > > Why do we have dense packing? > > 1. Some filesystems can't do holes well. > > 2. readahead I/O is harder to detect > > Dense packing can be done without making it part of the > file layout: just implement data servers to map the sparse offsets > to dense offsets. The only downside here is that the data server must understand the full layout to be able to do the translation from sparse to dense. But this is probably the best compromise... -Garth > >> -Dan >> >>> -----Original Message----- >>> From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] >>> Sent: Wednesday, November 14, 2007 9:19 PM >>> To: nfsv4@ietf.org >>> Subject: [nfsv4] pNFS Dense Packing Problem >>> >>> A majority of the editors agree we should remove DENSE packing from >>> the NFSv4.1 pNFS file layout specification since as Anatoly >>> points out, >>> it doesn't work. >>> >>> I plan to start ripping it out in a few hours unless someone can >>> convince us otherwise. >>> >>> --- Mike Eisler wrote: >>> >>>> --- Anatoly Pinchuk wrote: >>>> >>>> >>>>> --- Anatoly Pinchuk wrote: >>>>> >>>>>> 1. If the client file layouts can have different stripe unit >>>> sizes >>>>> we >>>>>> need more than just a text clarification. In that case >>> the layout >>>>>> structure should include additional information to calculate >> a >>>> data >>>>>> file offset for dense packing. Offset returned in layout4 >>>> structure >>>>>> and stripe unit size is not enough to do the >>> calculation. Here is >>>>> an >>>>>> example: >>>>>> >>>>>> There are devices: >>>>>> struct nfsv4_1_file_layout_ds_addr4 >>>>>> dev0 = { // ID is 0 >>>>>> {0}, >>>>>> {{A}} >>>>>> }, >>>>>> dev1 = { // ID is 1 >>>>>> {0}, >>>>>> {{B}} >>>>>> }; >>>>>> >>>>>> File Layouts for a client file >>>>>> struct nfsv4_1_file_layout4 >>>>>> fl0 = { >>>>>> 0, >>>> deviceID 0 >>>> >>>>>> x, // stripe unit size of 0x400 is coded with x >>>>>> 0, >>>>>> fh0 >>>>>> }, >>>>>> fl1 = { >>>>>> 1, >>>> deviceID 1 >>>>>> y, // stripe unit size of 0x1000 and dense packing are >> coded >>>>> with >>>>>> y >>>>>> 0, >>>>>> fh1 >>>>>> }; >>>>>> >>>>>> fl0 and fl1 correspond to file ranges [0, 0x400-1] and >> [0x400, >>>>>> 0x1400-1]; >>>>>> >>>>>> Now a client requests layout for an offset of 0x800 and >> length >>>>> 0x400 >>>>>> and the reply is: >>>>>> >>>>>> struct layout4 >>>>>> lo = { >>>>>> 0x800, >>>> offset 0x800 >>>> >>>>>> 0x400, >>>>>> lo_iomode, // some IO mode >>>>>> lo_content // see below >>>>>> }; >>>>>> >>>>>> struct layout_content4 >>>>>> lo_content = { >>>>>> LAYOUT4_NFSV4_1_FILES, >>>>>> loc_body // see below >>>>>> }; >>>>>> loc_body contains fl1 defined above. >>>>>> >>>>>> So, the client knows the server (B) and the file handle (fh1) >> to >>>> do >>>>>> IO on. Offset for the fh1 is needed as well. The formula from >>>>>> paragraph 14.5 does not provide correct offset since >>>>>> >>>>>> data_file_offset = floor(file_offset / stripe_width) >>>>>> * stripe_unit_size + file_offset % stripe_unit_size = >>>>>> floor(0x800/0x1000) * 0x1000 + 0x800 % 0x1000 = 0x800; >>>>>> >>>>>> and the correct offset is >>>>>> >>>>>> rel_off = (file_offset - layout_offset) = (0x800 - 0x400) = >>>> 0x400; >>>>>> data_file_offset = floor(rel_offset / stripe_width) >>>>>> * stripe_unit_size + rel_offset % stripe_unit_size = >>>>>> floor(0x400/0x1000) * 0x1000 + 0x400 % 0x1000 = 0x400; >>>> Unless fh1 and fh0 are the same. >>>> >>>> This is a big problem and I don't have an immediate >>>> answer other than to suggest we remove dense >>>> packing from the protocol and rely on data server intelligence >>>> to pack stripe units. >>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 Nov 19 20:57: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 1IuIMz-0000Oo-UV; Mon, 19 Nov 2007 20:57:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIMy-0000Oh-Us for nfsv4@ietf.org; Mon, 19 Nov 2007 20:57:44 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuIMv-0003O2-Ek for nfsv4@ietf.org; Mon, 19 Nov 2007 20:57:44 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAK1vfg6020785 for ; Tue, 20 Nov 2007 01:57:41 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRS00H0180OTJ00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 19 Nov 2007 18:57:41 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRS005M683UZL30@mail-amer.sun.com> for nfsv4@ietf.org; Mon, 19 Nov 2007 18:57:31 -0700 (MST) Date: Mon, 19 Nov 2007 19:57:32 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Issue in LAYOUTRETURN In-reply-to: To: NFSv4 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: -1.0 (-) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Nov 18, 2007, at 9:22 AM, Noveck, Dave wrote: > There are a couple of differences between layouts and byte-range locks > that I think are important here: > > Layouts are recallable, leading to a worry that a server, by > recalling some set of byte ranges, may impose on the client a > complicated set of discontiguous ranges, which it might be > inconvenient for the client to remember. > > The server, unlike the case of locks, may respond to a request > with something different than the client requested, leading to > more complex information for the client to save. In both of these cases the client is not bound to use the layout information. In the first case, it may return layout ranges to ease the implementation burden or to ease issues related to performance. It may also return the layouts and attempt to acquire new ones. In the second case, the client is not bound by the server either given that the client always has the option to read/write via the meta-data server. The server implementations will likely adapt their behaviors over time to allow for reasonable performance and interoperability with client capabilities. > Layouts, at least potentially, are going to be used more > intensively than byte-range locks, making expansion of the > size of data involved, for both the client and the server, > more of an issue. This view seems to presume complex or discontiguous layouts. Is this likely to be the case and if we don't know are we comfortable in a design that make this assumption. I don't have a strong opinion here other than my original implicit assertion about maintaining a shared common view of layout state between client and server. > > The current spec has some places where it tries to address these > issues by suggesting as David indicates that we try to accommodate > the inconsistencies that would arise by simply allowing the client > and the server to each forget layout information at will. I have > some worries about whether that can be made to work in all cases, > even without layout stateids. But it seems to me that with layout > stateids, it gets harder. I agree. And this seems to be the first principal that we are revisiting at this point. In general, for all layouts, is the design goal to allow the client (in this discussion) the ability to "forget" about layout ranges. By this I assume that this forgetfulness is in the form of not doing a LAYOUTRETURN and then being able to respond to a LAYOUTRECALL in a way to inform the server that the layout is not currently held. > > I think we need to decide what we want to do about this issue and > the choices I know about are: > > Make this ability to independently forget layout information > the centerpiece of the protocol, and drop layout stateids. > > Figure out how to have that ability work together with > stateids, convince ourselves we have done it, and clearly > explain in the spec, how that works. > > Go to a strict agreement model as Spencer is suggesting and > explain the protocol from that standpoint. To assist in making the decision about direction, it would be helpful to have concrete use cases of when the server will (either in implementation today or future plans) recall layouts. And then use cases for the client in its need for optimization of LAYOUTRETURNs in that it is anticipated to be too much overhead for client capture of the data, over the wire interaction or the combination of the two. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Mon Nov 19 21: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 1IuIUN-000296-5U; Mon, 19 Nov 2007 21:05:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIUL-0001rw-6L for nfsv4@ietf.org; Mon, 19 Nov 2007 21:05:21 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuIUI-0003Xa-22 for nfsv4@ietf.org; Mon, 19 Nov 2007 21:05:21 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAK25HS3028015 for ; Tue, 20 Nov 2007 02:05:17 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRS00L018AW3400@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 19 Nov 2007 19:05:17 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRS005NM8GTZL30@mail-amer.sun.com> for nfsv4@ietf.org; Mon, 19 Nov 2007 19:05:17 -0700 (MST) Date: Mon, 19 Nov 2007 20:05:19 -0600 From: Spencer Shepler Subject: Re: [nfsv4] Issue in LAYOUTRETURN In-reply-to: To: NFSv4 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: <4A3FA24D-EEEB-41E5-8D7D-4E0A76082FF7@sun.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Nov 19, 2007, at 1:29 PM, Black_David@emc.com wrote: > Dave, > > EMC has implementation experience from MPFS/FMP which suggests > that moving from: > >> Go to a strict agreement model as Spencer is suggesting and >> explain the protocol from that standpoint. > > to at least: > >> Figure out how to have that ability work together with >> stateids, convince ourselves we have done it, and clearly >> explain in the spec, how that works. > > has robustness and flexibility gains for client implementations. > > In the former case, when the server issues a return for a set of > layouts and/or ranges, the client has to return *exactly* what > the server thinks it has. Taken to its extreme limit, it can > yield situations in which an out-of-sync client has no chance > of working further with the server, and it imposes server > communication costs on client decisions to drop otherwise-clean > layout state. Can you add some words or experience to the case where the client is out-of-sync with the server? Is this by choice or by implementation or protocol error? > In the latter case, when the server issues a return for a set of > layouts and/or ranges, the client has to get to a state in which > it no longer has anything that needs to be returned and tell the > server that it has reached that state. This allows some out-of- > sync situations to be resolved cleanly, and allows some client > optimizations to drop no-longer-needed state without having to talk > to the server. In the implementation you mention, does the client associate layout information with cached pages and when those pages are flushed the layout information is "dropped" and thus answering my question above or is there some other condition that occurs, etc. > > The server can't tell these two situations apart for a client > that issues returns based on "I don't have any of those". Think > about the responses to the Old Maid "Give me all your 8's" > request - whether or not the recipient had any 8's beforehand, > she will have no 8's when her response is complete, and the > latter is what the server actually cares about (no outstanding > layout or range covered by issued recall). Of course, the client > *must* absolutely respect the stateid protocol as part of this - > getting confused about the stateid is generally fatal to continued > use of the state protected by the stateid. From the point of view of a protocol that requires the client and server to share the layout state, the only time the client would need to know exactly what it has is in the case where no recall of layout is being done. In the servicing of the recall, the client can just pretend it has the layouts for which the server is asking. To support the forgetful client, the layoutreturn would need to allow for a "0->max-range" layoutreturn and the stateid transition would need to occur for that to signify that the server has processed the request (even if no layouts were being held). > One new wrinkle here is that client discard of clean state need > not affect the stateid, and that probably falls into your category > of "convince ourselves we have done it, and clearly explain in > the spec, how that works." Can you expand on what you intend by "client discard of clean state"? What scenario does this describe? Spencer > The other new wrinkle is that if a > client gets a recall for a layout that it has discarded, it needs > to have a clean way to tell the server "I don't have that layout", > and I believe that's already there as an error return to the callback. > > Thanks, > --David > > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 20 01:42: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 1IuMoO-0001ez-8G; Tue, 20 Nov 2007 01:42:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuMoN-0001eu-PJ for nfsv4@ietf.org; Tue, 20 Nov 2007 01:42:19 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuMoN-0008RK-DB for nfsv4@ietf.org; Tue, 20 Nov 2007 01:42:19 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAK6gIwj006541 for ; Tue, 20 Nov 2007 06:42:18 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRS00G01L5D6H00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Mon, 19 Nov 2007 23:42:18 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRS005LGLAIZL40@mail-amer.sun.com> for nfsv4@ietf.org; Mon, 19 Nov 2007 23:42:18 -0700 (MST) Date: Tue, 20 Nov 2007 00:42:20 -0600 From: Spencer Shepler To: NFSv4 Message-id: <13A1D2B7-03DB-4F3B-96E9-9D611783E908@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: 93238566e09e6e262849b4f805833007 Subject: [nfsv4] NFSv4.1 draft 17 and moving toward working group last call 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 NFSv4.1 draft 17 was made available earlier today, as you have likely already noticed. As always, please review and provide comments (thanks to those who have commented already). The most important thing to note is that we are quickly moving towards an I-D that will be ready for working group last call. There are two areas that are receiving final review and update. The first is the operations and their associated errors. The second is the pNFS operations. The editors plan to have all known issues and the two above areas completed in draft 18 and it is our intent to start the working group last call with that draft. Given the timing of the IETF meeting and the updates needed, it is our goal to have draft 18 available sometime the week of Dec 17th. Given the size of the I-D, please consider spending time now in review draft 17 in light of the above. Thanks, Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 20 02:17: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 1IuNMW-0003AJ-LK; Tue, 20 Nov 2007 02:17:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNMV-0003A7-RA for nfsv4@ietf.org; Tue, 20 Nov 2007 02:17:35 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuNMV-0000kC-GT for nfsv4@ietf.org; Tue, 20 Nov 2007 02:17:35 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAK7HXNI022790 for ; Tue, 20 Nov 2007 07:17:34 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JRS00301MP9JH00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 20 Nov 2007 00:17:33 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JRS00CHNMX9VU30@mail-amer.sun.com> for nfsv4@ietf.org; Tue, 20 Nov 2007 00:17:33 -0700 (MST) Date: Tue, 20 Nov 2007 01:17:35 -0600 From: Spencer Shepler To: NFSv4 Message-id: <933ED09D-CC52-4F35-898B-918FF60CC491@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: cf4fa59384e76e63313391b70cd0dd25 Subject: [nfsv4] NFSv4.1 draft 17 pNFS review on Dec 4th 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 those that are attending the IETF meeting in a couple of weeks... There will be another walk through of the pNFS related sections of draft 17. This will occur in the late afternoon/early evening of Dec 4th in Vancouver. Exact times and location are yet to be determined. If you would like to attend/participate, please send me email such that I can include you on the final details. Note that this is a design/I-D detailed review and not the NFSv4 working group meeting; that is Dec 5th in the morning. Thanks, Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 20 11:55: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 1IuWN5-0001ph-9Y; Tue, 20 Nov 2007 11:54:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWN4-0001pN-2Z for nfsv4@ietf.org; Tue, 20 Nov 2007 11:54:46 -0500 Received: from web38103.mail.mud.yahoo.com ([209.191.124.130]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuWN1-0007zD-Nb for nfsv4@ietf.org; Tue, 20 Nov 2007 11:54:46 -0500 Received: (qmail 45743 invoked by uid 60001); 20 Nov 2007 16:54:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=BTD+BFY7r1n+1y/mKx4sPEtpQkQHcZ5ZUF9bLJgqJb5Zm8Gj6qA8JZz7y3kSWxHI48GSXzBLtpI/Kb9ZdBgHC1AdyZ/R5/j7Mkbe15jDic8B94nXp2Gmx6nUXoPBjqaEKmAIQxJ25pfPjyoN+JkjdS0lIOOvUlzhmodBBzENUys=; X-YMail-OSG: _o2QLvsVM1nLPg5QGMl4Iu7h2EuiFoNSNbxkQm5se1JNvH3Dp6VKq0wXWkUO8Koe2PHBwC_Xpg-- Received: from [198.95.226.230] by web38103.mail.mud.yahoo.com via HTTP; Tue, 20 Nov 2007 08:54:43 PST Date: Tue, 20 Nov 2007 08:54:43 -0800 (PST) From: Mike Eisler To: nfsv4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <249496.44610.qm@web38103.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [nfsv4] odd text in RFC3530's LOCK description X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Some servers may only support locking for byte offsets that fit within 32 bits. If the client specifies a range that includes a byte beyond the last byte offset of the 32-bit range, but does not include the last byte offset of the 32-bit and all of the byte offsets beyond it, up to the end of the valid 64-bit range, such a 32-bit server MUST return the error NFS4ERR_BAD_RANGE. I don't know what the above is trying to say, but wonder if it is saying: 32 bit servers are servers that support locking for byte offsets that fit within 32 bits (i.e. less than or equal to 0xFFFFFFFF). If the client specifies a range that overlaps one or more bytes beyond offset 0xFFFFFFFF, but does not end at the maximum 64 bit offset (i.e. 0xFFFFFFFFFFFFFFFF), such a 32-bit server MUST return the error NFS4ERR_BAD_RANGE. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 20 12:11: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 1IuWde-0005lK-Hr; Tue, 20 Nov 2007 12:11:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuWdc-0005l3-Mf for nfsv4@ietf.org; Tue, 20 Nov 2007 12:11:52 -0500 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 1IuWdc-00012e-Bi for nfsv4@ietf.org; Tue, 20 Nov 2007 12:11:52 -0500 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 lAKHBpjp015995; Tue, 20 Nov 2007 12:11:51 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 20 Nov 2007 12:11:51 -0500 Received: from fs1.bhalevy.com ([172.17.28.115]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 12:11:51 -0500 Message-ID: <47431555.3010907@panasas.com> Date: Tue, 20 Nov 2007 19:11:49 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: email2mre-ietf@yahoo.com Subject: Re: [nfsv4] odd text in RFC3530's LOCK description References: <249496.44610.qm@web38103.mail.mud.yahoo.com> In-Reply-To: <249496.44610.qm@web38103.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2007 17:11:51.0540 (UTC) FILETIME=[71448B40:01C82B98] 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 Nov. 20, 2007, 18:54 +0200, Mike Eisler wrote: > Some servers may only support locking for byte offsets that fit > within 32 bits. If the client specifies a range that includes a > byte > beyond the last byte offset of the 32-bit range, but does not > include > the last byte offset of the 32-bit and all of the byte offsets > beyond > it, up to the end of the valid 64-bit range, such a 32-bit server > MUST return the error NFS4ERR_BAD_RANGE. > > I don't know what the above is trying to say, but wonder > if it is saying: > > 32 bit servers are servers that support locking > for byte offsets that fit within 32 bits (i.e. less than > or equal to 0xFFFFFFFF). If the > client specifies a range that overlaps one or more bytes > beyond offset 0xFFFFFFFF, but does not end at the > maximum 64 bit offset (i.e. 0xFFFFFFFFFFFFFFFF), such a > 32-bit server MUST return the error NFS4ERR_BAD_RANGE. > almost... If the range doesn't overlap with 0xFFFFFFFF such server should also return NFS4ERR_BAD_RANGE. so the cases for for which the server should return the error are: start_offset > 0xFFFFFFFF || end_offset != 0xFFFFFFFFFFFFFFFF Benny _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 20 12:39: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 1IuX4i-0008NC-HH; Tue, 20 Nov 2007 12:39:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuX4h-0008KD-Fw for nfsv4@ietf.org; Tue, 20 Nov 2007 12:39:51 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuX4h-0002CY-0K for nfsv4@ietf.org; Tue, 20 Nov 2007 12:39:51 -0500 X-IronPort-AV: E=Sophos;i="4.21,442,1188802800"; d="scan'208";a="124325175" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 20 Nov 2007 09:39:19 -0800 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 lAKHdJWw024828; Tue, 20 Nov 2007 09:39:19 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 09:39:19 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 09:39:19 -0800 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] odd text in RFC3530's LOCK description Date: Tue, 20 Nov 2007 12:39:16 -0500 Message-ID: In-Reply-To: <249496.44610.qm@web38103.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] odd text in RFC3530's LOCK description Thread-Index: AcgrlpZM/HYgKZRnRYyDFtQr9YVQ9QAAtOug From: "Noveck, Dave" To: , X-OriginalArrivalTime: 20 Nov 2007 17:39:19.0085 (UTC) FILETIME=[4747F5D0:01C82B9C] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 think you are headed inn the right directtion but your formulation would not require a 32-bit server to return NFS4ERR_BADRANGE if the=20 client specified a range that started at 0x100000000 and ended at=20 0xFFFFFFFFFFFFFFFF, while the paragraph in RFC3530, would. Your paragraph delas with where the range ends but doesn't deal with where the range starts, which must be at or below 0xFFFFFFFF, to=20 avoid NFS4ERR_BAD_RANGE. -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Tuesday, November 20, 2007 11:55 AM To: nfsv4@ietf.org Subject: [nfsv4] odd text in RFC3530's LOCK description Some servers may only support locking for byte offsets that fit within 32 bits. If the client specifies a range that includes a byte beyond the last byte offset of the 32-bit range, but does not include the last byte offset of the 32-bit and all of the byte offsets beyond it, up to the end of the valid 64-bit range, such a 32-bit server MUST return the error NFS4ERR_BAD_RANGE. I don't know what the above is trying to say, but wonder if it is saying: 32 bit servers are servers that support locking=20 for byte offsets that fit within 32 bits (i.e. less than=20 or equal to 0xFFFFFFFF). If the =20 client specifies a range that overlaps one or more bytes beyond offset 0xFFFFFFFF, but does not end at the=20 maximum 64 bit offset (i.e. 0xFFFFFFFFFFFFFFFF), such a=20 32-bit server MUST return the error NFS4ERR_BAD_RANGE. _______________________________________________ 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 Nov 20 13:26: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 1IuXnJ-0004HK-SE; Tue, 20 Nov 2007 13:25:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXnI-00047A-8p for nfsv4@ietf.org; Tue, 20 Nov 2007 13:25:56 -0500 Received: from 209-198-142-2-host.prismnet.net ([209.198.142.2] helo=smtp.opengridcomputing.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuXnH-0004KA-VY for nfsv4@ietf.org; Tue, 20 Nov 2007 13:25:56 -0500 Received: from [10.10.0.248] (trinity.ogc.int [10.10.0.248]) by smtp.opengridcomputing.com (Postfix) with ESMTP id 48A7A7C72D; Tue, 20 Nov 2007 12:25:55 -0600 (CST) Subject: Re: [nfsv4] NFSv4.1 draft 17 pNFS review on Dec 4th From: Tom Tucker To: Spencer Shepler In-Reply-To: <933ED09D-CC52-4F35-898B-918FF60CC491@sun.com> References: <933ED09D-CC52-4F35-898B-918FF60CC491@sun.com> Content-Type: text/plain Organization: Open Grid Computing, Inc. Date: Tue, 20 Nov 2007 12:28:59 -0600 Message-Id: <1195583339.27217.7.camel@trinity.ogc.int> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 Spencer: This link looks dead to me. Am I the only one? https://www1.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-17.txt On Tue, 2007-11-20 at 01:17 -0600, Spencer Shepler wrote: > For those that are attending the IETF meeting in a couple of weeks... > > There will be another walk through of the pNFS related sections > of draft 17. This will occur in the late afternoon/early evening > of Dec 4th in Vancouver. Exact times and location are yet > to be determined. If you would like to attend/participate, > please send me email such that I can include you on the > final details. > > Note that this is a design/I-D detailed review and not > the NFSv4 working group meeting; that is Dec 5th in the > morning. > > 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 Tue Nov 20 13:29: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 1IuXqk-0004vX-23; Tue, 20 Nov 2007 13:29:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXqi-0004uT-Ao for nfsv4@ietf.org; Tue, 20 Nov 2007 13:29:28 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuXqg-0003KU-JV for nfsv4@ietf.org; Tue, 20 Nov 2007 13:29:28 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1685753nfb for ; Tue, 20 Nov 2007 10:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; bh=0lR3tzxir+TPXU25FzPQZlp9DoL6NgkwpQdV9/97IMg=; b=lQ9Ydlm2+WZbCCD/VJLSVTy/X4SgJkARrRUB/EYqVyff6fe0PPpjni5JHrUBtxrx+ZNXslZFki5jo4tD+UHCAh9cva6sN708jGWng/mYAEl/gYnbzSnhcmAxSIKpHdZIVgRgYhrPVaWIWXRTWzu3+u+Ab/DY24hO64Rj6CkNX1U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=UUpvNDJjSQROTLdP/qyLh/BjDU6lafPoIfKiNArvCBQMbMCuhCt6t78hz4gf8Xb5CUbByHQB52dMgzuSR9dqk+OKHmM/7XCOXxDgix9Rb2n5tsMM69fD70apKvUFgjJISXfRoNtY1aK4V+AETf1FeJuZNOO9BQH45Ulrj3yvqIQ= Received: by 10.86.49.13 with SMTP id w13mr6438975fgw.1195583365388; Tue, 20 Nov 2007 10:29:25 -0800 (PST) Received: by 10.86.51.8 with HTTP; Tue, 20 Nov 2007 10:29:25 -0800 (PST) Message-ID: <78771fdc0711201029q887b8a3h999c1b76b35ff698@mail.gmail.com> Date: Tue, 20 Nov 2007 10:29:25 -0800 From: PMR To: "Tom Tucker" Subject: Re: [nfsv4] NFSv4.1 draft 17 pNFS review on Dec 4th In-Reply-To: <1195583339.27217.7.camel@trinity.ogc.int> MIME-Version: 1.0 References: <933ED09D-CC52-4F35-898B-918FF60CC491@sun.com> <1195583339.27217.7.camel@trinity.ogc.int> X-Google-Sender-Auth: 3ea18de03c3ff605 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Spencer Shepler , NFSv4 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pryce@ucla.edu List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092715213==" Errors-To: nfsv4-bounces@ietf.org --===============0092715213== Content-Type: multipart/alternative; boundary="----=_Part_31156_16316156.1195583365381" ------=_Part_31156_16316156.1195583365381 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline That link is dead to me too. Paul On Nov 20, 2007 10:28 AM, Tom Tucker wrote: > Spencer: > > This link looks dead to me. Am I the only one? > > > https://www1.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-17.txt > > > On Tue, 2007-11-20 at 01:17 -0600, Spencer Shepler wrote: > > For those that are attending the IETF meeting in a couple of weeks... > > > > There will be another walk through of the pNFS related sections > > of draft 17. This will occur in the late afternoon/early evening > > of Dec 4th in Vancouver. Exact times and location are yet > > to be determined. If you would like to attend/participate, > > please send me email such that I can include you on the > > final details. > > > > Note that this is a design/I-D detailed review and not > > the NFSv4 working group meeting; that is Dec 5th in the > > morning. > > > > 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 > -- http://covertheuninsured.org/ http://www.nrdcaction.org/gwtakeaction http://www.nrdcactionfund.org/tellafriend.asp http://www.savetheinternet.com ------=_Part_31156_16316156.1195583365381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline That link is dead to me too.

Paul

On Nov 20, 2007 10:28 AM, Tom Tucker <tom@opengridcomputing.com> wrote:
Spencer:

This link looks dead to me. Am I the only one?

https://www1.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-17.txt


On Tue, 2007-11-20 at 01:17 -0600, Spencer Shepler wrote:
> For those that are attending the IETF meeting in a couple of weeks...
>
> There will be another walk through of the pNFS related sections
> of draft 17.  This will occur in the late afternoon/early evening
> of Dec 4th in Vancouver.  Exact times and location are yet
> to be determined.  If you would like to attend/participate,
> please send me email such that I can include you on the
> final details.
>
> Note that this is a design/I-D detailed review and not
> the NFSv4 working group meeting; that is Dec 5th in the
> morning.
>
> 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



--
http://covertheuninsured.org/
http://www.nrdcaction.org/gwtakeaction
http://www.nrdcactionfund.org/tellafriend.asp
http://www.savetheinternet.com ------=_Part_31156_16316156.1195583365381-- --===============0092715213== 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 --===============0092715213==-- From nfsv4-bounces@ietf.org Tue Nov 20 13:43:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuY4J-0006rX-Uo; Tue, 20 Nov 2007 13:43:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuY4J-0006rS-6g for nfsv4@ietf.org; Tue, 20 Nov 2007 13:43:31 -0500 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 1IuY4G-0004Cj-F6 for nfsv4@ietf.org; Tue, 20 Nov 2007 13:43:31 -0500 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 lAKIhSCU018294; Tue, 20 Nov 2007 13:43:28 -0500 Received: from 172.17.1.41 ([172.17.1.41] helo=riverside.int.panasas.com) by ASSP-nospam; 20 Nov 2007 13:43:28 -0500 Received: from fs1.bhalevy.com ([172.17.28.115]) by riverside.int.panasas.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Nov 2007 13:43:27 -0500 Message-ID: <47432ACD.3010807@panasas.com> Date: Tue, 20 Nov 2007 20:43:25 +0200 From: Benny Halevy User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: pryce@ucla.edu, Tom Tucker Subject: Re: [nfsv4] NFSv4.1 draft 17 pNFS review on Dec 4th References: <933ED09D-CC52-4F35-898B-918FF60CC491@sun.com> <1195583339.27217.7.camel@trinity.ogc.int> <78771fdc0711201029q887b8a3h999c1b76b35ff698@mail.gmail.com> In-Reply-To: <78771fdc0711201029q887b8a3h999c1b76b35ff698@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Nov 2007 18:43:28.0009 (UTC) FILETIME=[3D6B2790:01C82BA5] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Spencer Shepler , 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 try http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-17.txt PMR wrote: > That link is dead to me too. > > Paul > > On Nov 20, 2007 10:28 AM, Tom Tucker wrote: > >> Spencer: >> >> This link looks dead to me. Am I the only one? >> >> >> https://www1.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-17.txt >> >> >> On Tue, 2007-11-20 at 01:17 -0600, Spencer Shepler wrote: >>> For those that are attending the IETF meeting in a couple of weeks... >>> >>> There will be another walk through of the pNFS related sections >>> of draft 17. This will occur in the late afternoon/early evening >>> of Dec 4th in Vancouver. Exact times and location are yet >>> to be determined. If you would like to attend/participate, >>> please send me email such that I can include you on the >>> final details. >>> >>> Note that this is a design/I-D detailed review and not >>> the NFSv4 working group meeting; that is Dec 5th in the >>> morning. >>> >>> 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 >> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 -- Benny Halevy Software Architect Tel/Fax: +972-3-647-8340 Mobile: +972-54-802-8340 US: +1-412-203-3187 bhalevy@panasas.com Panasas, Inc. Leader in Parallel Storage www.panasas.com _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Tue Nov 20 13:45: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 1IuY67-00085V-EP; Tue, 20 Nov 2007 13:45:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuY65-00083j-HC for nfsv4@ietf.org; Tue, 20 Nov 2007 13:45:21 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuY64-0005Tn-Qd for nfsv4@ietf.org; Tue, 20 Nov 2007 13:45:21 -0500 X-IronPort-AV: E=Sophos;i="4.21,442,1188802800"; d="scan'208,217";a="124346870" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 20 Nov 2007 10:45:16 -0800 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 lAKIjFjv012581; Tue, 20 Nov 2007 10:45:15 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 10:45:15 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 10:45:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [nfsv4] NFSv4.1 draft 17 pNFS review on Dec 4th Date: Tue, 20 Nov 2007 13:45:13 -0500 Message-ID: In-Reply-To: <78771fdc0711201029q887b8a3h999c1b76b35ff698@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] NFSv4.1 draft 17 pNFS review on Dec 4th Thread-Index: Acgro1m+HliUuumyTxmcypylubjjFwAAe6lA From: "Noveck, Dave" To: , "Tom Tucker" X-OriginalArrivalTime: 20 Nov 2007 18:45:15.0381 (UTC) FILETIME=[7D6AD250:01C82BA5] X-Spam-Score: 2.5 (++) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: Spencer Shepler , 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="===============1787392389==" Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. --===============1787392389== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82BA5.7CA035AA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82BA5.7CA035AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I changed www1 to www and it worked (or at least I got a document of the appropriate length). ________________________________ From: PMR [mailto:pryce@ucla.edu]=20 Sent: Tuesday, November 20, 2007 1:29 PM To: Tom Tucker Cc: Spencer Shepler; NFSv4 Subject: Re: [nfsv4] NFSv4.1 draft 17 pNFS review on Dec 4th That link is dead to me too. Paul On Nov 20, 2007 10:28 AM, Tom Tucker wrote: Spencer: =09 This link looks dead to me. Am I the only one? =09 =09 https://www1.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-17. txt=20 =09 =09 On Tue, 2007-11-20 at 01:17 -0600, Spencer Shepler wrote: > For those that are attending the IETF meeting in a couple of weeks... > > There will be another walk through of the pNFS related sections=20 > of draft 17. This will occur in the late afternoon/early evening > of Dec 4th in Vancouver. Exact times and location are yet > to be determined. If you would like to attend/participate, > please send me email such that I can include you on the=20 > final details. > > Note that this is a design/I-D detailed review and not > the NFSv4 working group meeting; that is Dec 5th in the > morning. > > Thanks, > Spencer >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www1.ietf.org/mailman/listinfo/nfsv4 =09 =09 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 =09 --=20 http://covertheuninsured.org/ http://www.nrdcaction.org/gwtakeaction=20 http://www.nrdcactionfund.org/tellafriend.asp http://www.savetheinternet.com=20 ------_=_NextPart_001_01C82BA5.7CA035AA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I changed www1 to www and it worked (or at = least I got a=20 document of the appropriate length).

From: PMR [mailto:pryce@ucla.edu]=20
Sent: Tuesday, November 20, 2007 1:29 PM
To: Tom=20 Tucker
Cc: Spencer Shepler; NFSv4
Subject: Re: = [nfsv4]=20 NFSv4.1 draft 17 pNFS review on Dec 4th

That link is dead to me too.

Paul

On Nov 20, 2007 10:28 AM, Tom Tucker <tom@opengridcomputing.com&g= t;=20 wrote:
Spencer:

This=20 link looks dead to me. Am I the only one?

https://www1.ietf.org/internet-drafts/draft-ietf-nfsv4-mi= norversion1-17.txt=20


On Tue, 2007-11-20 at 01:17 -0600, Spencer Shepler=20 wrote:
> For those that are attending the IETF meeting in a = couple of=20 weeks...
>
> There will be another walk through of the = pNFS=20 related sections
> of draft 17.  This will occur in the = late=20 afternoon/early evening
> of Dec 4th in Vancouver.  Exact = times and=20 location are yet
> to be determined.  If you would like to=20 attend/participate,
> please send me email such that I can = include you=20 on the
> final details.
>
> Note that this is a = design/I-D=20 detailed review and not
> the NFSv4 working group meeting; that = is Dec=20 5th in the
> morning.
>
> Thanks,
> = Spencer
>=20
> _______________________________________________
> nfsv4 = mailing=20 list
> nfsv4@ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4

<= BR>_______________________________________________
nfsv4=20 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4


--
http://covertheuninsured.org/<= BR>http://www.nrdcaction.org= /gwtakeaction=20
http://www.nrdcact= ionfund.org/tellafriend.asp
http://www.savetheinternet.com=20 ------_=_NextPart_001_01C82BA5.7CA035AA-- --===============1787392389== 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 --===============1787392389==-- From nfsv4-bounces@ietf.org Tue Nov 20 14:35: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 1IuYsG-0002F2-OU; Tue, 20 Nov 2007 14:35:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYsF-0002Ek-Ny for nfsv4@ietf.org; Tue, 20 Nov 2007 14:35:07 -0500 Received: from 209-198-142-2-host.prismnet.net ([209.198.142.2] helo=smtp.opengridcomputing.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuYsF-0007jj-7S for nfsv4@ietf.org; Tue, 20 Nov 2007 14:35:07 -0500 Received: from [10.10.0.248] (trinity.ogc.int [10.10.0.248]) by smtp.opengridcomputing.com (Postfix) with ESMTP id CDC8E7C72D; Tue, 20 Nov 2007 13:35:06 -0600 (CST) Subject: RE: [nfsv4] NFSv4.1 draft 17 pNFS review on Dec 4th From: Tom Tucker To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Organization: Open Grid Computing, Inc. Date: Tue, 20 Nov 2007 13:38:11 -0600 Message-Id: <1195587491.27217.12.camel@trinity.ogc.int> Mime-Version: 1.0 X-Mailer: Evolution 2.12.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.6 (++) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Spencer Shepler , 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 Hmm...maybe the content hasn't been completely distributed to all the web servers? On Tue, 2007-11-20 at 13:45 -0500, Noveck, Dave wrote: > I changed www1 to www and it worked (or at least I got a document of > the appropriate length). > > > ______________________________________________________________________ > From: PMR [mailto:pryce@ucla.edu] > Sent: Tuesday, November 20, 2007 1:29 PM > To: Tom Tucker > Cc: Spencer Shepler; NFSv4 > Subject: Re: [nfsv4] NFSv4.1 draft 17 pNFS review on Dec 4th > > > > That link is dead to me too. > > Paul > > On Nov 20, 2007 10:28 AM, Tom Tucker > wrote: > Spencer: > > This link looks dead to me. Am I the only one? > > https://www1.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-17.txt > > > On Tue, 2007-11-20 at 01:17 -0600, Spencer Shepler wrote: > > For those that are attending the IETF meeting in a couple of > weeks... > > > > There will be another walk through of the pNFS related > sections > > of draft 17. This will occur in the late afternoon/early > evening > > of Dec 4th in Vancouver. Exact times and location are yet > > to be determined. If you would like to attend/participate, > > please send me email such that I can include you on the > > final details. > > > > Note that this is a design/I-D detailed review and not > > the NFSv4 working group meeting; that is Dec 5th in the > > morning. > > > > 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 > > > > -- > http://covertheuninsured.org/ > http://www.nrdcaction.org/gwtakeaction > http://www.nrdcactionfund.org/tellafriend.asp > http://www.savetheinternet.com _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Larivieretcn@gg.com.br Tue Nov 20 14:42:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYzm-0005BD-TN for nfsv4-archive@lists.ietf.org; Tue, 20 Nov 2007 14:42:54 -0500 Received: from catv-5665a6f1.catv.broadband.hu ([86.101.166.241]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuYzm-00080i-6X for nfsv4-archive@lists.ietf.org; Tue, 20 Nov 2007 14:42:54 -0500 Received: from mad ([198.110.66.64] helo=mad) by catv-5665a6f1.catv.broadband.hu ( sendmail 8.13.3/8.13.1) with esmtpa id 1yaMYW-000VTW-Yj for nfsv4-archive@lists.ietf.org; Tue, 20 Nov 2007 20:43:50 +0100 Message-ID: <000901c82bad$99222ef0$f1a66556@mad> From: "Brice Lariviere" To: nfsv4-archive@lists.ietf.org Subject: onhoudba Date: Tue, 20 Nov 2007 20:43:17 +0100 Message-ID: <000901c82bad$99222ef0$f1a66556@mad> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.7 (++++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Fight for your success with a maid of your dream ismar Hartman http://www.expectprint.com/ From nfsv4-bounces@ietf.org Tue Nov 20 15:07: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 1IuZNp-00014h-O5; Tue, 20 Nov 2007 15:07:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuZNo-00014Y-F4 for nfsv4@ietf.org; Tue, 20 Nov 2007 15:07:44 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuZNo-0000ea-1b for nfsv4@ietf.org; Tue, 20 Nov 2007 15:07:44 -0500 X-IronPort-AV: E=Sophos;i="4.21,443,1188802800"; d="scan'208";a="124373590" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 20 Nov 2007 12:07:43 -0800 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 lAKK7hlV002119; Tue, 20 Nov 2007 12:07:43 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 12:07:43 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 12:07:42 -0800 Received: from tmt.netapp.com ([10.30.32.47]) by exnane01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 20 Nov 2007 15:07:41 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2007 15:06:53 -0500 To: Tom Tucker From: "Talpey, Thomas" Subject: RE: [nfsv4] NFSv4.1 draft 17 pNFS review on Dec 4th In-Reply-To: <1195587491.27217.12.camel@trinity.ogc.int> References: <1195587491.27217.12.camel@trinity.ogc.int> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: X-OriginalArrivalTime: 20 Nov 2007 20:07:41.0443 (UTC) FILETIME=[017FFD30:01C82BB1] X-Spam-Score: 2.5 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 At 02:38 PM 11/20/2007, Tom Tucker wrote: > >Hmm...maybe the content hasn't been completely distributed to all the >web servers? You can also go here: http://nfsv4-editor.org/drafts/drafts.html ...where you can also find the (much) more useful html version: http://www.nfsv4-editor.org/draft17/draft-ietf-nfsv4-minorversion1-17.html Tom. > >On Tue, 2007-11-20 at 13:45 -0500, Noveck, Dave wrote: >> I changed www1 to www and it worked (or at least I got a document of >> the appropriate length). >> >> >> ______________________________________________________________________ >> From: PMR [mailto:pryce@ucla.edu] >> Sent: Tuesday, November 20, 2007 1:29 PM >> To: Tom Tucker >> Cc: Spencer Shepler; NFSv4 >> Subject: Re: [nfsv4] NFSv4.1 draft 17 pNFS review on Dec 4th >> >> >> >> That link is dead to me too. >> >> Paul >> >> On Nov 20, 2007 10:28 AM, Tom Tucker >> wrote: >> Spencer: >> >> This link looks dead to me. Am I the only one? >> >> >https://www1.ietf.org/internet-drafts/draft-ietf-nfsv4-minorversion1-17.txt >> >> >> On Tue, 2007-11-20 at 01:17 -0600, Spencer Shepler wrote: >> > For those that are attending the IETF meeting in a couple of >> weeks... >> > >> > There will be another walk through of the pNFS related >> sections >> > of draft 17. This will occur in the late afternoon/early >> evening >> > of Dec 4th in Vancouver. Exact times and location are yet >> > to be determined. If you would like to attend/participate, >> > please send me email such that I can include you on the >> > final details. >> > >> > Note that this is a design/I-D detailed review and not >> > the NFSv4 working group meeting; that is Dec 5th in the >> > morning. >> > >> > Thanks, >> > Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From LiMcConway@proximaweb.com Tue Nov 20 17:55:42 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuc0M-0002YO-QB for nfsv4-archive@lists.ietf.org; Tue, 20 Nov 2007 17:55:42 -0500 Received: from [189.13.191.3] (helo=18913194089.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuc0M-0008RC-1v for nfsv4-archive@lists.ietf.org; Tue, 20 Nov 2007 17:55:42 -0500 Received: from Deryck ([150.196.160.97] helo=Deryck) by 18913194089.user.veloxzone.com.br ( sendmail 8.13.3/8.13.1) with esmtpa id 1aWAee-000SWG-FH for nfsv4-archive@lists.ietf.org; Tue, 20 Nov 2007 19:56:22 -0300 Message-ID: <000e01c82bc8$7e45b410$59c20dbd@Deryck> From: "Li McConway" To: Subject: edreedlo Date: Tue, 20 Nov 2007 19:55:49 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C82BAF.58F87C10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 ------=_NextPart_000_0008_01C82BAF.58F87C10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Get it bigger and no lassie can resist Randy molenaar http://www.methodoxygen.com/ ------=_NextPart_000_0008_01C82BAF.58F87C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Get it bigger and no lassie can = resist
Randy molenaar
http://www.methodoxygen.com/
------=_NextPart_000_0008_01C82BAF.58F87C10-- From nfsv4-bounces@ietf.org Wed Nov 21 14:46: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 1IuvX7-0002Qe-P4; Wed, 21 Nov 2007 14:46:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuvX7-0002QZ-G0 for nfsv4@ietf.org; Wed, 21 Nov 2007 14:46:49 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuvX3-0000pw-4o for nfsv4@ietf.org; Wed, 21 Nov 2007 14:46:49 -0500 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id lALIjgbx002857 for ; Wed, 21 Nov 2007 13:45:42 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lALJkiWR126832 for ; Wed, 21 Nov 2007 12:46:44 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lALJkiVN009103 for ; Wed, 21 Nov 2007 12:46:44 -0700 Received: from d03nm115.boulder.ibm.com (d03nm115.boulder.ibm.com [9.17.195.141]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lALJki4k009094 for ; Wed, 21 Nov 2007 12:46:44 -0700 Auto-Submitted: auto-generated From: Tom Beglin To: nfsv4@ietf.org Message-ID: Date: Wed, 21 Nov 2007 12:46:42 -0700 X-MIMETrack: Serialize by Router on D03NM115/03/M/IBM(Release 8.0|August 02, 2007) at 11/21/2007 12:46:43 MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [nfsv4] Tom Beglin/Tucson/IBM is out of the office. 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="===============0614623964==" Errors-To: nfsv4-bounces@ietf.org --===============0614623964== Content-type: multipart/alternative; Boundary="0__=08BBF909DFFF23FE8f9e8a93df938690918c08BBF909DFFF23FE" Content-Disposition: inline --0__=08BBF909DFFF23FE8f9e8a93df938690918c08BBF909DFFF23FE Content-type: text/plain; charset=US-ASCII I will be out of the office starting 11/19/2007 and will not return until 11/26/2007. --0__=08BBF909DFFF23FE8f9e8a93df938690918c08BBF909DFFF23FE Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 11/19/2007 and will not return until 11/26/2007.

--0__=08BBF909DFFF23FE8f9e8a93df938690918c08BBF909DFFF23FE-- --===============0614623964== 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 --===============0614623964==-- From nfsv4-bounces@ietf.org Wed Nov 21 15:31: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 1IuwE4-0003M5-Ds; Wed, 21 Nov 2007 15:31:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwE3-0003La-5t for nfsv4@ietf.org; Wed, 21 Nov 2007 15:31:11 -0500 Received: from ccshst09.cs.uoguelph.ca ([131.104.94.206]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuwE2-0007py-ND for nfsv4@ietf.org; Wed, 21 Nov 2007 15:31:11 -0500 Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ccshst09.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id lALKV17X028838 for ; Wed, 21 Nov 2007 15:31:03 -0500 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id lALKVtW16703 for ; Wed, 21 Nov 2007 15:31:55 -0500 (EST) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 21 Nov 2007 15:31:55 -0500 (EST) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: nfsv4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.206 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [nfsv4] current nfsv4 client for Tiger 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 case anyone who is a Mac lover wants to try my client that is using delegations aggressively, I now have a Tiger port of my current client on the ftp site (ftp.cis.uoguelph.ca/pub/nfsv4/darwin-port). There is binaries for a Kext and utilities in the tarball, so running a kernel built from modified sources is no longer necessary. I hope to have a port to Leopard going by Jan 2008, but?? Have fun with it, if you try it, rick _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Antonin645@controlgerencial.com Wed Nov 21 16:15:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuwue-0004SA-A9 for nfsv4-archive@lists.ietf.org; Wed, 21 Nov 2007 16:15:12 -0500 Received: from [200.24.5.142] (helo=[200.24.5.142]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuwuZ-0001RZ-2z for nfsv4-archive@lists.ietf.org; Wed, 21 Nov 2007 16:15:12 -0500 Received: from acartera by controlgerencial.com with ASMTP id 9520447B for ; Wed, 21 Nov 2007 16:15:31 -0500 Received: from acartera ([129.128.97.191]) by controlgerencial.com with ESMTP id 3FA13E73930E for ; Wed, 21 Nov 2007 16:15:31 -0500 Message-ID: <000401c82c83$950db2e0$8e0518c8@acartera> From: "Antonin DeBora" To: Subject: erphoria Date: Wed, 21 Nov 2007 16:15:03 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C82C59.AC37AAE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 ------=_NextPart_000_0007_01C82C59.AC37AAE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Our new chemical, will let you be able to get the desired size of your = PE and attract any filly you desire maert kozenec http://feetso.com/ ------=_NextPart_000_0007_01C82C59.AC37AAE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Our new chemical, will let you be = able to get=20 the desired size of your PE and attract any filly you = desire
maert kozenec
http://feetso.com/
------=_NextPart_000_0007_01C82C59.AC37AAE0-- From KeithphenolCollins@economist.com Wed Nov 21 16:56:48 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxYt-0000VW-Uw; Wed, 21 Nov 2007 16:56:47 -0500 Received: from [200.88.31.183] (helo=pc2) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuxYt-0003a8-AS; Wed, 21 Nov 2007 16:56:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host72637120.economist.com (8.13.1/8.13.1) with SMTP id 3pvIB9aG16.141331.T0X.iYN.3917186086064 for ; Wed, 24 Oct 2007 17:57:47 +0600 Message-ID: <6ea101c81699$bdc52380$2600000a@PC2> From: "Justin Edwards" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_6E9D_01C81699.BDC52380-- From DarrenhomesteadMedina@williepbennett.com Wed Nov 21 18:36:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuz7D-0005ny-Ec; Wed, 21 Nov 2007 18:36:19 -0500 Received: from pool-71-172-48-133.nwrknj.fios.verizon.net ([71.172.48.133] helo=dell1.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iuz7D-00083d-4m; Wed, 21 Nov 2007 18:36:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host10755211.williepbennett.com (8.13.1/8.13.1) with SMTP id cdd84DE491.670945.b67.vIL.8938840988800 for ; Wed, 21 Nov 2007 18:32:58 +0500 Message-ID: From: "Lonnie Burke" To: Subject: Approval process Date: Wed, 21 Nov 2007 18:32:58 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_A08B_01C82C97.415236D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_A08B_01C82C97.415236D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_A08B_01C82C97.415236D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_A08B_01C82C97.415236D0-- From nfsv4-bounces@ietf.org Wed Nov 21 18:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuzMl-00075g-Bs; Wed, 21 Nov 2007 18:52:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuzMj-00075R-Sm for nfsv4@ietf.org; Wed, 21 Nov 2007 18:52:21 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuzMj-0000az-22 for nfsv4@ietf.org; Wed, 21 Nov 2007 18:52:21 -0500 Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lALNqK2T003682; Wed, 21 Nov 2007 18:52:20 -0500 (EST) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Wed, 21 Nov 2007 18:52:17 -0500 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 lALNqAu2029667; Wed, 21 Nov 2007 18:52:14 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 18:52:13 -0500 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] Issue in LAYOUTRETURN Date: Wed, 21 Nov 2007 18:52:12 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [nfsv4] Issue in LAYOUTRETURN Thread-index: AcgrGeMbSUZC4jiCT0Gh2SJN2R947gBfs97Q References: <4A3FA24D-EEEB-41E5-8D7D-4E0A76082FF7@sun.com> To: , X-OriginalArrivalTime: 21 Nov 2007 23:52:13.0469 (UTC) FILETIME=[89DDC4D0:01C82C99] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 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-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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 Spencer, I should let Jason elaborate further, as he's closer to these implementations, but here are some initial answers: > Can you add some words or experience to the case where the client > is out-of-sync with the server? Is this by choice or by > implementation or protocol error? It can be by implementation choice, and can help with some protocol errors. We initially did it as an implementation choice. > > This allows some out-of- > > sync situations to be resolved cleanly, and allows some client > > optimizations to drop no-longer-needed state without having to talk > > to the server. >=20 > In the implementation you mention, does the client associate > layout information with cached pages and when those pages are > flushed the layout information is "dropped" and thus answering > my question above or is there some other condition that occurs, etc. Yes, that is an example, and it avoids having to return a layout when dropping clean pages from cache. > From the point of view of a protocol that requires the client and server > to share the layout state, the only time the client would need to > know exactly what it has is in the case where no recall of layout is > being done. In the servicing of the recall, the client can just pretend > it has the layouts for which the server is asking. Right - the ability of the client to drop state assumes that if the server needs something, it'll send a recall. > To support the forgetful client, the layoutreturn would need to > allow for a "0->max-range" layoutreturn and the stateid transition > would need to occur for that to signify that the server has > processed the request (even if no layouts were being held). Probably also a good idea, if the client wants to do the server a favor, enabling the server to not send a recall. > > One new wrinkle here is that client discard of clean state need > > not affect the stateid, and that probably falls into your category > > of "convince ourselves we have done it, and clearly explain in > > the spec, how that works." >=20 > Can you expand on what you intend by "client discard of clean state"? > What scenario does this describe? The discard of a clean page and associated layout state from the cache, as you summarized above. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer 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: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 > Sent: Monday, November 19, 2007 9:05 PM > To: NFSv4 > Subject: Re: [nfsv4] Issue in LAYOUTRETURN >=20 >=20 > On Nov 19, 2007, at 1:29 PM, Black_David@emc.com wrote: >=20 > > Dave, > > > > EMC has implementation experience from MPFS/FMP which suggests > > that moving from: > > > >> Go to a strict agreement model as Spencer is suggesting and > >> explain the protocol from that standpoint. > > > > to at least: > > > >> Figure out how to have that ability work together with > >> stateids, convince ourselves we have done it, and clearly > >> explain in the spec, how that works. > > > > has robustness and flexibility gains for client implementations. > > > > In the former case, when the server issues a return for a set of > > layouts and/or ranges, the client has to return *exactly* what > > the server thinks it has. Taken to its extreme limit, it can > > yield situations in which an out-of-sync client has no chance > > of working further with the server, and it imposes server > > communication costs on client decisions to drop otherwise-clean > > layout state. >=20 > Can you add some words or experience to the case where the client > is out-of-sync with the server? Is this by choice or by > implementation or protocol error? >=20 > > In the latter case, when the server issues a return for a set of > > layouts and/or ranges, the client has to get to a state in which > > it no longer has anything that needs to be returned and tell the > > server that it has reached that state. This allows some out-of- > > sync situations to be resolved cleanly, and allows some client > > optimizations to drop no-longer-needed state without having to talk > > to the server. >=20 > In the implementation you mention, does the client associate > layout information with cached pages and when those pages are > flushed the layout information is "dropped" and thus answering > my question above or is there some other condition that occurs, etc. >=20 > > > > The server can't tell these two situations apart for a client > > that issues returns based on "I don't have any of those". Think > > about the responses to the Old Maid "Give me all your 8's" > > request - whether or not the recipient had any 8's beforehand, > > she will have no 8's when her response is complete, and the > > latter is what the server actually cares about (no outstanding > > layout or range covered by issued recall). Of course, the client > > *must* absolutely respect the stateid protocol as part of this - > > getting confused about the stateid is generally fatal to continued > > use of the state protected by the stateid. >=20 > From the point of view of a protocol that requires the client and =20 > server > to share the layout state, the only time the client would need to > know exactly what it has is in the case where no recall of layout is > being done. In the servicing of the recall, the client can=20 > just pretend > it has the layouts for which the server is asking. >=20 > To support the forgetful client, the layoutreturn would need to > allow for a "0->max-range" layoutreturn and the stateid transition > would need to occur for that to signify that the server has > processed the request (even if no layouts were being held). >=20 > > One new wrinkle here is that client discard of clean state need > > not affect the stateid, and that probably falls into your category > > of "convince ourselves we have done it, and clearly explain in > > the spec, how that works." >=20 > Can you expand on what you intend by "client discard of clean state"? > What scenario does this describe? >=20 >=20 > Spencer >=20 >=20 > > The other new wrinkle is that if a > > client gets a recall for a layout that it has discarded, it needs > > to have a clean way to tell the server "I don't have that layout", > > and I believe that's already there as an error return to=20 > the callback. > > > > Thanks, > > --David > > > > >=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 MarisaprosaicLyles@people.com Thu Nov 22 06:11:05 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv9xZ-0006JZ-GZ; Thu, 22 Nov 2007 06:11:05 -0500 Received: from 49-35-241.dsl.iaw.on.ca ([69.49.35.241] helo=svtsem42) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iv9xZ-0001bx-1i; Thu, 22 Nov 2007 06:11:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host99702221.people.com (8.13.1/8.13.1) with SMTP id xAUcKqUu94.750706.QEJ.3Jr.3546612774040 for ; Thu, 22 Nov 2007 06:10:27 +0500 Message-ID: From: "Rosalind Suggs" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_C19F2_01C82CF8.57251A20-- From bert86ananth@OPTONLINE.NET Thu Nov 22 10:15:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDmE-0003o4-Sa for nfsv4-archive@lists.ietf.org; Thu, 22 Nov 2007 10:15:38 -0500 Received: from host148-199-dynamic.4-87-r.retail.telecomitalia.it ([87.4.199.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvDmE-0001yS-A4 for nfsv4-archive@lists.ietf.org; Thu, 22 Nov 2007 10:15:38 -0500 Received: from [87.4.199.148] by kadsgc.OPTONLINE.NET; Thu, 22 Nov 2007 15:15:06 +0000 Message-ID: <000a01c82d1a$07377490$78b46aa0@aqkbsrvl> From: "humberto lucius" To: "Lorenzo Ashley" Subject: Top-notch customer service Date: Thu, 22 Nov 2007 13:27:44 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C82D1A.0732DB8D" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 4.1 (++++) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C82D1A.0732DB8D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Watches - Over 8000 Styles Of Genuine Swiss Replica Watch.=20 http://westrfdonda.com/ ------=_NextPart_000_0007_01C82D1A.0732DB8D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Replica Watches - Over 8000 Styles Of Genuine Swiss Replica Watch. =

http://westrfdonda.com/ ------=_NextPart_000_0007_01C82D1A.0732DB8D-- From SamdeoxyribonucleicLane@rivals.com Thu Nov 22 10:37:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvE7p-0006LJ-Lp; Thu, 22 Nov 2007 10:37:57 -0500 Received: from 190-38-151-191.dyn.dsl.cantv.net ([190.38.151.191] helo=personal85518b) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvE7o-0002e1-VI; Thu, 22 Nov 2007 10:37:57 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host39697881.rivals.com (8.13.1/8.13.1) with SMTP id AlLTqNya65.015204.3FE.m6M.5721276426460 for ; Thu, 22 Nov 2007 11:37:07 +0400 Message-ID: <30a4ce01c82d1d$9a7f88d0$0365a8c0@personal85518b> From: "Corey Ruiz" To: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_30A4CA_01C82D1D.9A7F88D0-- From nfsv4-bounces@ietf.org Thu Nov 22 12:37:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFzO-0006cM-DV; Thu, 22 Nov 2007 12:37:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvFzN-0006bT-7Q for nfsv4@ietf.org; Thu, 22 Nov 2007 12:37:21 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvFzK-0008P4-Pj for nfsv4@ietf.org; Thu, 22 Nov 2007 12:37:21 -0500 X-IronPort-AV: E=Sophos;i="4.21,452,1188802800"; d="scan'208,217";a="125059483" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 22 Nov 2007 09:37:18 -0800 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 lAMHbHeS005324 for ; Thu, 22 Nov 2007 09:37:17 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 09:37:17 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 09:37:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Nov 2007 12:37:16 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: File types in v4.1 spec Thread-Index: AcgtLlMB/ZjDa9SRQ36eNZcyPGW/5Q== From: "Noveck, Dave" To: X-OriginalArrivalTime: 22 Nov 2007 17:37:17.0473 (UTC) FILETIME=[539EF110:01C82D2E] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [nfsv4] File types in v4.1 spec 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="===============0892029213==" Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. --===============0892029213== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82D2E.53022106" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82D2E.53022106 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Currently the values of the file type attribute (NF4*) do not appear in the spec, but are referred to all over the place. While you can argue that the actual values are more appropriate to the dotx, having all the valid values in one place would definitely help understanding. Note that "NF4REG" does not appear at all in draft-17. I guess the right place to put this is the section on the type attribute, ------_=_NextPart_001_01C82D2E.53022106 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Currently the values=20 of the file type attribute (NF4*) do not appear in the spec, but are = referred to=20 all over the place.  While you can argue that the actual values are = more=20 appropriate to the dotx, having all the valid values in one place would=20 definitely help understanding.  Note that "NF4REG" does not appear = at all=20 in draft-17.  I guess the right place to put this is the section on = the=20 type attribute,
------_=_NextPart_001_01C82D2E.53022106-- --===============0892029213== 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 --===============0892029213==-- From WilburnstahlPetty@porscheclub.com Thu Nov 22 15:49:39 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvIzT-0004hN-EZ; Thu, 22 Nov 2007 15:49:39 -0500 Received: from 80-218-242-50.dclient.hispeed.ch ([80.218.242.50] helo=mevisb487df863) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvIzT-0005KZ-0e; Thu, 22 Nov 2007 15:49:39 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host07316653.porscheclub.com (8.13.1/8.13.1) with SMTP id U2bfXSEk92.732318.avx.847.4335342298535 for ; Thu, 22 Nov 2007 21:49:12 -0100 Message-ID: <9a3001c82d49$3127e5e0$32f2da50@mevisb487df863> From: "Wilburn Cabrera" To: Subject: Hi Date: Thu, 22 Nov 2007 21:49:12 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_9A2C_01C82D49.3127E5E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_9A2C_01C82D49.3127E5E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 15 = minutes! The tests showed that the majority of men after taking this = medication were able to have perfect erection during 36 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $95.95 $34.19 30 tabs 60 doses $349.95 $104.66 60 tabs 120 doses $549.95 $180.15 90 tabs 180 doses $789.95 $242.06 180 tabs 360 doses $1325.95 $445.61 When you are young and stressed up… When you are aged and never give up… Cialis gives you confidence in any chance, every time. ------=_NextPart_000_9A2C_01C82D49.3127E5E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_9A2C_01C82D49.3127E5E0-- From Moninder-Distefano@dressen.nl Thu Nov 22 19:59:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvMt6-0005zw-8b for nfsv4-archive@lists.ietf.org; Thu, 22 Nov 2007 19:59:20 -0500 Received: from [201.51.75.151] (helo=20151060231.user.veloxzone.com.br) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvMt5-0005Y4-Ah for nfsv4-archive@lists.ietf.org; Thu, 22 Nov 2007 19:59:20 -0500 Received: by 10.154.203.74 with SMTP id aJRNICEsUupgO; Thu, 22 Nov 2007 22:59:23 -0200 (GMT) Received: by 192.168.192.172 with SMTP id nFxvJDdsYgtXmy.7743182567041; Thu, 22 Nov 2007 22:59:21 -0200 (GMT) Message-ID: <000c01c82d6c$13163700$e73c33c9@rafaela0edfbd2> From: "Moninder Distefano" To: nfsv4-archive@lists.ietf.org Subject: ravintom Date: Thu, 22 Nov 2007 22:59:18 -0200 Message-ID: <000c01c82d6c$13163700$e73c33c9@rafaela0edfbd2> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Drive women totaly wild in bed http://www.smileeat.com/ From AnnerunyonLutz@frenchkicks.com Fri Nov 23 07:05:49 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvXI5-0001ai-2k; Fri, 23 Nov 2007 07:05:49 -0500 Received: from cm60052.red91-117.mundo-r.com ([91.117.60.52] helo=lito71fd8e0e64.mundor.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvXI4-0006mT-0W; Fri, 23 Nov 2007 07:05:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host79537802.frenchkicks.com (8.13.1/8.13.1) with SMTP id 5qxo0Yi320.422677.xad.aWE.5766895502473 for ; Fri, 23 Nov 2007 13:04:59 -0100 Message-ID: From: "Phyllis Mcallister" To: Subject: Hi Date: Fri, 23 Nov 2007 13:04:59 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_FD6D7_01C82DC9.286B3490" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_FD6D7_01C82DC9.286B3490 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_FD6D7_01C82DC9.286B3490 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_FD6D7_01C82DC9.286B3490-- From amer492@bs-ja.co.jp Fri Nov 23 07:10:43 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvXMp-0006jw-CG for nfsv4-archive@lists.ietf.org; Fri, 23 Nov 2007 07:10:43 -0500 Received: from [201.217.117.47] (helo=47.satnet-117-217.gye.satnet.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvXMn-0006se-Lr for nfsv4-archive@lists.ietf.org; Fri, 23 Nov 2007 07:10:43 -0500 Received: from home-07 ([119.132.121.60] helo=home-07) by 47.satnet-117-217.gye.satnet.net ( sendmail 8.13.3/8.13.1) with esmtpa id 1wXrzp-000GDY-su for nfsv4-archive@lists.ietf.org; Fri, 23 Nov 2007 07:10:44 -0500 Message-ID: <000b01c82dc9$d971a800$2f75d9c9@home07> From: "amer Scalf" To: nfsv4-archive@lists.ietf.org Subject: rtoorden Date: Fri, 23 Nov 2007 07:10:33 -0500 Message-ID: <000b01c82dc9$d971a800$2f75d9c9@home07> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 3.2 (+++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Surprisingly low prices for stunning replicas only for the holiday period http://www.ipcopy.com/ From CarterutCrosby@orgonics.com Fri Nov 23 08:02:19 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvYAl-0006aL-5L; Fri, 23 Nov 2007 08:02:19 -0500 Received: from cpe-66-61-117-142.neo.res.rr.com ([66.61.117.142] helo=johnsonfamily.belkin) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvYAk-0008Gi-SV; Fri, 23 Nov 2007 08:02:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host95313132.orgonics.com (8.13.1/8.13.1) with SMTP id oLu01auB48.260264.ued.fQL.5377846719208 for ; Fri, 23 Nov 2007 08:01:54 +0500 Message-ID: <9ed3e01c82dd1$141340c0$0202a8c0@JohnsonFamily> From: "Bernie Mcknight" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_9ED3A_01C82DD1.141340C0-- From nfsv4-bounces@ietf.org Fri Nov 23 13:46: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 1IvdY6-0008RD-Ai; Fri, 23 Nov 2007 13:46:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvdY4-0008Qt-Nq for nfsv4@ietf.org; Fri, 23 Nov 2007 13:46:44 -0500 Received: from web38102.mail.mud.yahoo.com ([209.191.124.129]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvdY4-0003cf-94 for nfsv4@ietf.org; Fri, 23 Nov 2007 13:46:44 -0500 Received: (qmail 70177 invoked by uid 60001); 23 Nov 2007 18:46:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=MUZVvRa4excUW5vCHIY4YKBa8O8CwSaE1GD3Zfot//nQJskTH+JpnATvh/MBhZY+bNX7UKU3bK+RYDyJ0MszMrU1nmkFFtN2t0upVwAG/SfM1B+lfL7AjO9SX5TV3hjTLOKnhlFmjc5bWBWt/HIzkamH2jFDYmdMnjCNzn6yRBs=; X-YMail-OSG: 02oXX5MVM1nvyl.zJdxuDneFfClpH0oxkOnKaAF9 Received: from [198.95.226.230] by web38102.mail.mud.yahoo.com via HTTP; Fri, 23 Nov 2007 10:46:43 PST Date: Fri, 23 Nov 2007 10:46:43 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] File types in v4.1 spec To: "Noveck, Dave" , nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <739037.70038.qm@web38102.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > Currently the values of the file type attribute (NF4*) do not appear > in > the spec, but are referred to all over the place. While you can > argue > that the actual values are more appropriate to the dotx, having all > the > valid values in one place would definitely help understanding. Note > that "NF4REG" does not appear at all in draft-17. I guess the right > place to put this is the section on the type attribute, I don't object, but wonder if the RFC should have every line of the .x file (which is now in a separate i-d, intended to be a separate RFC) in it. There are arguments either way, but if the consensus is that the spec i-d should have all of .x file's content, time is running out to do that. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 23 14:28:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IveCD-0002vG-MY; Fri, 23 Nov 2007 14:28:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IveCD-0002vB-9S for nfsv4@ietf.org; Fri, 23 Nov 2007 14:28:13 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IveCA-0003k4-Or for nfsv4@ietf.org; Fri, 23 Nov 2007 14:28:13 -0500 X-IronPort-AV: E=Sophos;i="4.21,458,1188802800"; d="scan'208";a="125384134" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 23 Nov 2007 11:28:10 -0800 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 lANJS9Zu027123; Fri, 23 Nov 2007 11:28:09 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 11:28:09 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Nov 2007 11:28:09 -0800 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] File types in v4.1 spec Date: Fri, 23 Nov 2007 14:28:06 -0500 Message-ID: In-Reply-To: <739037.70038.qm@web38102.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] File types in v4.1 spec Thread-Index: AcguATc3wTwIMcd4RTm5PyJ3XI/58QABTglw From: "Noveck, Dave" To: , X-OriginalArrivalTime: 23 Nov 2007 19:28:09.0346 (UTC) FILETIME=[FADBF620:01C82E06] X-Spam-Score: -4.0 (----) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 not saying that the RFC should have every line of the .x file. In particular, the numeric values of the NF* constants aren't=20 really needed. I do think that having the set of possible=20 values that the type can have is important. Where we introduce the concept of the file type, I think it makes sense to say what file types there can be.=20 -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Friday, November 23, 2007 1:47 PM To: Noveck, Dave; nfsv4@ietf.org Subject: Re: [nfsv4] File types in v4.1 spec --- "Noveck, Dave" wrote: > Currently the values of the file type attribute (NF4*) do not appear=20 > in the spec, but are referred to all over the place. While you can=20 > argue that the actual values are more appropriate to the dotx, having=20 > all the valid values in one place would definitely help understanding. > Note that "NF4REG" does not appear at all in draft-17. I guess the=20 > right place to put this is the section on the type attribute, I don't object, but wonder if the RFC should have every line of the .x file (which is now in a separate i-d, intended to be a separate RFC) in it. There are arguments either way, but if the consensus is that the spec i-d should have all of .x file's content, time is running out to do that. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From ReubenquantaGaines@washingtonpost.com Fri Nov 23 19:17:16 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivihw-0005lg-2t; Fri, 23 Nov 2007 19:17:16 -0500 Received: from host81-155-26-63.range81-155.btcentralplus.com ([81.155.26.63] helo=pc8f75eb365520.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ivihv-0007Bs-HR; Fri, 23 Nov 2007 19:17:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host59645630.washingtonpost.com (8.13.1/8.13.1) with SMTP id igv11MAp97.228518.Dv1.abt.3610224268681 for ; Sat, 24 Nov 2007 00:16:45 +0000 Message-ID: <6fb901c82e2f$5cf50040$4001a8c0@pc8f75eb365520> From: "Ernie Hancock" To: Subject: Your order approved Date: Sat, 24 Nov 2007 00:16:45 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_6FB5_01C82E2F.5CF50040" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_6FB5_01C82E2F.5CF50040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_6FB5_01C82E2F.5CF50040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_6FB5_01C82E2F.5CF50040-- From HelentransylvaniaMayfield@supremecourthistory.org Sat Nov 24 02:56:54 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivpsk-0007sJ-Q2; Sat, 24 Nov 2007 02:56:54 -0500 Received: from 49-44-168.wireless.iaw.on.ca ([69.49.44.168] helo=your3558354030) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ivpsk-0002UE-D3; Sat, 24 Nov 2007 02:56:54 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host58831743.supremecourthistory.org (8.13.1/8.13.1) with SMTP id AfNFtL4136.750473.k9e.nxZ.5546614715251 for ; Sat, 24 Nov 2007 02:55:00 +0500 Message-ID: From: "Margaret Rouse" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_DE44F_01C82E6F.61EBCCB0-- From LadonnahewnWinkler@sloymca.org Sat Nov 24 04:51:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvrfH-0004UC-G3; Sat, 24 Nov 2007 04:51:07 -0500 Received: from s010600016c2e7e4c.wp.shawcable.net ([24.78.131.145] helo=acera2gjrt6tf9.wp.shawcable.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvrfH-00060X-1z; Sat, 24 Nov 2007 04:51:07 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host03175675.sloymca.org (8.13.1/8.13.1) with SMTP id xoEQpi4511.582954.MCG.5H2.2153491327081 for ; Sat, 24 Nov 2007 03:50:21 +0600 Message-ID: <1f42401c82e7f$85c19600$91834e18@acera2gjrt6tf9> From: "Aileen Granger" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_1F420_01C82E7F.85C19600-- From nfsv4-bounces@ietf.org Sat Nov 24 09:12: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 1Ivvjt-0007b9-LU; Sat, 24 Nov 2007 09:12:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivvjs-0007b4-8y for nfsv4@ietf.org; Sat, 24 Nov 2007 09:12:08 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivvjr-0006aP-Su for nfsv4@ietf.org; Sat, 24 Nov 2007 09:12:08 -0500 X-IronPort-AV: E=Sophos;i="4.21,460,1188802800"; d="scan'208,217";a="125569036" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 24 Nov 2007 06:12:07 -0800 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 lAOEC6Uq018785 for ; Sat, 24 Nov 2007 06:12:06 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 06:12:06 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 06:12:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 24 Nov 2007 09:12:04 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: v4.1 acknowledgements Thread-Index: Acguo/06F6C0AjIdSqeJ7rh5mIRCLQ== From: "Noveck, Dave" To: X-OriginalArrivalTime: 24 Nov 2007 14:12:06.0518 (UTC) FILETIME=[FE8BC960:01C82EA3] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [nfsv4] v4.1 acknowledgements 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="===============0349025454==" Errors-To: nfsv4-bounces@ietf.org This is a multi-part message in MIME format. --===============0349025454== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82EA3.FDD4BB2C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82EA3.FDD4BB2C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think with draft-17, it is an appropriate time to review the acknowledgment section. We've tried to cite everybody appropriately but given that this has been a marathon effort (I think we are past 20 miles. I'm not going to get into the issue of performance-enhancing substances except to say that caffeine damn well better be allowable) with many contributors, we may have forgotten someone's contributions. If you think we have, let us know. Alternatively, if you think the acknowledgement incorrectly associates you with a result that you'd rather not be associated with, that can be dealt with as well.=20 ------_=_NextPart_001_01C82EA3.FDD4BB2C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I = think=20 with draft-17, it is an appropriate time to review the = acknowledgment=20 section.  We've tried to cite everybody appropriately but given = that this=20 has been a marathon effort (I think we are past 20 miles.  I'm not = going to=20 get into the issue of performance-enhancing substances except to say = that=20 caffeine damn well better be allowable) with many contributors, we may = have=20 forgotten someone's contributions.  If you think we have, let us=20 know.  Alternatively, if you think the acknowledgement incorrectly=20 associates you with a result that you'd rather not be associated = with, that=20 can be dealt with as well. 
------_=_NextPart_001_01C82EA3.FDD4BB2C-- --===============0349025454== 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 --===============0349025454==-- From nfsv4-bounces@ietf.org Sat Nov 24 09:23: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 1Ivvuz-00035n-W2; Sat, 24 Nov 2007 09:23:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivvuy-00035X-NG for nfsv4@ietf.org; Sat, 24 Nov 2007 09:23:36 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivvux-0006y2-LS for nfsv4@ietf.org; Sat, 24 Nov 2007 09:23:36 -0500 X-IronPort-AV: E=Sophos;i="4.21,460,1188802800"; d="scan'208";a="125571586" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 24 Nov 2007 06:23:35 -0800 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 lAOENYUB029547; Sat, 24 Nov 2007 06:23:34 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 06:23:34 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 06:23:34 -0800 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] File types in v4.1 spec Date: Sat, 24 Nov 2007 09:23:31 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] File types in v4.1 spec Thread-Index: AcguATc3wTwIMcd4RTm5PyJ3XI/58QABTglwACVnAhA= From: "Noveck, Dave" To: "Noveck, Dave" , , X-OriginalArrivalTime: 24 Nov 2007 14:23:34.0299 (UTC) FILETIME=[987ED6B0:01C82EA5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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 Interestingly enough, as I've thought about documenting the file types, this has caused some other issues to arise. You can have your own opinion abut whether that is a good thing or not. For example, what does "is a directory" mean? It seems obvious=20 but consider that there are two possible meanings: 1) Is an object of type NF4DIR. 2) In an object of type NF4DIR or of type NF4ATTRDIR? Clearly when we are not doing an open by handle, the fh passed to open must be a directory in sense 2. I assume that remove is similar in that you can do REMOVE to get rid of a named attribute. But what about CREATE? If you pass an attribute directory, should that not cause you to return NFS4ERR_WRONG_TYPE? I'll argue that it should. In the past, the general view was that whether you=20 supported special files, symlinks, or directories within the=20 attribute directory was an implementation choice. A number of reasons why I think this is a bad idea: It is inconsistent with the spec's handling of named attributes in general, in that there are distinct object types for=20 regular files and named attributes: NF4REG and NF4NAMEDATTR. BTW, neither of these type names appears in draft-17. If we were to allow these other object types in a named attribute directory, they, unlike the case of regular files, would not be distinguishable, in terms of object type, from their non-named-attribute cousins. That's a pretty glaring inconsistency. It is just asking for interoperability problems. Often we are forced, as with POSIX locking, to accommodate two=20 different implementation philosophies, which sit rather=20 uneasily together, but we do that because that's what the history of file system development has given us and we have to live with it. But unless there are clients who currently need this, and I haven't heard of them, I think it is better to keep things in this area uniform. If you do allow this, then the possibilities for variants are just about endless. If you can create directories under=20 the named attribute directory then you face the issues of whether you can rename files between them. Also, could such directories have their own named attribute directory? If you descend a chain of sub-directories within a named attribute directory, could not see the fsid change? I know that's nuts, but right now I don't think the spec prohibits=20 it. So I think we should have a simple model in which the directory passed to CREATE must be NF4DIR, you cannot do an OPENATTR on an object of type NF4ATTRDIR of NF4NAMEDATTR, and the=20 fsid for objects of types NF4ATTRDIR or NF4NAMEDATTR must match the parent. I think v4.1 should be tightened up in this regard. So that leaves LINK and RENAME. For LINK, my preference would be to disallow objects of type NF4ATTRDIR as the directory=20 and objects of type NF4NAMEDATTR as the object linked. Are=20 there people who need this? If this is allowed, I think we=20 should prohibit any linking between distinct named attribute=20 directories, and absolutely under no circumstances should we=20 allow the same object to be linked in an NF4DIR directory=20 and an NF4ATTRDIR directory. This leaves the issue of=20 what to return if these are attempted. If you try one of=20 the prohibited operations, I would say a somewhat expanded=20 definition of NFS4ERR_XDEV makes sense and if you try=20 something that is allowed in the protocol but the server doesn't support it, the return should be NFS4ERR_NOTSUPP. For RENAME, I assume that it is allowable to rename a named attribute without moving it to a different directory. Does anybody have trouble implementing that? Again, I would=20 prohibit renaming between different named attribute=20 directories and think we absolutely must prohibit renaming between the two types of directories. -----Original Message----- From: Noveck, Dave=20 Sent: Friday, November 23, 2007 2:28 PM To: email2mre-ietf@yahoo.com; nfsv4@ietf.org Subject: RE: [nfsv4] File types in v4.1 spec I'm not saying that the RFC should have every line of the .x file. In particular, the numeric values of the NF* constants aren't really needed. I do think that having the set of possible values that the type can have is important. Where we introduce the concept of the file type, I think it makes sense to say what file types there can be.=20 -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] Sent: Friday, November 23, 2007 1:47 PM To: Noveck, Dave; nfsv4@ietf.org Subject: Re: [nfsv4] File types in v4.1 spec --- "Noveck, Dave" wrote: > Currently the values of the file type attribute (NF4*) do not appear=20 > in the spec, but are referred to all over the place. While you can=20 > argue that the actual values are more appropriate to the dotx, having=20 > all the valid values in one place would definitely help understanding. > Note that "NF4REG" does not appear at all in draft-17. I guess the=20 > right place to put this is the section on the type attribute, I don't object, but wonder if the RFC should have every line of the .x file (which is now in a separate i-d, intended to be a separate RFC) in it. There are arguments either way, but if the consensus is that the spec i-d should have all of .x file's content, time is running out to do that. _______________________________________________ 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 Sat Nov 24 11:07: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 1IvxXg-0004Hr-SZ; Sat, 24 Nov 2007 11:07:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvxXf-0004Hm-GE for nfsv4@ietf.org; Sat, 24 Nov 2007 11:07:39 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvxXc-0007LJ-LB for nfsv4@ietf.org; Sat, 24 Nov 2007 11:07:39 -0500 X-IronPort-AV: E=Sophos;i="4.21,460,1188802800"; d="scan'208";a="125598225" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 24 Nov 2007 08:07:35 -0800 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 lAOG7YIF004245 for ; Sat, 24 Nov 2007 08:07:34 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 08:07:34 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 08:07:34 -0800 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: Sat, 24 Nov 2007 11:07:32 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: symlinks: opaque or UTF-8 Thread-Index: AcgutB7okqqL8xGfQLimxio3p3Nihw== From: "Noveck, Dave" To: X-OriginalArrivalTime: 24 Nov 2007 16:07:34.0641 (UTC) FILETIME=[20077610:01C82EB4] X-Spam-Score: -3.8 (---) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [nfsv4] symlinks: opaque or UTF-8 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 Both RFC3530 and the v4.1 spec say about symbolic links: The data is a UTF-8 string that is opaque to the server. The two clauses of this sentence are, if not quite contradictory, at the very least they are in considerable tension. If the data is opaque to the server, in what sense can it be described as "a UTF-8 string"? linktext4 is defined as a UTF-8 string which might lead to the conclusion that if the client presents something which is not a UTF-8 string, then NFS4ERR_INVAL should result. That's what we do with other stuff defined in the XDR as a UTF-8 string, but I know that I currently don't do that (for v4.0) and suspect that others don't as well. I get the sense from some of the surrounding text that, without being too explicit about it, implementers are being invited to ignore the definition of a symbolic link as a UTF-8 string. So the first question is what do we want clients and servers to do with regard to symbolic links. If we want them to be treated as UTF-8 strings: Servers would check that they are UTF-8 in CREATE. Servers might check that they are UTF-8 in READLINK. Clients would endeavour to send UTF-8 strings for CREATE. If passed strings for links in a context in which the strings would be interpreted according to some other code, then they=20 would, as part of making them UTF-8 strings, translated. Similarly on READLINK. If clients are doing that, then servers would have to translate them to UTF-8 where the filesystem stores names in other than UTF-8 format and where the symbolic links, stored for example by v2 and v3, are not in UTF-8. On the other hand, if they are opaque, none of the above applies any=20 more than it does to data handled by read and write. But the data for read and write is not described as UTF-8 strings. It is described as=20 opaque, end of story. This is a potential interoperability issue, and I think we want to be absolutely clear about which of these two we mean. =20 If we want them to be treated as UTF-8 strings, then we can be explicit about what clients and servers have to do and mention the errors that should be returned if they don't do that (e.g. INVAL if CREATE gets symlink test that is not UTF-8). We could say that while the data is opaque to the server as to content, it is not, as a UTF-8 string, opaque to the server as to form. In the other case in which we want this data to be treated as opaque, I would prefer we simply dropped all talk of this being a UTF-8 string, as confusing. The XDR speciifcation of linktext4 raises interesting issues. You could argue that we are not allowed, in a minor version, to change an existing XDR definition. However note that in RFC3530: linktext4 is typedef'd as utf8str_cs. (in both the text and .x file portion) utf8str_cs is typedef'd as utf8string. (in the .x file portion, the text typedefs it incorrectly as opaque). =20 utf8string is typedef'd as opaque<>. (in the .x file portion, the text typedefs it incorrectly as opaque). So consider if we typedef'd linktext4 as opaque<>, which is what it is effectively typedef'd as in v4.0. Is it really the case that we are obliged to maintain the exact chain of definition for existing ops, or only the result, which is that linktext4 winds up being opaque<>? If the former, I'll bet there are a bunch of cases in which we have changed the existing chain of definitions. Could we not legitimately typedef linktext4 as opaque<> in v4.1? I think we could. If we are stuck with the XDR/stringprep definition of this as UTF-8, the other way to deal with this if we want the opaque interpretation is to say: The data is intended to be a UTF-8 string. However, this data is opaque to the server and it is not the server's responsibility to validate this data as UTF-8, either when creating a symbolic link or when reading it. The trouble with this formulation is that if it isn't the server's responsibility to make this UTF-8 (and the specfication of this as a UTF-8 string is something other than pure bullshit) then it is the client's and if it is the client's, he is obliged to do the translations, but if he did that, he could not inter-operate with v2 and v3. So the client can't accept that responsibility and the responsibility would have to be the application's. But we have no business telling the applications what to do and they wouldn't listen to us anyway. =20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sat Nov 24 12:55: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 1IvzDg-0007gI-HW; Sat, 24 Nov 2007 12:55:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvzDe-0007ep-M7 for nfsv4@ietf.org; Sat, 24 Nov 2007 12:55:06 -0500 Received: from [2001:468:e9c:3060::4] (helo=citi.umich.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvzDQ-0002YK-Oc for nfsv4@ietf.org; Sat, 24 Nov 2007 12:54:56 -0500 Received: from citi.umich.edu (dsl093-001-248.det1.dsl.speakeasy.net [66.93.1.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Jim Rees", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id 84D79474A; Sat, 24 Nov 2007 12:54:51 -0500 (EST) Date: Sat, 24 Nov 2007 12:54:58 -0500 From: Jim Rees To: "Noveck, Dave" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071124175457.GA31698@citi.umich.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Noveck, Dave wrote: explicit about it, implementers are being invited to ignore the definition of a symbolic link as a UTF-8 string. I think the problem is that some clients won't know what character set the linktext is in, as that is considered an application issue in some older clients. It may be useful for the client to send arbitrary text to the server, knowing that it will only be meaningful for the client that created the symlink. I doubt we want to allow this but it's worth some thought. We could say that while the data is opaque to the server as to content, it is not, as a UTF-8 string, opaque to the server as to form. That was my interpretation. We should make this explicit. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sat Nov 24 13:48: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 1Iw03F-0003hD-Vx; Sat, 24 Nov 2007 13:48:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw03C-0003gU-GU for nfsv4@ietf.org; Sat, 24 Nov 2007 13:48:22 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iw038-0005Tq-GH for nfsv4@ietf.org; Sat, 24 Nov 2007 13:48:22 -0500 X-IronPort-AV: E=Sophos;i="4.21,461,1188802800"; d="scan'208";a="125640559" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 24 Nov 2007 10:47:47 -0800 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 lAOIlltX025648 for ; Sat, 24 Nov 2007 10:47:47 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 10:47:46 -0800 Received: from exsvl02.hq.netapp.com ([10.56.8.60]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 10:47:47 -0800 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] symlinks: opaque or UTF-8 Date: Sat, 24 Nov 2007 10:47:45 -0800 Message-ID: <992BA60650F1584BA63E339312CE42030C7CAC8E@exsvl02.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgutB7okqqL8xGfQLimxio3p3NihwAFUMKQ From: "Yoder, Alan" To: "Noveck, Dave" , X-OriginalArrivalTime: 24 Nov 2007 18:47:47.0108 (UTC) FILETIME=[81818640:01C82ECA] X-Spam-Score: -3.8 (---) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 A UTF-8 string is a string that=20 (1) contains no non-UTF-8 character sequences (2) can be manipulated with the C string library.=20 (3) has a semantics that may or may not be=20 known to the server (4) has other properties as well I suspect that (2) is about the only thing that implementations have cared about to date. However, (1) is pertinent if the string is being converted to Unicode; are there clients that need to store soft links to Unicode file names in an interoperable way? Alan > -----Original Message----- > From: Noveck, Dave=20 > Sent: Saturday, November 24, 2007 8:08 AM > To: nfsv4@ietf.org > Subject: [nfsv4] symlinks: opaque or UTF-8 >=20 > Both RFC3530 and the v4.1 spec say about symbolic links: >=20 > The data is a UTF-8 string that is opaque to the server. >=20 >=20 > The two clauses of this sentence are, if not quite=20 > contradictory, at the > very least they are in considerable tension. >=20 > If the data is opaque to the server, in what sense can it be described > as "a UTF-8 string"? >=20 > linktext4 is defined as a UTF-8 string which might lead to the > conclusion that if the client presents something which is not a UTF-8 > string, then NFS4ERR_INVAL should result. That's what we do=20 > with other > stuff defined in the XDR as a UTF-8 string, but I know that I=20 > currently > don't do that (for v4.0) and suspect that others don't as well. I get > the sense from some of the surrounding text that, without being too > explicit about it, implementers are being invited to ignore the > definition of a symbolic link as a UTF-8 string. >=20 > So the first question is what do we want clients and servers=20 > to do with > regard to symbolic links. >=20 > If we want them to be treated as UTF-8 strings: >=20 > Servers would check that they are UTF-8 in CREATE. >=20 > Servers might check that they are UTF-8 in READLINK. >=20 > Clients would endeavour to send UTF-8 strings for CREATE. >=20 > If passed strings for links in a context in which the strings > would be interpreted according to some other code, then they=20 > would, as part of making them UTF-8 strings, translated. >=20 > Similarly on READLINK. >=20 > If clients are doing that, then servers would have to translate > them to UTF-8 where the filesystem stores names in other than > UTF-8 format and where the symbolic links, stored for example > by v2 and v3, are not in UTF-8. >=20 > On the other hand, if they are opaque, none of the above applies any=20 > more than it does to data handled by read and write. But the data for > read and write is not described as UTF-8 strings. It is described as=20 > opaque, end of story. >=20 > This is a potential interoperability issue, and I think we want to be > absolutely clear about which of these two we mean. =20 >=20 > If we want them to be treated as UTF-8 strings, then we can=20 > be explicit > about what clients and servers have to do and mention the errors that > should be returned if they don't do that (e.g. INVAL if CREATE gets > symlink test that is not UTF-8). We could say that while the data is > opaque to the server as to content, it is not, as a UTF-8=20 > string, opaque > to the server as to form. >=20 > In the other case in which we want this data to be treated as=20 > opaque, I > would prefer we simply dropped all talk of this being a UTF-8=20 > string, as > confusing. The XDR speciifcation of linktext4 raises interesting > issues. You could argue that we are not allowed, in a minor=20 > version, to > change an existing XDR definition. However note that in RFC3530: >=20 > linktext4 is typedef'd as utf8str_cs. (in both the text=20 > and .x file > portion) >=20 > utf8str_cs is typedef'd as utf8string. (in the .x file=20 > portion, the > text typedefs it incorrectly as opaque). > =20 > utf8string is typedef'd as opaque<>. (in the .x file portion, the > text typedefs it incorrectly as opaque). >=20 > So consider if we typedef'd linktext4 as opaque<>, which is what it is > effectively typedef'd as in v4.0. >=20 > Is it really the case that we are obliged to maintain the=20 > exact chain of > definition for existing ops, or only the result, which is=20 > that linktext4 > winds up being opaque<>? If the former, I'll bet there are a bunch of > cases in which we have changed the existing chain of=20 > definitions. Could > we not legitimately typedef linktext4 as opaque<> in v4.1? I think we > could. >=20 > If we are stuck with the XDR/stringprep definition of this as=20 > UTF-8, the > other way to deal with this if we want the opaque interpretation is to > say: >=20 > The data is intended to be a UTF-8 string. However, this data > is opaque to the server and it is not the server's responsibility > to validate this data as UTF-8, either when creating a symbolic > link or when reading it. >=20 > The trouble with this formulation is that if it isn't the server's > responsibility to make this UTF-8 (and the specfication of this as a > UTF-8 string is something other than pure bullshit) then it is the > client's and if it is the client's, he is obliged to do the > translations, but if he did that, he could not inter-operate=20 > with v2 and > v3. So the client can't accept that responsibility and the > responsibility would have to be the application's. But we have no > business telling the applications what to do and they=20 > wouldn't listen to > us anyway. >=20 > =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 PabloroccoBowen@interfax.ru Sat Nov 24 13:49:06 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw03u-0004YQ-So; Sat, 24 Nov 2007 13:49:06 -0500 Received: from [190.40.216.154] (helo=mchaparro) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iw03u-0000Ac-Er; Sat, 24 Nov 2007 13:49:06 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host89426645.interfax.ru (8.13.1/8.13.1) with SMTP id 96PjOeIq90.437840.vc2.4AN.7220967504185 for ; Sat, 24 Nov 2007 13:48:38 +0500 Message-ID: <1924001c82eca$af7856f0$0201a8c0@mchaparro> From: "Hubert Leonard" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_1923C_01C82ECA.AF7856F0-- From nfsv4-bounces@ietf.org Sat Nov 24 14:38: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 1Iw0p4-0003X7-O9; Sat, 24 Nov 2007 14:37:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw0p1-0003Nc-Pa for nfsv4@ietf.org; Sat, 24 Nov 2007 14:37:47 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iw0ow-0007MU-Hk for nfsv4@ietf.org; Sat, 24 Nov 2007 14:37:47 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1Iw0ov-0003ks-Hn; Sat, 24 Nov 2007 14:37:41 -0500 Date: Sat, 24 Nov 2007 14:37:41 -0500 To: "Noveck, Dave" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071124193741.GA12864@fieldses.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.2 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 Sat, Nov 24, 2007 at 11:07:32AM -0500, Noveck, Dave wrote: > Both RFC3530 and the v4.1 spec say about symbolic links: > > The data is a UTF-8 string that is opaque to the server. > > > The two clauses of this sentence are, if not quite contradictory, at the > very least they are in considerable tension. > > If the data is opaque to the server, in what sense can it be described > as "a UTF-8 string"? One of the fundamental requirements for a symlink is that it should be able to store any path on the client's filesystem. The only way I can see to allow that is to allow arbitrary strings to be stored in them. --b. > > linktext4 is defined as a UTF-8 string which might lead to the > conclusion that if the client presents something which is not a UTF-8 > string, then NFS4ERR_INVAL should result. That's what we do with other > stuff defined in the XDR as a UTF-8 string, but I know that I currently > don't do that (for v4.0) and suspect that others don't as well. I get > the sense from some of the surrounding text that, without being too > explicit about it, implementers are being invited to ignore the > definition of a symbolic link as a UTF-8 string. > > So the first question is what do we want clients and servers to do with > regard to symbolic links. > > If we want them to be treated as UTF-8 strings: > > Servers would check that they are UTF-8 in CREATE. > > Servers might check that they are UTF-8 in READLINK. > > Clients would endeavour to send UTF-8 strings for CREATE. > > If passed strings for links in a context in which the strings > would be interpreted according to some other code, then they > would, as part of making them UTF-8 strings, translated. > > Similarly on READLINK. > > If clients are doing that, then servers would have to translate > them to UTF-8 where the filesystem stores names in other than > UTF-8 format and where the symbolic links, stored for example > by v2 and v3, are not in UTF-8. > > On the other hand, if they are opaque, none of the above applies any > more than it does to data handled by read and write. But the data for > read and write is not described as UTF-8 strings. It is described as > opaque, end of story. > > This is a potential interoperability issue, and I think we want to be > absolutely clear about which of these two we mean. > > If we want them to be treated as UTF-8 strings, then we can be explicit > about what clients and servers have to do and mention the errors that > should be returned if they don't do that (e.g. INVAL if CREATE gets > symlink test that is not UTF-8). We could say that while the data is > opaque to the server as to content, it is not, as a UTF-8 string, opaque > to the server as to form. > > In the other case in which we want this data to be treated as opaque, I > would prefer we simply dropped all talk of this being a UTF-8 string, as > confusing. The XDR speciifcation of linktext4 raises interesting > issues. You could argue that we are not allowed, in a minor version, to > change an existing XDR definition. However note that in RFC3530: > > linktext4 is typedef'd as utf8str_cs. (in both the text and .x file > portion) > > utf8str_cs is typedef'd as utf8string. (in the .x file portion, the > text typedefs it incorrectly as opaque). > > utf8string is typedef'd as opaque<>. (in the .x file portion, the > text typedefs it incorrectly as opaque). > > So consider if we typedef'd linktext4 as opaque<>, which is what it is > effectively typedef'd as in v4.0. > > Is it really the case that we are obliged to maintain the exact chain of > definition for existing ops, or only the result, which is that linktext4 > winds up being opaque<>? If the former, I'll bet there are a bunch of > cases in which we have changed the existing chain of definitions. Could > we not legitimately typedef linktext4 as opaque<> in v4.1? I think we > could. > > If we are stuck with the XDR/stringprep definition of this as UTF-8, the > other way to deal with this if we want the opaque interpretation is to > say: > > The data is intended to be a UTF-8 string. However, this data > is opaque to the server and it is not the server's responsibility > to validate this data as UTF-8, either when creating a symbolic > link or when reading it. > > The trouble with this formulation is that if it isn't the server's > responsibility to make this UTF-8 (and the specfication of this as a > UTF-8 string is something other than pure bullshit) then it is the > client's and if it is the client's, he is obliged to do the > translations, but if he did that, he could not inter-operate with v2 and > v3. So the client can't accept that responsibility and the > responsibility would have to be the application's. But we have no > business telling the applications what to do and they wouldn't listen to > us anyway. > > > > _______________________________________________ > 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 Sat Nov 24 16:00: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 1Iw26M-0005zK-EI; Sat, 24 Nov 2007 15:59:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw26L-0005zC-BB for nfsv4@ietf.org; Sat, 24 Nov 2007 15:59:45 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iw26G-0001py-9T for nfsv4@ietf.org; Sat, 24 Nov 2007 15:59:45 -0500 Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Iw26F-0004jT-Df; Sat, 24 Nov 2007 21:59:39 +0100 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx9.uio.no) by mail-mx9.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Iw26E-0006Mx-WF; Sat, 24 Nov 2007 21:59:39 +0100 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx9.uio.no with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Iw26E-0006Mc-If; Sat, 24 Nov 2007 21:59:38 +0100 Subject: Re: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Sat, 24 Nov 2007 15:59:37 -0500 Message-Id: <1195937977.8544.20.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.3, required=12.0, autolearn=disabled, AWL=-0.288) X-UiO-Scanned: 235C2BEE90AC97391C4A9E11C2908FCBF266F671 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -2 maxlevel 200 minaction 2 bait 0 mail/h: 430 total 5349245 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Sat, 2007-11-24 at 11:07 -0500, Noveck, Dave wrote: > Both RFC3530 and the v4.1 spec say about symbolic links: > > The data is a UTF-8 string that is opaque to the server. > > > The two clauses of this sentence are, if not quite contradictory, at the > very least they are in considerable tension. Given that we make no effort whatsoever to define a portable symlink type (for instance, nowhere is there a definition of a NFSv4 'path separator') and hence that we assume the symlink is supposed to be entirely interpreted by the client, then why bother with the UTF-8 constraint? Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sat Nov 24 18:42: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 1Iw4dj-0000HM-8L; Sat, 24 Nov 2007 18:42:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw4di-0000HH-8g for nfsv4@ietf.org; Sat, 24 Nov 2007 18:42:22 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iw4df-0006Rn-3O for nfsv4@ietf.org; Sat, 24 Nov 2007 18:42:22 -0500 X-IronPort-AV: E=Sophos;i="4.21,462,1188802800"; d="scan'208";a="125702416" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 24 Nov 2007 15:41:38 -0800 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 lAONfbZI019851; Sat, 24 Nov 2007 15:41:37 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 15:41:36 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 15:41:36 -0800 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] symlinks: opaque or UTF-8 Date: Sat, 24 Nov 2007 18:41:34 -0500 Message-ID: In-Reply-To: <20071124175457.GA31698@citi.umich.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcguwyG/zNWs6s5jSWK4Tq3dijnTDgAL1Kbg From: "Noveck, Dave" To: "Jim Rees" X-OriginalArrivalTime: 24 Nov 2007 23:41:36.0641 (UTC) FILETIME=[8D86C710:01C82EF3] X-Spam-Score: -3.8 (---) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 > That was my interpretation.=20 But have you acted on this interpretation? For example, have you as a server validated the UTF8-ness of data to be stored in a symlink? Or as a client, taken data presented to you in a different code and translated it to UTF8 (below the VOP interface presumably). I think we have two issues here: How do we handle this in v4.1? Do we have an interoperability issue in v4.0? -----Original Message----- From: Jim Rees [mailto:rees@umich.edu]=20 Sent: Saturday, November 24, 2007 12:55 PM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Noveck, Dave wrote: explicit about it, implementers are being invited to ignore the definition of a symbolic link as a UTF-8 string. I think the problem is that some clients won't know what character set the linktext is in, as that is considered an application issue in some older clients. It may be useful for the client to send arbitrary text to the server, knowing that it will only be meaningful for the client that created the symlink. I doubt we want to allow this but it's worth some thought. We could say that while the data is opaque to the server as to content, it is not, as a UTF-8 string, opaque to the server as to form. That was my interpretation. We should make this explicit. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Sat Nov 24 18:54: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 1Iw4pf-000872-V2; Sat, 24 Nov 2007 18:54:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iw4pe-00086s-4t for nfsv4@ietf.org; Sat, 24 Nov 2007 18:54:42 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iw4pb-0006h8-5H for nfsv4@ietf.org; Sat, 24 Nov 2007 18:54:42 -0500 X-IronPort-AV: E=Sophos;i="4.21,462,1188802800"; d="scan'208";a="125706054" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 24 Nov 2007 15:54:37 -0800 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 lAONsbZ5021721 for ; Sat, 24 Nov 2007 15:54:37 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 15:54:37 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Nov 2007 15:54:37 -0800 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] symlinks: opaque or UTF-8 Date: Sat, 24 Nov 2007 18:54:35 -0500 Message-ID: In-Reply-To: <992BA60650F1584BA63E339312CE42030C7CAC8E@exsvl02.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgutB7okqqL8xGfQLimxio3p3NihwAFUMKQAAqnr6A= From: "Noveck, Dave" To: "Yoder, Alan" , X-OriginalArrivalTime: 24 Nov 2007 23:54:37.0016 (UTC) FILETIME=[5EAA8D80:01C82EF5] X-Spam-Score: -3.8 (---) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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 don't know about (2). A string of zero bytes seems to obey the rules of UTF-8, which prescibes the identity mapping for characters below 127 which zero is. If I present a name that has zero byte in it, is the correct error NFS4ERR_INVAL or NFS4ERR_BADCHAR?=20 > I suspect that (2) is about the only thing that implementations have cared about to date. I doubt they have cared about (2) for symlinks. You have a byte count and if you have treated it as opaque (like it was treated in v3), I don't think you would have looked for nulls. > However, (1) is pertinent if the string is being converted to=20 > Unicode; are there clients that need to store soft links to=20 > Unicode file names in an interoperable way? The other is interoperability with v2/v3 implementations that are writing symlinks in a non-UTF8 way. To deal with that, you eaither translate the data to/from UTF-8 or treat it as opaque which makes interoperability with the v2/v3 implmeentation easy and implementation with those using Unicode just about impossible. -----Original Message----- From: Yoder, Alan=20 Sent: Saturday, November 24, 2007 1:48 PM To: Noveck, Dave; nfsv4@ietf.org Subject: RE: [nfsv4] symlinks: opaque or UTF-8 A UTF-8 string is a string that=20 (1) contains no non-UTF-8 character sequences (2) can be manipulated with the C string library.=20 (3) has a semantics that may or may not be=20 known to the server (4) has other properties as well I suspect that (2) is about the only thing that implementations have cared about to date. However, (1) is pertinent if the string is being converted to Unicode; are there clients that need to store soft links to Unicode file names in an interoperable way? Alan > -----Original Message----- > From: Noveck, Dave > Sent: Saturday, November 24, 2007 8:08 AM > To: nfsv4@ietf.org > Subject: [nfsv4] symlinks: opaque or UTF-8 >=20 > Both RFC3530 and the v4.1 spec say about symbolic links: >=20 > The data is a UTF-8 string that is opaque to the server. >=20 >=20 > The two clauses of this sentence are, if not quite contradictory, at=20 > the very least they are in considerable tension. >=20 > If the data is opaque to the server, in what sense can it be described > as "a UTF-8 string"? >=20 > linktext4 is defined as a UTF-8 string which might lead to the=20 > conclusion that if the client presents something which is not a UTF-8=20 > string, then NFS4ERR_INVAL should result. That's what we do with=20 > other stuff defined in the XDR as a UTF-8 string, but I know that I=20 > currently don't do that (for v4.0) and suspect that others don't as=20 > well. I get the sense from some of the surrounding text that, without > being too explicit about it, implementers are being invited to ignore=20 > the definition of a symbolic link as a UTF-8 string. >=20 > So the first question is what do we want clients and servers to do=20 > with regard to symbolic links. >=20 > If we want them to be treated as UTF-8 strings: >=20 > Servers would check that they are UTF-8 in CREATE. >=20 > Servers might check that they are UTF-8 in READLINK. >=20 > Clients would endeavour to send UTF-8 strings for CREATE. >=20 > If passed strings for links in a context in which the strings > would be interpreted according to some other code, then they=20 > would, as part of making them UTF-8 strings, translated. >=20 > Similarly on READLINK. >=20 > If clients are doing that, then servers would have to translate > them to UTF-8 where the filesystem stores names in other than > UTF-8 format and where the symbolic links, stored for example > by v2 and v3, are not in UTF-8. >=20 > On the other hand, if they are opaque, none of the above applies any=20 > more than it does to data handled by read and write. But the data for > read and write is not described as UTF-8 strings. It is described as=20 > opaque, end of story. >=20 > This is a potential interoperability issue, and I think we want to be=20 > absolutely clear about which of these two we mean. >=20 > If we want them to be treated as UTF-8 strings, then we can be=20 > explicit about what clients and servers have to do and mention the=20 > errors that should be returned if they don't do that (e.g. INVAL if=20 > CREATE gets symlink test that is not UTF-8). We could say that while=20 > the data is opaque to the server as to content, it is not, as a UTF-8=20 > string, opaque to the server as to form. >=20 > In the other case in which we want this data to be treated as opaque,=20 > I would prefer we simply dropped all talk of this being a UTF-8=20 > string, as confusing. The XDR speciifcation of linktext4 raises=20 > interesting issues. You could argue that we are not allowed, in a=20 > minor version, to change an existing XDR definition. However note that > in RFC3530: >=20 > linktext4 is typedef'd as utf8str_cs. (in both the text and .x=20 > file > portion) >=20 > utf8str_cs is typedef'd as utf8string. (in the .x file portion,=20 > the text typedefs it incorrectly as opaque). > =20 > utf8string is typedef'd as opaque<>. (in the .x file portion, the=20 > text typedefs it incorrectly as opaque). >=20 > So consider if we typedef'd linktext4 as opaque<>, which is what it is > effectively typedef'd as in v4.0. >=20 > Is it really the case that we are obliged to maintain the exact chain=20 > of definition for existing ops, or only the result, which is that=20 > linktext4 winds up being opaque<>? If the former, I'll bet there are=20 > a bunch of cases in which we have changed the existing chain of=20 > definitions. Could we not legitimately typedef linktext4 as opaque<>=20 > in v4.1? I think we could. >=20 > If we are stuck with the XDR/stringprep definition of this as UTF-8,=20 > the other way to deal with this if we want the opaque interpretation=20 > is to > say: >=20 > The data is intended to be a UTF-8 string. However, this data > is opaque to the server and it is not the server's responsibility > to validate this data as UTF-8, either when creating a symbolic > link or when reading it. >=20 > The trouble with this formulation is that if it isn't the server's=20 > responsibility to make this UTF-8 (and the specfication of this as a > UTF-8 string is something other than pure bullshit) then it is the=20 > client's and if it is the client's, he is obliged to do the=20 > translations, but if he did that, he could not inter-operate with v2=20 > and v3. So the client can't accept that responsibility and the=20 > responsibility would have to be the application's. But we have no=20 > business telling the applications what to do and they wouldn't listen=20 > to us anyway. >=20 > =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 nowotka@k-meidai.co.jp Sun Nov 25 07:17:34 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwGQY-0002jj-01 for nfsv4-archive@lists.ietf.org; Sun, 25 Nov 2007 07:17:34 -0500 Received: from [213.207.204.10] (helo=[213.207.204.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwGQX-0004bw-5b for nfsv4-archive@lists.ietf.org; Sun, 25 Nov 2007 07:17:33 -0500 Received: from Autoserver ([131.130.156.180]:18294 "EHLO Autoserver" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by [213.207.204.10] with ESMTP id S22QBILWTOISLXZF (ORCPT ); Sun, 25 Nov 2007 15:50:46 +03-30 Message-ID: <000c01c82f5d$8db6ca90$0acccfd5@Autoserver> From: "avron nowotka" To: nfsv4-archive@lists.ietf.org Subject: pladenia Date: Sun, 25 Nov 2007 15:50:23 +03-30 Message-ID: <000c01c82f5d$8db6ca90$0acccfd5@Autoserver> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.8 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Stunning product: for less than $200 you get a quality watch! http://www.swimmong.com/ From MarlinslewRich@oyez.org Sun Nov 25 08:48:38 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwHqg-0001t1-PN; Sun, 25 Nov 2007 08:48:38 -0500 Received: from cpe-72-226-198-138.rochester.res.rr.com ([72.226.198.138] helo=inspiron) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwHqg-0007NH-Ag; Sun, 25 Nov 2007 08:48:38 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host61210257.oyez.org (8.13.1/8.13.1) with SMTP id C3YoD8Gs35.277111.ofQ.l21.2619807392595 for ; Sun, 25 Nov 2007 08:49:37 +0500 Message-ID: <2e923301c82f6a$1513b0f0$6701a8c0@Inspiron> From: "Elwood Avila" To: Cc: , =20

Even if you have no erection problems = Cialis would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 15 minutes! The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 36 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $95.95 $34.19
30 tabs 60 doses $349.95 $104.66
60 tabs 120 doses $549.95 $180.15
90 tabs 180 doses $789.95 $242.06
180 tabs 360 doses $1325.95 $445.61

When you are young and stressed = up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.

------=_NextPart_000_2E922F_01C82F6A.1513B0F0-- From ArlinevesperIrving@fnff.es Sun Nov 25 15:42:57 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwOJc-0008Ku-V3; Sun, 25 Nov 2007 15:42:57 -0500 Received: from oh-74-5-33-218.dhcp.embarqhsd.net ([74.5.33.218] helo=mom.gateway.2wire.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwOJc-0001oD-5q; Sun, 25 Nov 2007 15:42:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host58594080.fnff.es (8.13.1/8.13.1) with SMTP id f0gFHuOd48.387995.VBQ.ArC.8555071754149 for ; Sun, 25 Nov 2007 15:38:14 +0500 Message-ID: <3114801c82fa3$3d246830$4001a8c0@MOM> From: "Marietta Ogden" To: Subject: Your health Date: Sun, 25 Nov 2007 15:38:14 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_31144_01C82FA3.3D246830" 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: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_31144_01C82FA3.3D246830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_31144_01C82FA3.3D246830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_31144_01C82FA3.3D246830-- From freddievelazquez@crossford.org.uk Mon Nov 26 02:58:53 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwYrl-0000P5-0G for nfsv4-archive@lists.ietf.org; Mon, 26 Nov 2007 02:58:53 -0500 Received: from [196.212.86.74] (helo=[41.206.160.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwYrL-0000xb-9u for nfsv4-archive@lists.ietf.org; Mon, 26 Nov 2007 02:58:52 -0500 Received: from fastfreightnels ([154.143.77.154] helo=fastfreightnels) by [41.206.160.2] ( sendmail 8.13.3/8.13.1) with esmtpa id 1FKZFC-000WSC-ga for nfsv4-archive@lists.ietf.org; Mon, 26 Nov 2007 09:59:06 +0200 Message-ID: <000c01c83002$229691a0$02a0ce29@fastfreightnels> From: "freddie velazquez" To: Subject: 49-42467 Date: Mon, 26 Nov 2007 09:58:30 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C83012.E61F61A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0005_01C83012.E61F61A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable these crazy christmas specials wont last, get your rolex today = http://www.rgwkor.com/ ------=_NextPart_000_0005_01C83012.E61F61A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
these crazy christmas specials wont last, get = your=20 rolex today http://www.rgwkor.com/
------=_NextPart_000_0005_01C83012.E61F61A0-- From nfsv4-bounces@ietf.org Mon Nov 26 14:28: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 1Iwjd5-0007UO-0X; Mon, 26 Nov 2007 14:28:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwjd4-0007UJ-Cf for nfsv4@ietf.org; Mon, 26 Nov 2007 14:28:26 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwjd1-00012f-6y for nfsv4@ietf.org; Mon, 26 Nov 2007 14:28:26 -0500 Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lAQJSMGc023743; Mon, 26 Nov 2007 14:28:22 -0500 (EST) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Mon, 26 Nov 2007 14:28:22 -0500 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 lAQJRQ8U018966; Mon, 26 Nov 2007 14:28:19 -0500 (EST) From: Glasgow_Jason@emc.com Received: from CORPUSMX40A.corp.emc.com ([10.254.64.44]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 14:28:19 -0500 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] Issue in LAYOUTRETURN Date: Mon, 26 Nov 2007 14:28:17 -0500 Message-ID: <39CF2A4B63947142A66EAA65B2FDF2F00606001D@CORPUSMX40A.corp.emc.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] Issue in LAYOUTRETURN thread-index: AcgrGeMbSUZC4jiCT0Gh2SJN2R947gBfs97QAPIQSSA= References: <4A3FA24D-EEEB-41E5-8D7D-4E0A76082FF7@sun.com> To: , , X-OriginalArrivalTime: 26 Nov 2007 19:28:19.0034 (UTC) FILETIME=[7FDF7BA0:01C83062] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 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-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: -2.8 (--) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b 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 The most relevant cases that I am familiar with are the following: Case 1 The client issues a LAYOUTGET operation and the server returns a LAYOUT comprised of many extents. The client while processing the individual extents and putting them into client data structures runs out of memory. The cleanest behavior in this situation is to silently drop the remaining extents that comprise the layout. Case 2 A similar case happens under memory pressure. In our implementation of FMP, the client implementation releases read-only layouts when notified by the memory manager to shrink its cache. In such a situation it is advantageous to immediately drop the resources. In the short term, acquiring new resources to send an RPC would be counter productive. I think that the protocol should allow for both behaviors. -Jason -----Original Message----- From: Black_David@emc.com [mailto:Black_David@emc.com]=20 Sent: Wednesday, November 21, 2007 6:52 PM To: Spencer.Shepler@Sun.COM; nfsv4@ietf.org Subject: RE: [nfsv4] Issue in LAYOUTRETURN Spencer, I should let Jason elaborate further, as he's closer to these implementations, but here are some initial answers: > Can you add some words or experience to the case where the client > is out-of-sync with the server? Is this by choice or by > implementation or protocol error? It can be by implementation choice, and can help with some protocol errors. We initially did it as an implementation choice. > > This allows some out-of- > > sync situations to be resolved cleanly, and allows some client > > optimizations to drop no-longer-needed state without having to talk > > to the server. >=20 > In the implementation you mention, does the client associate > layout information with cached pages and when those pages are > flushed the layout information is "dropped" and thus answering > my question above or is there some other condition that occurs, etc. Yes, that is an example, and it avoids having to return a layout when dropping clean pages from cache. > From the point of view of a protocol that requires the client and server > to share the layout state, the only time the client would need to > know exactly what it has is in the case where no recall of layout is > being done. In the servicing of the recall, the client can just pretend > it has the layouts for which the server is asking. Right - the ability of the client to drop state assumes that if the server needs something, it'll send a recall. > To support the forgetful client, the layoutreturn would need to > allow for a "0->max-range" layoutreturn and the stateid transition > would need to occur for that to signify that the server has > processed the request (even if no layouts were being held). Probably also a good idea, if the client wants to do the server a favor, enabling the server to not send a recall. > > One new wrinkle here is that client discard of clean state need > > not affect the stateid, and that probably falls into your category > > of "convince ourselves we have done it, and clearly explain in > > the spec, how that works." >=20 > Can you expand on what you intend by "client discard of clean state"? > What scenario does this describe? The discard of a clean page and associated layout state from the cache, as you summarized above. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer 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: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 > Sent: Monday, November 19, 2007 9:05 PM > To: NFSv4 > Subject: Re: [nfsv4] Issue in LAYOUTRETURN >=20 >=20 > On Nov 19, 2007, at 1:29 PM, Black_David@emc.com wrote: >=20 > > Dave, > > > > EMC has implementation experience from MPFS/FMP which suggests > > that moving from: > > > >> Go to a strict agreement model as Spencer is suggesting and > >> explain the protocol from that standpoint. > > > > to at least: > > > >> Figure out how to have that ability work together with > >> stateids, convince ourselves we have done it, and clearly > >> explain in the spec, how that works. > > > > has robustness and flexibility gains for client implementations. > > > > In the former case, when the server issues a return for a set of > > layouts and/or ranges, the client has to return *exactly* what > > the server thinks it has. Taken to its extreme limit, it can > > yield situations in which an out-of-sync client has no chance > > of working further with the server, and it imposes server > > communication costs on client decisions to drop otherwise-clean > > layout state. >=20 > Can you add some words or experience to the case where the client > is out-of-sync with the server? Is this by choice or by > implementation or protocol error? >=20 > > In the latter case, when the server issues a return for a set of > > layouts and/or ranges, the client has to get to a state in which > > it no longer has anything that needs to be returned and tell the > > server that it has reached that state. This allows some out-of- > > sync situations to be resolved cleanly, and allows some client > > optimizations to drop no-longer-needed state without having to talk > > to the server. >=20 > In the implementation you mention, does the client associate > layout information with cached pages and when those pages are > flushed the layout information is "dropped" and thus answering > my question above or is there some other condition that occurs, etc. >=20 > > > > The server can't tell these two situations apart for a client > > that issues returns based on "I don't have any of those". Think > > about the responses to the Old Maid "Give me all your 8's" > > request - whether or not the recipient had any 8's beforehand, > > she will have no 8's when her response is complete, and the > > latter is what the server actually cares about (no outstanding > > layout or range covered by issued recall). Of course, the client > > *must* absolutely respect the stateid protocol as part of this - > > getting confused about the stateid is generally fatal to continued > > use of the state protected by the stateid. >=20 > From the point of view of a protocol that requires the client and =20 > server > to share the layout state, the only time the client would need to > know exactly what it has is in the case where no recall of layout is > being done. In the servicing of the recall, the client can=20 > just pretend > it has the layouts for which the server is asking. >=20 > To support the forgetful client, the layoutreturn would need to > allow for a "0->max-range" layoutreturn and the stateid transition > would need to occur for that to signify that the server has > processed the request (even if no layouts were being held). >=20 > > One new wrinkle here is that client discard of clean state need > > not affect the stateid, and that probably falls into your category > > of "convince ourselves we have done it, and clearly explain in > > the spec, how that works." >=20 > Can you expand on what you intend by "client discard of clean state"? > What scenario does this describe? >=20 >=20 > Spencer >=20 >=20 > > The other new wrinkle is that if a > > client gets a recall for a layout that it has discarded, it needs > > to have a clean way to tell the server "I don't have that layout", > > and I believe that's already there as an error return to=20 > the callback. > > > > Thanks, > > --David > > > > >=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 garret@businessedge.org Tue Nov 27 05:50:28 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwy1M-0000fV-7D for nfsv4-archive@lists.ietf.org; Tue, 27 Nov 2007 05:50:28 -0500 Received: from cablelink16-145.telefonia.intercable.net ([201.172.16.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwy1L-0001l4-R5 for nfsv4-archive@lists.ietf.org; Tue, 27 Nov 2007 05:50:28 -0500 Received: from dell ([104.112.197.173]:19771 "EHLO dell" smtp-auth: TLS-CIPHER: TLS-PEER-CN1: ) by CableLink16-145.telefonia.InterCable.net with ESMTP id S22ZOLIWMBXKSUSN (ORCPT ); Tue, 27 Nov 2007 04:50:24 -0600 Message-ID: <000e01c830e3$49e20dc0$9110acc9@dell> From: "garret azme" To: Subject: ntrukten Date: Tue, 27 Nov 2007 04:50:13 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C830B0.FF479DC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0006_01C830B0.FF479DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable if you wear a classy watch, people really do think higher of you = http://www.adbeno.com/ ------=_NextPart_000_0006_01C830B0.FF479DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
if you wear a classy watch, people really do think = higher=20 of you http://www.adbeno.com/
------=_NextPart_000_0006_01C830B0.FF479DC0-- From nfsv4-bounces@ietf.org Tue Nov 27 18:15:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9eA-0000mW-Vu; Tue, 27 Nov 2007 18:15:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix9e9-0000mA-3s for nfsv4@ietf.org; Tue, 27 Nov 2007 18:15:17 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix9e8-00072Z-36 for nfsv4@ietf.org; Tue, 27 Nov 2007 18:15:17 -0500 X-IronPort-AV: E=Sophos;i="4.23,221,1194249600"; d="scan'208";a="126661248" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 27 Nov 2007 15:15:00 -0800 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 lARNExlJ017828 for ; Tue, 27 Nov 2007 15:14:59 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 15:14:59 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 15:14:59 -0800 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] File types in v4.1 spec Date: Tue, 27 Nov 2007 18:15:07 -0500 Message-ID: In-Reply-To: <8B14822F7A793B489412B50D1D04A6602F5304A0@exnane01.hq.netapp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] File types in v4.1 spec Thread-Index: AcguATc3wTwIMcd4RTm5PyJ3XI/58QABTglwACVnAhAAqW21YA== From: "Noveck, Dave" To: X-OriginalArrivalTime: 27 Nov 2007 23:14:59.0160 (UTC) FILETIME=[5497C580:01C8314B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 Here's a concrete proposal for people to throw stones at (or salute for its brilliance :-). OPENATTR on an object of type NF4ATTRDIR or NFS4NAMEDATTR returns NFSERR_WRONG_TYPE. CREATE where the current fh is of type NF4ATTRDIR returns NFS4ERR_WRONG_TYPE. If LINK is called when the current fh is of type NF4NAMEDATTR and the saved fh is not the associated attribute dir, it returns NFS4ERR_XDEV. If LINK is called when the current fh is of type NF4NAMEDATTR and the saved fh is the associated attribute dir, it may return NFS4ERR_NOTSUPP, even if LINK is otherwise supported for the file system. If RENAME is called and current and saved fh's are different and at least one is of type NF4ATTRDIR, it returns NFS4ERR_XDEV. -----Original Message----- From: Noveck, Dave=20 Sent: Saturday, November 24, 2007 9:24 AM To: Noveck, Dave; email2mre-ietf@yahoo.com; nfsv4@ietf.org Subject: RE: [nfsv4] File types in v4.1 spec Interestingly enough, as I've thought about documenting the file types, this has caused some other issues to arise. You can have your own opinion abut whether that is a good thing or not. For example, what does "is a directory" mean? It seems obvious=20 but consider that there are two possible meanings: 1) Is an object of type NF4DIR. 2) In an object of type NF4DIR or of type NF4ATTRDIR? Clearly when we are not doing an open by handle, the fh passed to open must be a directory in sense 2. I assume that remove is similar in that you can do REMOVE to get rid of a named attribute. But what about CREATE? If you pass an attribute directory, should that not cause you to return NFS4ERR_WRONG_TYPE? I'll argue that it should. In the past, the general view was that whether you=20 supported special files, symlinks, or directories within the=20 attribute directory was an implementation choice. A number of reasons why I think this is a bad idea: It is inconsistent with the spec's handling of named attributes in general, in that there are distinct object types for=20 regular files and named attributes: NF4REG and NF4NAMEDATTR. BTW, neither of these type names appears in draft-17. If we were to allow these other object types in a named attribute directory, they, unlike the case of regular files, would not be distinguishable, in terms of object type, from their non-named-attribute cousins. That's a pretty glaring inconsistency. It is just asking for interoperability problems. Often we are forced, as with POSIX locking, to accommodate two=20 different implementation philosophies, which sit rather=20 uneasily together, but we do that because that's what the history of file system development has given us and we have to live with it. But unless there are clients who currently need this, and I haven't heard of them, I think it is better to keep things in this area uniform. If you do allow this, then the possibilities for variants are just about endless. If you can create directories under=20 the named attribute directory then you face the issues of whether you can rename files between them. Also, could such directories have their own named attribute directory? If you descend a chain of sub-directories within a named attribute directory, could not see the fsid change? I know that's nuts, but right now I don't think the spec prohibits=20 it. So I think we should have a simple model in which the directory passed to CREATE must be NF4DIR, you cannot do an OPENATTR on an object of type NF4ATTRDIR of NF4NAMEDATTR, and the=20 fsid for objects of types NF4ATTRDIR or NF4NAMEDATTR must match the parent. I think v4.1 should be tightened up in this regard. So that leaves LINK and RENAME. For LINK, my preference would be to disallow objects of type NF4ATTRDIR as the directory=20 and objects of type NF4NAMEDATTR as the object linked. Are=20 there people who need this? If this is allowed, I think we=20 should prohibit any linking between distinct named attribute=20 directories, and absolutely under no circumstances should we=20 allow the same object to be linked in an NF4DIR directory=20 and an NF4ATTRDIR directory. This leaves the issue of=20 what to return if these are attempted. If you try one of=20 the prohibited operations, I would say a somewhat expanded=20 definition of NFS4ERR_XDEV makes sense and if you try=20 something that is allowed in the protocol but the server doesn't support it, the return should be NFS4ERR_NOTSUPP. For RENAME, I assume that it is allowable to rename a named attribute without moving it to a different directory. Does anybody have trouble implementing that? Again, I would=20 prohibit renaming between different named attribute=20 directories and think we absolutely must prohibit renaming between the two types of directories. -----Original Message----- From: Noveck, Dave=20 Sent: Friday, November 23, 2007 2:28 PM To: email2mre-ietf@yahoo.com; nfsv4@ietf.org Subject: RE: [nfsv4] File types in v4.1 spec I'm not saying that the RFC should have every line of the .x file. In particular, the numeric values of the NF* constants aren't really needed. I do think that having the set of possible values that the type can have is important. Where we introduce the concept of the file type, I think it makes sense to say what file types there can be.=20 -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] Sent: Friday, November 23, 2007 1:47 PM To: Noveck, Dave; nfsv4@ietf.org Subject: Re: [nfsv4] File types in v4.1 spec --- "Noveck, Dave" wrote: > Currently the values of the file type attribute (NF4*) do not appear=20 > in the spec, but are referred to all over the place. While you can=20 > argue that the actual values are more appropriate to the dotx, having=20 > all the valid values in one place would definitely help understanding. > Note that "NF4REG" does not appear at all in draft-17. I guess the=20 > right place to put this is the section on the type attribute, I don't object, but wonder if the RFC should have every line of the .x file (which is now in a separate i-d, intended to be a separate RFC) in it. There are arguments either way, but if the consensus is that the spec i-d should have all of .x file's content, time is running out to do that. _______________________________________________ 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 Nov 28 00:29: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 1IxFUU-0007ce-LU; Wed, 28 Nov 2007 00:29:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxFUU-0007cY-6w for nfsv4@ietf.org; Wed, 28 Nov 2007 00:29:42 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxFUS-0003c6-QQ for nfsv4@ietf.org; Wed, 28 Nov 2007 00:29:42 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAS5Tddv018562 for ; Wed, 28 Nov 2007 05:29:39 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS700A01B569M00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Tue, 27 Nov 2007 22:29:39 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS700GYUB9BPA30@mail-amer.sun.com>; Tue, 27 Nov 2007 22:29:36 -0700 (MST) Date: Tue, 27 Nov 2007 23:29:34 -0600 From: Spencer Shepler Subject: Re: [nfsv4] File types in v4.1 spec In-reply-to: To: "Noveck, Dave" Message-id: <62B14A7B-A3C1-45FE-9EB0-3FC30A6B90C1@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: -1.0 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Nov 27, 2007, at 5:15 PM, Noveck, Dave wrote: > Here's a concrete proposal for people to throw stones at (or salute > for > its brilliance :-). > > OPENATTR on an object of type NF4ATTRDIR or NFS4NAMEDATTR returns > NFSERR_WRONG_TYPE. > > CREATE where the current fh is of type NF4ATTRDIR returns > NFS4ERR_WRONG_TYPE. > > If LINK is called when the current fh is of type NF4NAMEDATTR and the > saved fh is not the associated attribute dir, it returns NFS4ERR_XDEV. > > If LINK is called when the current fh is of type NF4NAMEDATTR and the > saved fh is the associated attribute dir, it may return > NFS4ERR_NOTSUPP, > even if LINK is otherwise supported for the file system. > > If RENAME is called and current and saved fh's are different and at > least one is of type NF4ATTRDIR, it returns NFS4ERR_XDEV. These changes are fine with me. Given the "significant" change from 4.0, I would suggest a description of these changes and impact be added to the introduction. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From MarcelinotakeoffFrost@newbritainherald.com Wed Nov 28 04:25:26 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJAc-00014N-Ju; Wed, 28 Nov 2007 04:25:26 -0500 Received: from [86.158.175.237] (helo=homewc58l63m16.home) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxJAc-0005Q2-4U; Wed, 28 Nov 2007 04:25:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host01691982.newbritainherald.com (8.13.1/8.13.1) with SMTP id sPlGZrcK17.761305.px6.KUz.9625979008945 for ; Wed, 28 Nov 2007 09:25:18 +0000 Message-ID: <6ec8001c831a0$a17f44e0$4001a8c0@homewc58l63m16> From: "Denver Best" To: Subject: Approval process Date: Wed, 28 Nov 2007 09:25:18 +0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_6EC7C_01C831A0.A17F44E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_6EC7C_01C831A0.A17F44E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_6EC7C_01C831A0.A17F44E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_6EC7C_01C831A0.A17F44E0-- From EileencorrosiveLocke@mathleague.com Wed Nov 28 08:23:07 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxMsd-0007ru-DI; Wed, 28 Nov 2007 08:23:07 -0500 Received: from [84.232.81.5] (helo=companynts) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxMsc-0004cz-5y; Wed, 28 Nov 2007 08:23:07 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host65407532.mathleague.com (8.13.1/8.13.1) with SMTP id tBkxRTPA63.678331.b25.nwj.3791350202828 for ; Wed, 28 Nov 2007 14:22:48 -0100 Message-ID: <3eb201c831c1$cee85180$0551e854@companynts> From: "Terri Bergeron" To: Subject: Your family Date: Wed, 28 Nov 2007 14:22:48 -0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_3EAE_01C831C1.CEE85180" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_3EAE_01C831C1.CEE85180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_3EAE_01C831C1.CEE85180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_3EAE_01C831C1.CEE85180-- From nfsv4-bounces@ietf.org Wed Nov 28 08:33: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 1IxN2Q-0006Mt-Ib; Wed, 28 Nov 2007 08:33:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxN2P-0006Mc-DP for nfsv4@ietf.org; Wed, 28 Nov 2007 08:33:13 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxN2N-0000tP-Up for nfsv4@ietf.org; Wed, 28 Nov 2007 08:33:13 -0500 X-IronPort-AV: E=Sophos;i="4.23,224,1194249600"; d="scan'208";a="126842324" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 28 Nov 2007 05:32:56 -0800 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 lASDWurT029249; Wed, 28 Nov 2007 05:32:56 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 05:32:55 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 05:32:55 -0800 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] File types in v4.1 spec Date: Wed, 28 Nov 2007 08:33:03 -0500 Message-ID: In-Reply-To: <62B14A7B-A3C1-45FE-9EB0-3FC30A6B90C1@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] File types in v4.1 spec Thread-Index: Acgxf70Y85/tq28JQOmMsZSncGxPSwAQzX/g From: "Noveck, Dave" To: "Spencer Shepler" X-OriginalArrivalTime: 28 Nov 2007 13:32:55.0709 (UTC) FILETIME=[2F01CCD0:01C831C3] X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 can write that. I think what will work best is a short mention in chapter 1 with an xref to a longer explanation of the changes from v4.0 where named attributes are discussed.=20 -----Original Message----- From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM]=20 Sent: Wednesday, November 28, 2007 12:30 AM To: Noveck, Dave Cc: nfsv4@ietf.org Subject: Re: [nfsv4] File types in v4.1 spec On Nov 27, 2007, at 5:15 PM, Noveck, Dave wrote: > Here's a concrete proposal for people to throw stones at (or salute=20 > for its brilliance :-). > > OPENATTR on an object of type NF4ATTRDIR or NFS4NAMEDATTR returns=20 > NFSERR_WRONG_TYPE. > > CREATE where the current fh is of type NF4ATTRDIR returns=20 > NFS4ERR_WRONG_TYPE. > > If LINK is called when the current fh is of type NF4NAMEDATTR and the=20 > saved fh is not the associated attribute dir, it returns NFS4ERR_XDEV. > > If LINK is called when the current fh is of type NF4NAMEDATTR and the=20 > saved fh is the associated attribute dir, it may return=20 > NFS4ERR_NOTSUPP, even if LINK is otherwise supported for the file=20 > system. > > If RENAME is called and current and saved fh's are different and at=20 > least one is of type NF4ATTRDIR, it returns NFS4ERR_XDEV. These changes are fine with me. Given the "significant" change from 4.0, I would suggest a description of these changes and impact be added to the introduction. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 10:57: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 1IxPIC-0000Gf-8j; Wed, 28 Nov 2007 10:57:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxPI9-0000Bo-N8 for nfsv4@ietf.org; Wed, 28 Nov 2007 10:57:37 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxPI8-00049E-8s for nfsv4@ietf.org; Wed, 28 Nov 2007 10:57:37 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lASFvZuF015146 for ; Wed, 28 Nov 2007 15:57:35 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS800E01438PT00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 28 Nov 2007 08:57:35 -0700 (MST) Received: from [192.168.0.3] (adsl-71-145-137-130.dsl.austtx.sbcglobal.net [71.145.137.130]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS800BMR4BSHB80@mail-amer.sun.com>; Wed, 28 Nov 2007 08:57:29 -0700 (MST) Date: Wed, 28 Nov 2007 09:57:27 -0600 From: Spencer Shepler Subject: Re: [nfsv4] File types in v4.1 spec 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: -1.0 (-) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Nov 28, 2007, at 7:33 AM, Noveck, Dave wrote: > I can write that. I think what will work best is a short mention in > chapter 1 with an xref to a longer explanation of the changes from > v4.0 > where named attributes are discussed. Yes, this is what I had in mind. Spencer > > -----Original Message----- > From: Spencer Shepler [mailto:Spencer.Shepler@Sun.COM] > Sent: Wednesday, November 28, 2007 12:30 AM > To: Noveck, Dave > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] File types in v4.1 spec > > > On Nov 27, 2007, at 5:15 PM, Noveck, Dave wrote: > >> Here's a concrete proposal for people to throw stones at (or salute >> for its brilliance :-). >> >> OPENATTR on an object of type NF4ATTRDIR or NFS4NAMEDATTR returns >> NFSERR_WRONG_TYPE. >> >> CREATE where the current fh is of type NF4ATTRDIR returns >> NFS4ERR_WRONG_TYPE. >> >> If LINK is called when the current fh is of type NF4NAMEDATTR and the >> saved fh is not the associated attribute dir, it returns >> NFS4ERR_XDEV. >> >> If LINK is called when the current fh is of type NF4NAMEDATTR and the >> saved fh is the associated attribute dir, it may return >> NFS4ERR_NOTSUPP, even if LINK is otherwise supported for the file >> system. >> >> If RENAME is called and current and saved fh's are different and at >> least one is of type NF4ATTRDIR, it returns NFS4ERR_XDEV. > > These changes are fine with me. Given the "significant" change from > 4.0, I would suggest a description of these changes and impact be > added > to the introduction. > > Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 15:35: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 1IxTcU-00088L-8g; Wed, 28 Nov 2007 15:34:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTcT-00085V-KF for nfsv4@ietf.org; Wed, 28 Nov 2007 15:34:53 -0500 Received: from p01c11o141.mxlogic.net ([208.65.144.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxTcS-0001SA-9T for nfsv4@ietf.org; Wed, 28 Nov 2007 15:34:53 -0500 Received: from unknown [63.110.244.103] (EHLO us-email.terastack.bluearc.com) by p01c11o141.mxlogic.net (mxl_mta-5.2.0-1) with ESMTP id ce0dd474.2436033456.325851.00-013.p01c11o141.mxlogic.net (envelope-from ); Wed, 28 Nov 2007 13:34:52 -0700 (MST) 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: Wed, 28 Nov 2007 12:34:50 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: File Layout change proposal Thread-Index: Acgx/h+9BmK2SuCbSueyrhO+o7SeGQ== From: "Anatoly Pinchuk" To: X-Spam: [F=0.0100000000; S=0.010(2007110801)] X-MAIL-FROM: X-SOURCE-IP: [63.110.244.103] X-Spam-Score: -1.0 (-) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Subject: [nfsv4] File Layout change proposal 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 thinking about improving file layout. Here is an example of how file layout structures might look like. Highlights of file layout changes - The existing two layer (device - layout) hierarchy is extended into three (device - layout item - layout) layered one. As a result of this only one layout4 structure is returned as a result of LAYOUTGET. According to the current specification an array of layout4 is returned. - Packing type (sparse/dense) and COMMIT operation acceptance (NFL4_UFLG_COMMIT_THRU_MDS) are defined per data server instead of the layout. - Stripe unit size is defined per device instead of the layout. - Number of data file handles in the layout item is not linked to packing and can be equal to number of data server lists or stripe units. /* Data server address type */ typedef netaddr4 ds_addr4; const NFL4_DS_UFLG_DENSE =3D 0x00000001; const NFL4_DS_UFLG_COMMIT_THRU_MDS =3D 0x00000002; /* Data server structure to be used in a device definition. In particular, this allows us to have packing type specified per data server. A given layout can be based on both sparse and dense data servers. This gives us the flexibility of having a given client file spread between the data servers with different packing implementation. This is not allowed currently. */ struct nfsv4_1_fl_ds4 { ds_addr4 nflds_addr; uint32_t nflds_util; }; nflds_addr Data server address. nflds_util=20 A compact representation of whether dense or sparse packing is used (nflds_util & NFL4_DS_UFLG_DENSE). Also the field defines if the client SHOULD send COMMIT operations to the data server or metadata server (nflda_util & NFL4_DS_UFLG_COMMIT_THRU_MDS). /* List of equivalent data servers */ typedef nfsv4_1_fl_ds4 nfsv4_1_file_layout_multipath_list4<>; The same data server address MUST NOT be presented more than once in the list.=20 const NFL4_DEV_UFLG_STRIPE_UNIT_SIZE_MASK =3D 0xFFFFFFC0; /* Encoded in the da_addr_body field of type device_addr4 and represents a device */ struct nfsv4_1_file_layout_ds_addr4 { nfsv4_1_file_layout_multipath_list4 nflda_multipath_ds_list<>; uint32_t nflda_stripe_indices<>; uint32_t nflda_util; }; nflda_multipath_ds_list An array of lists of data servers, where each list can be one or more elements and each element represents an equivalent data server. nflda_stripe_indices An array of indexes used to index into nflda_multipath_ds_list. The number of elements in nflda_stripe_indices is always equal to the stripe count. nflda_util Defines stripe unit size (nflda_util & NFL4_DEV_UFLG_STRIPE_UNIT_SIZE_MASK). Stripe unit size is considered as part of data distribution and, therefore, belongs to the device. Each element in nflda_multipath_ds_list MUST be referenced by at least one stripe index from nflda_stripe_indices array. Thus number of the elements in nflda_stripe_indices array is more or equal than in nflda_multipath_ds_list one. /* The layout item corresponds to a segment of the client file. It allows the segment to be represented with different devices. Thus each segment can be of different length, based on its own data file handles, array of equivalent data servers, and/or striping */ struct nfsv4_1_fl_item4 { deviceid4 nfli_deviceid; offset4 nfli_off; uint32_t nfl_first_stripe_index; nfs_fh4 nfli_fh_list<>; }; nfli_deviceid Device ID maps to a value of type nfsv4_1_file_layout_ds_addr4. nfli_off Offset of first byte of the client file the layout item is applicable to. In segments (see above) terminology it is offset of the first byte of the corresponding segment. nfl_first_stripe_index The index into the first element of the nflda_stripe_indices array to use. nfli_fh_list An array of data server file handles. Once we mapped the handle into nflda_multipath_ds_list, it is used for all data servers in the list. The mapping of handles into the lists is defined below. Number of elements in nfli_fh_list MUST be - Zero means that the data file handles used for each data server list MUST be the same as the one returned by the OPEN operation from the metadata server. - One element in the list means that each data server MUST use the same file handle what is specified in nfli_fh_list[0]. - The number of elements as nflda_multipath_ds_list array. Thus, in this case, when issuing an I/O to any data server in nflda_multipath_ds_list[nflda_stripe_indices[X]], the filehandle in nfli_fh_list[nflda_stripe_indices[X]] MUST be used. - The number of elements as in nflda_stripe_indices array. Thus, in this case, when issuing an I/O to any data server in nflda_multipath_ds_list[nflda_stripe_indices[X]], the filehandle in nfli_fh_list[X] MUST be used. Note that number of the data file handles is not related to sparse/dense packing anymore. /* file layout - encoded in the loc_body field of type layout_content4 */ typedef nfsv4_1_fl_item4 nfsv4_1_file_layout4<>; A nfsv4_1_file_layout4 fl MUST satisfy to the following consistency rules. - fl[i].nfli_off < fl[j].nfli_off, for i < j. The offset presented by subsequent layout items within a layout MUST be increasing. - if fl[i] is not last item in the array, then it covers client bytes exactly from fl[i].nfli_off to fl[i+1].nfli_off - 1. There MUST not be any holes in view of client range provided by the layout. - bytes range ([lo_offset, lo_offset + lo_length - 1]) returned to the client in layout4 structure is completely covered with corresponding file layout fl packed into the same structure File layout SHOULD NOT contain the items not covering bytes from the range returned in layout4 structure - [lo_offset, lo_offset + lo_length - 1]. The file layout definitions above establish a mapping between data file handles and multi-set of nfsv4_1_fl_ds4 structures. The multi-set MS for a handle fh is constructed by processing all the layouts of a given client file. For each layout having fh we identify all the data server lists the handle is used to do IO. Then we add each nfsv4_1_fl_ds4 structure from the lists to the multi-set MS. The mapping is called overlapping if for some handle fh there are two elements ds1 and ds2 from the multi-set the handle is mapped into, such that ds1.nflds_addr equal to ds2.nflds_addr and dense packing is used in ds1 or ds2. The layout items defined in the system MUST NOT introduce overlapping mapping. As follows from the definition, overlapping is not possible if dense packing is not used. In practice, even if dense packing is defined for some data servers, there is no need to build that map. The only requirement is to generate the layout items in such way that mapping is not overlapping if we build one. Here is an algorithm for performing IO using the above data structures. It uses the file layout returned by the metadata server and client file offset provided to determine the data server network addresses and data file handle, length, offset.=20 Let's assume that fl represents the nfsv4_1_file_layout4 layout and client_off represents the client offset provided. The first step is to select appropriate nfsv4_1_fl_item4 fli using client_off and fl. The layout item fli would be the item with maximum nfli_off which is less or equal than client_off. Also, using fli we can get corresponding nfsv4_1_file_layout_ds_addr4 dev.=20 Given that a pattern allows data server list can be used more than once in a given stripe, we need an auxiliary function ds_stripe_count(i, j, k). The function is used to calculate data file offset for dense packing and handle per data server list distribution (see handle_per_su below). This function essentially counts the number of references to the server list nflda_multipath_ds_list[k] in array nflda_stripe_indices from element i to item j. If i is more than j then wraparound occurs. For example if nflda_stripe_indices array is {1, 2, 1, 2, 0, 1} then ds_stripe_count(2, 5, 0) =3D 1, ds_stripe_count(5, 1, 1) =3D 2, ds_stripe_count(0, 2, 2) =3D 1. More formally the function is defined for all i, j, k such that=20 0 <=3D i, j < stripe_count=20 0 <=3D k < ds_list_count Another auxiliary function we need is prev(i). The function is defined for all 0 <=3D i < stripe_count as prev(i) =3D i - 1, if i > 0 prev(0) =3D stripe_count - 1; The value of ds_stripe_count(i, j, k) equal to number of occurrences of k in elements dev.nflda_stripe_indices[i], ..., dev.nflda_stripe_indices[j]. Definitions of stripe_count and ds_list_count are given below.=20 /* various numbers and sizes associated with the layout item and its device */ fh_count =3D number of elements in fli.nfli_fh_list; ds_list_count =3D number of elements in dev.nflda_multipath_ds_list; stripe_count =3D number of elements in dev.nflda_stripe_indices; stripe_size =3D dev.nflda_util & NFL4_DEV_UFLG_STRIPE_UNIT_SIZE_MASK; stripe_width =3D stripe_count * stripe_size; /* offsets and indices */ /* offset inside a layout item */ rel_off =3D client_off - fli.nfli_client_off; /* number of times a pattern has been repeated */ stripe_rep_idx =3D floor(rel_off / stripe_width); /* the stripe unit within the stripe that this offset applies to */ stripe_unit_idx =3D floor((rel_off % stripe_width) / stripe_size); stripe_unit_idx =3D (stripe_unit_idx + nfl_first_stripe_index) % stripe_count; /* the offset in the stripe unit the client offset represents */ stripe_unit_byte_off =3D rel_off % stripe_size; /* index into data servers list array */ ds_list_indx =3D dev.nflda_stripe_indices[stripe_unit_idx]; /* handle_per_su indicates if file handle is defined per data server list or stripe unit */ /* calculate data file handle */ switch (fh_count) { case 0: handle_per_su =3D FALSE; fh =3D filehandle returned by OPEN; break; case 1: handle_per_su =3D FALSE; fh =3D fli.nfli_fh_list[0]; break; case ds_list_count: handle_per_su =3D FALSE; fh =3D fli.nfli_fh_list[ds_list_idx]; break; case stripe_count: /* this is the only case of file handle per stripe unit */ handle_per_su =3D TRUE; fh =3D fli.nfli_fh_list[stripe_unit_idx]; break; default: throw a fatal exception; break; } /* the maximum number of bytes for IO in stripe unit */ len =3D stripe_size - stripe_unit_byte_off; /* list of equivalent data servers to perform IO to */ ds_list =3D dev.nflda_multipath_ds_list[ds_list_indx]; /* number of equivalent data servers in ds_list */ ds_count =3D number of elements in ds_list; for ( i =3D 0; i < ds_count; i++ ) { /* define data server for already defined data file handle fh and length len */ ds =3D ds_list[i]; /* The actual calculation is based on whether DENSE or SPARSE packing is used. Calculate offset for already defined fh, len, and ds */ if ( ds.nflds_util & NFL4_DS_UFLG_DENSE ) { /* rep_off_count counts number of the stripe units of stripe related to data file with handle fh. su_off_count is similar but counts stripe units from nfl_first_stripe_index to prev(stripe_unit_idx) */ if ( handle_per_su =3D=3D TRUE ) { /*only one reference for fh in case of handle per stripe unit distribution */ rep_off_count =3D 1; su_off_count =3D 0; } else { /* this is the only case when we need ds_stripe_count() and prev() functions */ rep_off_count =3D ds_stripe_count(0, stripe_count, ds_list_indx); if ( nfl_first_stripe_index =3D=3D stripe_unit_idx ) su_off_count =3D 0; else su_off_count =3D =09 ds_stripe_count(nfl_first_stripe_index, prev(stripe_unit_idx), ds_list_indx); } off =3D (rep_off_count * stripe_rep_idx + su_off_count ) * stripe_size + stripe_unit_byte_off; } else off =3D client_off; /* Now we can do IO using ds.nflds_addr, fh, off, and len */ } - Anatoly _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 16:22:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUMD-0002ds-ID; Wed, 28 Nov 2007 16:22:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUMC-0002dZ-IT for nfsv4@ietf.org; Wed, 28 Nov 2007 16:22:08 -0500 Received: from web38105.mail.mud.yahoo.com ([209.191.124.132]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxUMB-0003JC-E9 for nfsv4@ietf.org; Wed, 28 Nov 2007 16:22:08 -0500 Received: (qmail 81828 invoked by uid 60001); 28 Nov 2007 21:22:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=2jngL63ucrxBQ6JzvaTRuebgXjnoWF9yBcjidplStwfPabMzuzYFUqn5XehDJCwn5xVb17qIr3zrOmgrXOBbYRpmvpd1xvZc0z2IXu/A5hh6xqNXsQXGqVDNIuTdkUy2o3PTNFpmPaQ3JFE6HM7P/vn6hbQJ90d28IzezH7J7OM=; X-YMail-OSG: KhFrS_EVM1ki3Ug.XKgvC10wPx1HvABCbXf_GjZo1fc0DpREi4tVk3vf5a6I8rJyP2SgR_M3NFZ4Dm6mCurSeJtPnffVSJs9KdKXL8_dXKeqj2W4z8U- Received: from [198.95.226.230] by web38105.mail.mud.yahoo.com via HTTP; Wed, 28 Nov 2007 13:22:06 PST Date: Wed, 28 Nov 2007 13:22:06 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <869679.80262.qm@web38105.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > Both RFC3530 and the v4.1 spec say about symbolic links: > > The data is a UTF-8 string that is opaque to the server. > > > The two clauses of this sentence are, if not quite contradictory, at > the > very least they are in considerable tension. This is rooted in how symbolic links were first specified when 4.2 BSD introduced them: - they were parseable by system calls like open(), stat(), rename(), link(), i.e. anything that took a pathname as an argument. - the symlink() system call that created the symbolic did not impose a form on symlink, presumably because symbolic links could be relative or absolute, and many relative symbolic links do not have component separators ("/" in 4.2 BSD), and remote file access protocols were not a consideration. When NFS came along, we were faced with a situation where clients, and only clients, interpreted the symbolic link (although the MOUNT protocol could). Note that the symbolic link type was of type "path" in NFSv2, and "path" was of type "string", i.e. US-ASCII. This meant that aclient that used say backslashes as a component separator could create a symbolic link that if read by another client that used forward slashes as the component separator would likely result in ENOENT. In NFSv3, the type of the symbolic link as still ultimately an string (nfspath3). In NFSv4, the type was changed to opaque from string. Given that component names were changed to a type (utf8str_cs) that derived from opaque, this was the right thing. And symlinks were defined as linktest4, which is also a typedef of utf8str_cs. So any suggestion that we change the meaning of symlinks to anything but utf8 is dead on arrival, unless it is accompanied by a new operation to read these new symlinks (that NFS has never specified before in over 20 years), and another operation to create them. Minor versioning rules. OK, so let's just consider what is in RFC3530 and the current NFSv4.1 as errata. What do we want to say? We currently have: "The data is a UTF-8 string that is opaque to the server. That is, whether created by an NFS client or created locally on the server, the data in a symbolic link is not interpreted when created, but is simply stored." What was meant by "opaque to the server". I believe what was meant is that structure of presumed path name in the symolic link contents is opaque to the server. E.g. if the contents are a\b or d/c, the server MUST NOT rejected the former if its native component name separator is /. "The data is a UTF-8 string that may or may not be a path name constructed in a form that may or may be known to the server. That is, whether created by an NFS client or created locally on the server, the data in a symbolic link is not interpreted as a path name when created but is simply stored, as long as the string is legal UTF-8, and UTF-8 characters used are supported by the server. Nor is the symbolic link interpreted as a path name when retried via READLINK. A process on a client might interpret the results of READLINK as a path name but whether this interpretation succeeds or not depends on whether the symbolic link is a legal absolute or relative symbolic link on the client's operating environment. In the IMPLEMENTATION section we could have: A server might store a symbolic link in an encoding other than UTF-8. If so, the server MUST convert the contents of the symbolic link to UTF-8 before returning READLINK's result. If a server supports a file access protocol other than NFSv4.0 and NFSv4.1, such a file access protocol might create symbolic links using non-UTF-8 characters. If so, it is RECOMMENDED the server record the identity of the character set used when the symbolic link is created, so that conversion to UTF-8 is possible, and thus interoperability betwenn non NFSv4 and NFSv4 clients is possible. Some server implementations might assign the character set identity on a per-fsid basis. In particular, NFSv3 is a file access protocol that while strictly speaking uses only characters that are a proper subset of UTF-8 (US-ASCII: 7 bit characters, with the highest order 8th bit always equal to zero), in practice can non-US-ASCII characters. If the NFSv3 client creates symbolic links with UTF-8 characters, and the fsid's character set is also UTF-8, interoperability is trivial. If the fsid's character set is not UTF-8, then the NFSv3 client needs to create symbolic links using the character set of the fsid, or the server needs to have a method for converting from the client's character set to that of the fsid. > > If the data is opaque to the server, in what sense can it be > described > as "a UTF-8 string"? > > linktext4 is defined as a UTF-8 string which might lead to the > conclusion that if the client presents something which is not a UTF-8 > string, then NFS4ERR_INVAL should result. That's what we do with > other > stuff defined in the XDR as a UTF-8 string, but I know that I > currently > don't do that (for v4.0) and suspect that others don't as well. I > get > the sense from some of the surrounding text that, without being too > explicit about it, implementers are being invited to ignore the > definition of a symbolic link as a UTF-8 string. > > So the first question is what do we want clients and servers to do > with > regard to symbolic links. > > If we want them to be treated as UTF-8 strings: > > Servers would check that they are UTF-8 in CREATE. > > Servers might check that they are UTF-8 in READLINK. > > Clients would endeavour to send UTF-8 strings for CREATE. > > If passed strings for links in a context in which the strings > would be interpreted according to some other code, then they > would, as part of making them UTF-8 strings, translated. > > Similarly on READLINK. > > If clients are doing that, then servers would have to translate > them to UTF-8 where the filesystem stores names in other than > UTF-8 format and where the symbolic links, stored for example > by v2 and v3, are not in UTF-8. > > On the other hand, if they are opaque, none of the above applies any > more than it does to data handled by read and write. But the data > for > read and write is not described as UTF-8 strings. It is described as > > opaque, end of story. > > This is a potential interoperability issue, and I think we want to be > absolutely clear about which of these two we mean. > > If we want them to be treated as UTF-8 strings, then we can be > explicit > about what clients and servers have to do and mention the errors that > should be returned if they don't do that (e.g. INVAL if CREATE gets > symlink test that is not UTF-8). We could say that while the data is > opaque to the server as to content, it is not, as a UTF-8 string, > opaque > to the server as to form. > > In the other case in which we want this data to be treated as opaque, > I > would prefer we simply dropped all talk of this being a UTF-8 string, > as > confusing. The XDR speciifcation of linktext4 raises interesting > issues. You could argue that we are not allowed, in a minor version, > to > change an existing XDR definition. However note that in RFC3530: > > linktext4 is typedef'd as utf8str_cs. (in both the text and .x > file > portion) > > utf8str_cs is typedef'd as utf8string. (in the .x file portion, > the > text typedefs it incorrectly as opaque). > > utf8string is typedef'd as opaque<>. (in the .x file portion, the > text typedefs it incorrectly as opaque). > > So consider if we typedef'd linktext4 as opaque<>, which is what it > is > effectively typedef'd as in v4.0. > > Is it really the case that we are obliged to maintain the exact chain > of > definition for existing ops, or only the result, which is that > linktext4 > winds up being opaque<>? If the former, I'll bet there are a bunch > of > cases in which we have changed the existing chain of definitions. > Could > we not legitimately typedef linktext4 as opaque<> in v4.1? I think > we > could. > > If we are stuck with the XDR/stringprep definition of this as UTF-8, > the > other way to deal with this if we want the opaque interpretation is > to > say: > > The data is intended to be a UTF-8 string. However, this data > is opaque to the server and it is not the server's > responsibility > to validate this data as UTF-8, either when creating a symbolic > link or when reading it. > > The trouble with this formulation is that if it isn't the server's > responsibility to make this UTF-8 (and the specfication of this as a > UTF-8 string is something other than pure bullshit) then it is the > client's and if it is the client's, he is obliged to do the > translations, but if he did that, he could not inter-operate with v2 > and > v3. So the client can't accept that responsibility and the > responsibility would have to be the application's. But we have no > business telling the applications what to do and they wouldn't listen > to > us anyway. > > > > _______________________________________________ > 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 Nov 28 17: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 1IxV6r-0001iB-8f; Wed, 28 Nov 2007 17:10:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxV6p-0001hE-Fv for nfsv4@ietf.org; Wed, 28 Nov 2007 17:10:19 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxV6p-0002Qm-24 for nfsv4@ietf.org; Wed, 28 Nov 2007 17:10:19 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IxV6n-0006iR-QD; Wed, 28 Nov 2007 17:10:17 -0500 Date: Wed, 28 Nov 2007 17:10:17 -0500 To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071128221017.GE7376@fieldses.org> References: <869679.80262.qm@web38105.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <869679.80262.qm@web38105.mail.mud.yahoo.com> User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.2 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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, Nov 28, 2007 at 01:22:06PM -0800, Mike Eisler wrote: > > In the other case in which we want this data to be treated as > > opaque, I would prefer we simply dropped all talk of this being a > > UTF-8 string, as confusing. The XDR speciifcation of linktext4 > > raises interesting issues. You could argue that we are not allowed, > > in a minor version, to change an existing XDR definition. However > > note that in RFC3530: > > > > linktext4 is typedef'd as utf8str_cs. (in both the text and .x > > file > > portion) > > > > utf8str_cs is typedef'd as utf8string. (in the .x file portion, > > the > > text typedefs it incorrectly as opaque). > > > > utf8string is typedef'd as opaque<>. (in the .x file portion, the > > text typedefs it incorrectly as opaque). > > > > So consider if we typedef'd linktext4 as opaque<>, which is what it > > is effectively typedef'd as in v4.0. > > > > Is it really the case that we are obliged to maintain the exact > > chain of definition for existing ops, or only the result, which is > > that linktext4 winds up being opaque<>? If the former, I'll bet > > there are a bunch of cases in which we have changed the existing > > chain of definitions. Could we not legitimately typedef linktext4 > > as opaque<> in v4.1? I think we could. That would be great.... Do any servers currently guarantee that they return utf-8 data in symlinks? Linux's certainly doesn't, and won't for the forseeable future, because: - Popular Linux on-disk filesystems treat paths as arbitrary binary data (with only NULL and "/" being special). - We want the Linux server to be useful to Linux clients. - That means letting them store paths to non-nfsv4 filesystems in symlinks on nfsv4 filesystems. They won't be able to do that reliably if we insist on utf-8 symlinks. I just don't see a way out of the above. Help! --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 17:30: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 1IxVPr-0007bg-9I; Wed, 28 Nov 2007 17:29:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVPp-0007ba-M2 for nfsv4@ietf.org; Wed, 28 Nov 2007 17:29:57 -0500 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxVPp-0007DX-4r for nfsv4@ietf.org; Wed, 28 Nov 2007 17:29:57 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lASMTuQZ006652 for ; Wed, 28 Nov 2007 22:29:56 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lASMTtZ2037287 for ; Wed, 28 Nov 2007 15:29:56 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lASMTtsw002517; Wed, 28 Nov 2007 16:29:55 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lASMTsih002516; Wed, 28 Nov 2007 16:29:54 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Nov 2007 16:29:54 -0600 From: Nicolas Williams To: "J. Bruce Fields" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071128222954.GK1524@Sun.COM> Mail-Followup-To: "J. Bruce Fields" , Mike Eisler , nfsv4@ietf.org References: <869679.80262.qm@web38105.mail.mud.yahoo.com> <20071128221017.GE7376@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071128221017.GE7376@fieldses.org> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Mike Eisler , 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, Nov 28, 2007 at 05:10:17PM -0500, J. Bruce Fields wrote: > Do any servers currently guarantee that they return utf-8 data in > symlinks? Linux's certainly doesn't, and won't for the forseeable > future, because: MacOS X might (it normalizes to NFD on create in NFSv3, and Leopard, IIRC, has NFSv4 support). Solaris doesn't [yet], but nowadays OpenSolaris/Solaris Nevada does have the necessary framework for dealing with UTF-8 in NFSv4, and so we would have to know how to deal with symlinks... soon. That said, symlinks can and do contain non-pathname contents in many cases. Restricting symlinks to UTF-8 may not be the best thing to do. But when a client follows a symlink it will have to know what to do with any non-UTF-8 sequences therein -- the only reasonable thing to do, at first blush, in such cases is to return an error to the application. But there's the possibility that a symlink might have a pathname that contains codepoints that are, from a client's p.o.v., unassigned. Should a client try to follow symlinks with such pathnames? I think the answer is "yes." My proposal: - let symlinks be opaque<> - recommend that clients refuse to follow symlinks with illegal UTF-8 octet sequences - recommand that clients do follow symlinks with unassigned codepoints, provided there are no illegal UTF-8 octet sequences in them > - Popular Linux on-disk filesystems treat paths as arbitrary > binary data (with only NULL and "/" being special). Let's call this behaviour "just-use-8" for simplicity (we use it elsewhere). > - We want the Linux server to be useful to Linux clients. > > - That means letting them store paths to non-nfsv4 filesystems > in symlinks on nfsv4 filesystems. They won't be able to do > that reliably if we insist on utf-8 symlinks. Symlinks are the _least_ of your problem if you have just-use-8 clients and servers. > I just don't see a way out of the above. Help! See: http://blogs.sun.com/nico/entry/filesystem_i18n Short version: - Your best bet on the server is to treat all UTF-8-looking octet sequences as per NFSv4/NFSv4.1, have a knob to reject/allow non-UTF-8, and implement normalization-insenstive LOOKUPs. - On the client side you should refrain from using non-UTF-8 locales. Alternatively you should implement codeset conversions in your libc/glibc system call stubs when in non-UTF-8/ASCII/C locales. - Provide tools for finding and converting legacy filesystem contents. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 18:10: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 1IxW3H-0006F7-5x; Wed, 28 Nov 2007 18:10:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxW3G-0006DS-20 for nfsv4@ietf.org; Wed, 28 Nov 2007 18:10:42 -0500 Received: from web38106.mail.mud.yahoo.com ([209.191.124.133]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxW3F-0000Ot-MA for nfsv4@ietf.org; Wed, 28 Nov 2007 18:10:42 -0500 Received: (qmail 17088 invoked by uid 60001); 28 Nov 2007 23:10:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=w/OvFYS2mOD0THcLljMC7HQZWuMcZOly2qv2vqZV0UvdGO2EPcLVRsbb5jmzte98WJ/kCgfczqxfE8kPv+BWYK+K9GXK84NhfGkFlQjnAbLHF3rNkBY1du9thm/XCb76NYeTxJOvea1eQyr1Dx5ny9h7qseGyrO8diUdN3eU4jw=; X-YMail-OSG: WEW1GaEVM1kN0xt_GPOFhtSkILCY643J4BcTmoEpTu..Hu.a.JFHZ70DdT111x9XsF80DclpGw-- Received: from [198.95.226.230] by web38106.mail.mud.yahoo.com via HTTP; Wed, 28 Nov 2007 15:10:41 PST Date: Wed, 28 Nov 2007 15:10:41 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071128221017.GE7376@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <177167.16972.qm@web38106.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "J. Bruce Fields" wrote: > Do any servers currently guarantee that they return utf-8 data in > symlinks? Linux's certainly doesn't, and won't for the forseeable > future, because: > > - Popular Linux on-disk filesystems treat paths as arbitrary > binary data (with only NULL and "/" being special). So what happens when a process opens the symlink? What character set is used to process the pathname? If the path to the symlink is "/mnt/a/b/symlink" and a/b/symlink are on the serveer, doesn't the client expect the character set of what's in "symlink" to match that of "a/b/symlink"? > - We want the Linux server to be useful to Linux clients. > > - That means letting them store paths to non-nfsv4 filesystems > in symlinks on nfsv4 filesystems. They won't be able to do > that reliably if we insist on utf-8 symlinks. Don't you have the same problem with path names to file objects? What if a client wants to create a file with non-UTF-8 characters? What does the Linux server do? It seems to me that if the creating files with UTF-8 names is not a problem, creating symlinks with UTF-8 content is not problem. > > I just don't see a way out of the above. Help! > > --b. > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 18:42: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 1IxWY8-0007LZ-4N; Wed, 28 Nov 2007 18:42:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWY7-0007LS-7a for nfsv4@ietf.org; Wed, 28 Nov 2007 18:42:35 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxWY4-0001Sp-Vi for nfsv4@ietf.org; Wed, 28 Nov 2007 18:42:35 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IxWY3-0008TP-Ko; Wed, 28 Nov 2007 18:42:31 -0500 Date: Wed, 28 Nov 2007 18:42:31 -0500 To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071128234231.GH7376@fieldses.org> References: <20071128221017.GE7376@fieldses.org> <177167.16972.qm@web38106.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <177167.16972.qm@web38106.mail.mud.yahoo.com> User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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, Nov 28, 2007 at 03:10:41PM -0800, Mike Eisler wrote: > > --- "J. Bruce Fields" wrote: > > > Do any servers currently guarantee that they return utf-8 data in > > symlinks? Linux's certainly doesn't, and won't for the forseeable > > future, because: > > > > - Popular Linux on-disk filesystems treat paths as arbitrary > > binary data (with only NULL and "/" being special). > > So what happens when a process opens the symlink? What character > set is used to process the pathname? I don't understand what you mean by "use a character set to process a pathname". The system calls and posix api's that deal with paths just take char *'s. They aren't given anything that would identify the paths as using a particular character set. > If the path to the symlink is > "/mnt/a/b/symlink" > and a/b/symlink are on the serveer, doesn't the client expect the > character set of what's in "symlink" to match that of "a/b/symlink"? No, The client just takes a the contents of symlink, splits it at the "/" characters, and does lookups for each component. Those components may fall into different filesystems with different ideas about what a legal pathname component looks like. > > > > - We want the Linux server to be useful to Linux clients. > > > > - That means letting them store paths to non-nfsv4 filesystems > > in symlinks on nfsv4 filesystems. They won't be able to do > > that reliably if we insist on utf-8 symlinks. > > Don't you have the same problem with path names to file objects? > What if a client wants to create a file with non-UTF-8 characters? > What does the Linux server do? We give it to the filesystem and let it decide. If you want a fully NFSv4-compliant(TM) server then you should be exporting a filesystem that enforces the utf-8 requirement. Absent enforcement from the filesystem, I don't see any hope of making utf-8 restrictions work in the presence of v2/v3 clients and local processes. > It seems to me that if the creating files with UTF-8 names > is not a problem, creating symlinks with UTF-8 content is not > problem. It's a different problem. Even if we could demand that any filesystem that we exported require utf-8, we couldn't demand that none of our clients mount a filesystem with non-utf8 pathnames. --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 18:58: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 1IxWnu-00048U-Nb; Wed, 28 Nov 2007 18:58:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWns-00047O-IY for nfsv4@ietf.org; Wed, 28 Nov 2007 18:58:53 -0500 Received: from web38106.mail.mud.yahoo.com ([209.191.124.133]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxWns-0006hM-0t for nfsv4@ietf.org; Wed, 28 Nov 2007 18:58:52 -0500 Received: (qmail 34741 invoked by uid 60001); 28 Nov 2007 23:58:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=RhRcdbN5GgNSHxsB3YVxrBOTZluu9Dz4HQlaFXPJxFfm4jOKw7VXAPKbO76cFn9I4doqTH/EfzkPB2eLrHJzI7pa5HQ85/r/l6tOHur2xuBDVjxf6LzaR39P5qlvsAUvR8KspIWHVWhvazAwWDCsUccWkCuLilQnuESqBWLs29A=; X-YMail-OSG: OzEjfh8VM1mzgaYF_8N4alubhdIWpwBVP5pGBHWj76nSGVYhXXBDCW3Vh9DveO3oos9iyJppfw-- Received: from [198.95.226.230] by web38106.mail.mud.yahoo.com via HTTP; Wed, 28 Nov 2007 15:58:50 PST Date: Wed, 28 Nov 2007 15:58:50 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071128234231.GH7376@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <688823.34235.qm@web38106.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "J. Bruce Fields" wrote: > On Wed, Nov 28, 2007 at 03:10:41PM -0800, Mike Eisler wrote: > > > > --- "J. Bruce Fields" wrote: > > > > > Do any servers currently guarantee that they return utf-8 data in > > > symlinks? Linux's certainly doesn't, and won't for the > forseeable > > > future, because: > > > > > > - Popular Linux on-disk filesystems treat paths as arbitrary > > > binary data (with only NULL and "/" being special). > > > > So what happens when a process opens the symlink? What character > > set is used to process the pathname? > > I don't understand what you mean by "use a character set to process a > pathname". The system calls and posix api's that deal with paths I was curious if 16 bit or 32 bit characters were being used. > just > take char *'s. They aren't given anything that would identify the > paths > as using a particular character set. > > > If the path to the symlink is > > "/mnt/a/b/symlink" > > and a/b/symlink are on the serveer, doesn't the client expect the > > character set of what's in "symlink" to match that of > "a/b/symlink"? > > No, The client just takes a the contents of symlink, splits it at the > "/" characters, and does lookups for each component. Those OK, I get it. > components > may fall into different filesystems with different ideas about what a > legal pathname component looks like. > > > > > > > > - We want the Linux server to be useful to Linux clients. > > > > > > - That means letting them store paths to non-nfsv4 filesystems > > > in symlinks on nfsv4 filesystems. They won't be able to do > > > that reliably if we insist on utf-8 symlinks. > > > > Don't you have the same problem with path names to file objects? > > What if a client wants to create a file with non-UTF-8 characters? > > What does the Linux server do? > > We give it to the filesystem and let it decide. If you want a fully > NFSv4-compliant(TM) server then you should be exporting a filesystem > that enforces the utf-8 requirement. So your server's READDIR will return directory entries that aren't legal UTF-8? > > Absent enforcement from the filesystem, I don't see any hope of > making > utf-8 restrictions work in the presence of v2/v3 clients and local > processes. > > > It seems to me that if the creating files with UTF-8 names > > is not a problem, creating symlinks with UTF-8 content is not > > problem. > > It's a different problem. Even if we could demand that any > filesystem > that we exported require utf-8, we couldn't demand that none of our > clients mount a filesystem with non-utf8 pathnames. I don't follow how it is different. You seem to be saying that regardless what the specification says, your server treats component names as 8 bit opaque characters. How do you expect clients to display the right glyphs for a character if the server renders illegal utf-8? > > --b. > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 19:15: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 1IxX43-0004J1-C3; Wed, 28 Nov 2007 19:15:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxX42-0004Io-6m for nfsv4@ietf.org; Wed, 28 Nov 2007 19:15:34 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxX41-0007HU-KL for nfsv4@ietf.org; Wed, 28 Nov 2007 19:15:34 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAT0FXx6020964 for ; Thu, 29 Nov 2007 00:15:33 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAT0FWmC010847 for ; Wed, 28 Nov 2007 17:15:32 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAT0FW0E002586; Wed, 28 Nov 2007 18:15:32 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAT0FVNe002585; Wed, 28 Nov 2007 18:15:31 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Nov 2007 18:15:31 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129001531.GD2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <20071128234231.GH7376@fieldses.org> <688823.34235.qm@web38106.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <688823.34235.qm@web38106.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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, Nov 28, 2007 at 03:58:50PM -0800, Mike Eisler wrote: > --- "J. Bruce Fields" wrote: > > On Wed, Nov 28, 2007 at 03:10:41PM -0800, Mike Eisler wrote: > > > --- "J. Bruce Fields" wrote: > > > > Do any servers currently guarantee that they return utf-8 data in > > > > symlinks? Linux's certainly doesn't, and won't for the > > forseeable > > > > future, because: > > > > > > > > - Popular Linux on-disk filesystems treat paths as arbitrary > > > > binary data (with only NULL and "/" being special). > > > > > > So what happens when a process opens the symlink? What character > > > set is used to process the pathname? Usually processes _follow_ symlinks without even knowing they are there. But when the read the symlink they should get the contents of it as it exists on the server. If two users are exchanging non-pathname data via symlinks and they don't agree on codesets, well, too bad. If two users are exchanging pathname data via symlinks and they don't agree on codesets, then as long as the pathname in the symlink exists then it should be possible to traverse it _provided_ that the client following the symlink doesn't transform the symlink's contents in any way. > > I don't understand what you mean by "use a character set to process a > > pathname". The system calls and posix api's that deal with paths > > I was curious if 16 bit or 32 bit characters were being > used. Huh? Oh boy, no, you really need to define a character width and codeset for use between the system call layer and the filesystem. Just-use-8 will work provided all users are using UTF-8 locales. And just-use-8 will work for US-ASCII names provided that all users are using single-byte or variable-width codeset locales that are US-ASCII compatible (ISO-8859-*, UTF-8, ...). But throw in UTF-16 or UTF-32 locales and I think you've got big problems in a just-use-8 system. > > We give it to the filesystem and let it decide. If you want a fully > > NFSv4-compliant(TM) server then you should be exporting a filesystem > > that enforces the utf-8 requirement. > > So your server's READDIR will return directory entries that > aren't legal UTF-8? Clients need to be ready to deal with such servers, because legacy filesystem contents exists. Servers might well reject CREATEs of non-UTF-8 names while still allowing LOOKUPs of and READDIRs that include existing non-UTF-8 names. > > > It seems to me that if the creating files with UTF-8 names > > > is not a problem, creating symlinks with UTF-8 content is not > > > problem. > > > > It's a different problem. Even if we could demand that any > > filesystem that we exported require utf-8, we couldn't demand that > > none of our clients mount a filesystem with non-utf8 pathnames. > > I don't follow how it is different. You seem to be saying that > regardless what the specification says, your server treats > component names as 8 bit opaque characters. It is different because symlinks have been defined from the get-go as being allowed to contain non-pathname data. Therefore constraining them to contain UTF-8 seems a bit harsh (though probably livable). > How do you expect clients to display the right glyphs for a character > if the server renders illegal utf-8? "renders"? The answer is: the way clients generally tend to do in many other cases, namely, by replacing them with question marks or some other appropriate glyph. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 19:17: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 1IxX68-0005ft-Jb; Wed, 28 Nov 2007 19:17:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxX67-0005al-Js for nfsv4@ietf.org; Wed, 28 Nov 2007 19:17:43 -0500 Received: from web38102.mail.mud.yahoo.com ([209.191.124.129]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxX67-0002ik-7z for nfsv4@ietf.org; Wed, 28 Nov 2007 19:17:43 -0500 Received: (qmail 91419 invoked by uid 60001); 29 Nov 2007 00:17:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=CCx8QY2Onlm9oXAuoET2C1X5AtCAdERP+OjI24OFlfjVmAGLniY/A+edZ9dLEJDJGMd9BkEPJf6nbfQhcC6wAv7bmbIlnYjFPu/Y2UuGyypdkIcZEsJLg9riVuCckus6Wn4cGCVx/2GRchoHDIeI1gxlxHfzF7UdwUBfXCnLHX0=; X-YMail-OSG: Q9rESzMVM1lzs.7CFecH4SV5H.imSNzZrp5JqxBhb7c4n1nZ_IpbSAniM.TZbvRfMG1WxAfHCLAhFkLAS7bFKpiISP6Qu9sYXtMOGJieZ85MrsMBuAg- Received: from [198.95.226.230] by web38102.mail.mud.yahoo.com via HTTP; Wed, 28 Nov 2007 16:17:42 PST Date: Wed, 28 Nov 2007 16:17:42 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071128222954.GK1524@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <771812.91113.qm@web38102.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Nicolas Williams wrote: > That said, symlinks can and do contain non-pathname contents in many > cases. Restricting symlinks to UTF-8 may not be the best thing to > do. So when an app like the ls command reads a symlink and displays its contents, what does it display when it finds non-utf-8 in it? > But when a client follows a symlink it will have to know what to do > with > any non-UTF-8 sequences therein -- the only reasonable thing to do, > at > first blush, in such cases is to return an error to the application. What does one do at second blush? > My proposal: > > - let symlinks be opaque<> why stop there? > http://blogs.sun.com/nico/entry/filesystem_i18n > > Short version: > > - Your best bet on the server is to treat all UTF-8-looking octet > sequences as per NFSv4/NFSv4.1, have a knob to reject/allow > non-UTF-8, and implement normalization-insenstive LOOKUPs. > > - On the client side you should refrain from using non-UTF-8 > locales. > Alternatively you should implement codeset conversions in your > libc/glibc system call stubs when in non-UTF-8/ASCII/C locales. > > - Provide tools for finding and converting legacy filesystem > contents. The problem is that NFSv3 implemented to be 8 bit clean. Many, if not most, non-ASCII deployments of NFSv3 don't use UTF-8. Lots of data today is stored on NAS devices that allow access via file access protocols like CIFS that do mandate things like Unicode, no weaseling out permitted. What to do? - declare the character set for the fsid - convert from the character set to Unicode if using CIFS - convert from the character set to UTF-8 if using NFSv4 - for NFSv3, if the declared character set uses 8 bit characters do not convert. If the declared character set uses 16 bit or higher characters, convert to UTF-8 and hope for best. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 19:19:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxX7h-0006tc-AR; Wed, 28 Nov 2007 19:19:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxX7f-0006gX-Co for nfsv4@ietf.org; Wed, 28 Nov 2007 19:19:19 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxX7f-0007S6-2d for nfsv4@ietf.org; Wed, 28 Nov 2007 19:19:19 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IxX7d-0000jz-Ti; Wed, 28 Nov 2007 19:19:17 -0500 Date: Wed, 28 Nov 2007 19:19:17 -0500 To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129001917.GJ7376@fieldses.org> References: <20071128234231.GH7376@fieldses.org> <688823.34235.qm@web38106.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <688823.34235.qm@web38106.mail.mud.yahoo.com> User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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, Nov 28, 2007 at 03:58:50PM -0800, Mike Eisler wrote: > > --- "J. Bruce Fields" wrote: > > It's a different problem. Even if we could demand that any > > filesystem > > that we exported require utf-8, we couldn't demand that none of our > > clients mount a filesystem with non-utf8 pathnames. > > I don't follow how it is different. The difference is: - In one case I just need to insist that all the paths on filesystems I export be utf-8. - In the symlink case, I need to insist that all the paths on all the *other* filesystems that my client mounts *also* be utf-8, whether those other filesystems are nfsv4 or ext3. At least if they want symlinks to work. Symlinks on an nfsv4-mounted /home should be able to refer to paths on an ext3-mounted /. --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 19:25: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 1IxXDQ-0004m9-Cr; Wed, 28 Nov 2007 19:25:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXDP-0004ly-Lp for nfsv4@ietf.org; Wed, 28 Nov 2007 19:25:15 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxXDN-0002zy-UP for nfsv4@ietf.org; Wed, 28 Nov 2007 19:25:15 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAT0PDbJ024293 for ; Thu, 29 Nov 2007 00:25:13 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAT0PCkV015699 for ; Wed, 28 Nov 2007 17:25:13 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAT0PC9n002598; Wed, 28 Nov 2007 18:25:12 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAT0PCpq002597; Wed, 28 Nov 2007 18:25:12 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Nov 2007 18:25:12 -0600 From: Nicolas Williams To: "J. Bruce Fields" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129002512.GE2540@Sun.COM> Mail-Followup-To: "J. Bruce Fields" , Mike Eisler , nfsv4@ietf.org References: <20071128234231.GH7376@fieldses.org> <688823.34235.qm@web38106.mail.mud.yahoo.com> <20071129001917.GJ7376@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071129001917.GJ7376@fieldses.org> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Mike Eisler , 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, Nov 28, 2007 at 07:19:17PM -0500, J. Bruce Fields wrote: > > I don't follow how it is different. > > The difference is: > > - In one case I just need to insist that all the paths on > filesystems I export be utf-8. All new paths. In practice you'll have to allow legacy objects to retain their legacy names. > - In the symlink case, I need to insist that all the paths on > all the *other* filesystems that my client mounts *also* be > utf-8, whether those other filesystems are nfsv4 or ext3. At > least if they want symlinks to work. Users already need to create symlinks with valid pathnames when that is what they want. If a user is running in a non-UTF-8, non-ASCII locale and they cut-and-paste what should be a UTF-8 path but which has been codeset converted to another locale, well, they'll create a bogus symlink. This is true. The only way out of that is to have the client convert back to UTF-8 when creating the symlink. In such an environment the client would have to be converting to/grom UTF-8 in lots of other places, so might as well. That doesn't mean that the spec should REQUIRE that symlink content be UTF-8 -- it need only REQUIRE or RECOMMEND that symlink content that is intended to be traversable as a pathname be in the correct codeset, namely (for an all NFSv4/UTF-8 environment) UTF-8. > Symlinks on an nfsv4-mounted /home should be able to refer to paths on > an ext3-mounted /. Off-topic: can't you use UTF-8 in ext3 filesystems? Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 19:29: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 1IxXH0-0005RQ-IG; Wed, 28 Nov 2007 19:28:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXGz-0005Mo-Bt for nfsv4@ietf.org; Wed, 28 Nov 2007 19:28:57 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxXGy-00038n-W2 for nfsv4@ietf.org; Wed, 28 Nov 2007 19:28:57 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IxXGy-0000we-1v; Wed, 28 Nov 2007 19:28:56 -0500 Date: Wed, 28 Nov 2007 19:28:56 -0500 To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129002855.GK7376@fieldses.org> References: <20071128234231.GH7376@fieldses.org> <688823.34235.qm@web38106.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <688823.34235.qm@web38106.mail.mud.yahoo.com> User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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, Nov 28, 2007 at 03:58:50PM -0800, Mike Eisler wrote: > > --- "J. Bruce Fields" wrote: > > > On Wed, Nov 28, 2007 at 03:10:41PM -0800, Mike Eisler wrote: > > > Don't you have the same problem with path names to file objects? > > > What if a client wants to create a file with non-UTF-8 characters? > > > What does the Linux server do? > > > > We give it to the filesystem and let it decide. If you want a fully > > NFSv4-compliant(TM) server then you should be exporting a filesystem > > that enforces the utf-8 requirement. > > So your server's READDIR will return directory entries that > aren't legal UTF-8? Yep, it may. I'm not particularly proud of it. It's just the least worst option I see given the requirements and the available time. (Responding separately because I really think it is a separate issue--one is about imposing requirements on the server's own path components, the other is about imposing requirements on client-side paths which may not touch nfsv4 filesystems at all.) --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 19:29: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 1IxXHl-0005mZ-HM; Wed, 28 Nov 2007 19:29:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXHk-0005m6-Fp for nfsv4@ietf.org; Wed, 28 Nov 2007 19:29:44 -0500 Received: from web38106.mail.mud.yahoo.com ([209.191.124.133]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxXHk-0007tq-1P for nfsv4@ietf.org; Wed, 28 Nov 2007 19:29:44 -0500 Received: (qmail 46663 invoked by uid 60001); 29 Nov 2007 00:29:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=raLEqei/vgD/5nto7i548YTJMdv3RzZDvjl57VfRwtXuNBgpz9jZQCOE+/VcnjGOrFizypaVXasHp9JBtkTNvpMO+/4hNGZZDrMgLC0bhnR8kbphl0eQsOyPQBWI2ibCwTL2hed8tQZ54u03Lqd2kZOCd70VXLoBAsZ8LUo0f4I=; X-YMail-OSG: S8zIFhYVM1ljVHTt9Xp23ODgnu5e3rZP2Q0jsbuQCe4Qi6Y2zJjBzfVLMaXGeUOP.QtfCd56AQ-- Received: from [198.95.226.230] by web38106.mail.mud.yahoo.com via HTTP; Wed, 28 Nov 2007 16:29:43 PST Date: Wed, 28 Nov 2007 16:29:43 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071129001531.GD2540@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <230454.46502.qm@web38106.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Nicolas Williams wrote: > > > We give it to the filesystem and let it decide. If you want a > fully > > > NFSv4-compliant(TM) server then you should be exporting a > filesystem > > > that enforces the utf-8 requirement. > > > > So your server's READDIR will return directory entries that > > aren't legal UTF-8? > > Clients need to be ready to deal with such servers, because legacy > filesystem contents exists. Servers might well reject CREATEs of > non-UTF-8 names while still allowing LOOKUPs of and READDIRs that > include existing non-UTF-8 names. So if servers can return non-UTF-8 in readdir and readlink, then what's the point? Either a server can cope with UTF-8 or not. If it cannot, and is going to ignore the spec, then what difference does it make if we mandate UTF-8? Bruce will deal with his unsolvable problem by returning non-UTF-8 every where, and allowing non0UTF-8 every where. If that's what his server does and if clients are OK with that, why should we care? It's not like anyone cared until Dave kicked the hornets' nest. UTF-8 is a tool, use it or not, but I don't see why we should weaken the spec because some cannot or will not use it. > > I don't follow how it is different. You seem to be saying that > > regardless what the specification says, your server treats > > component names as 8 bit opaque characters. > > It is different because symlinks have been defined from the get-go as > being allowed to contain non-pathname data. Therefore constraining > them > to contain UTF-8 seems a bit harsh (though probably livable). Sorry, I don't see the difference. User names in NFSv4 don't have path names data and they are mandated to have UTF-8 (not that I have any faith that all NFSv4 user names are encoded in UTF-8). > > How do you expect clients to display the right glyphs for a > character > > if the server renders illegal utf-8? > > "renders"? > > The answer is: the way clients generally tend to do in many other > cases, > namely, by replacing them with question marks or some other > appropriate > glyph. Well that's useful. :-( _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 19:37: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 1IxXPg-000799-0v; Wed, 28 Nov 2007 19:37:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXPe-0006uo-VY for nfsv4@ietf.org; Wed, 28 Nov 2007 19:37:54 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxXPe-0003Sh-IK for nfsv4@ietf.org; Wed, 28 Nov 2007 19:37:54 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IxXPc-00017A-QR; Wed, 28 Nov 2007 19:37:52 -0500 Date: Wed, 28 Nov 2007 19:37:52 -0500 To: Mike Eisler , nfsv4@ietf.org Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129003752.GL7376@fieldses.org> References: <20071128234231.GH7376@fieldses.org> <688823.34235.qm@web38106.mail.mud.yahoo.com> <20071129001917.GJ7376@fieldses.org> <20071129002512.GE2540@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071129002512.GE2540@Sun.COM> User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 On Wed, Nov 28, 2007 at 06:25:12PM -0600, Nicolas Williams wrote: > On Wed, Nov 28, 2007 at 07:19:17PM -0500, J. Bruce Fields wrote: > > > I don't follow how it is different. > > > > The difference is: > > > > - In one case I just need to insist that all the paths on > > filesystems I export be utf-8. > > All new paths. In practice you'll have to allow legacy objects to > retain their legacy names. > > > - In the symlink case, I need to insist that all the paths on > > all the *other* filesystems that my client mounts *also* be > > utf-8, whether those other filesystems are nfsv4 or ext3. At > > least if they want symlinks to work. > > Users already need to create symlinks with valid pathnames when that is > what they want. If a user is running in a non-UTF-8, non-ASCII locale > and they cut-and-paste what should be a UTF-8 path but which has been > codeset converted to another locale, well, they'll create a bogus > symlink. This is true. That's not the example that concerns me. If some file on another filesystem only exists under a path that contains non-utf8 characters, how will a user create a symlink to it on an nfsv4 filesystem? > > The only way out of that is to have the client convert back to UTF-8 > when creating the symlink. In such an environment the client would have > to be converting to/grom UTF-8 in lots of other places, so might as > well. > > That doesn't mean that the spec should REQUIRE that symlink content be > UTF-8 -- it need only REQUIRE or RECOMMEND that symlink content that is > intended to be traversable as a pathname be in the correct codeset, > namely (for an all NFSv4/UTF-8 environment) UTF-8. > > > Symlinks on an nfsv4-mounted /home should be able to refer to paths on > > an ext3-mounted /. > > Off-topic: can't you use UTF-8 in ext3 filesystems? Sure. The filesystem doesn't know or care that you're using utf-8, though. --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 19:41: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 1IxXTa-00030l-Vg; Wed, 28 Nov 2007 19:41:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXTa-00030a-1t for nfsv4@ietf.org; Wed, 28 Nov 2007 19:41:58 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxXTZ-0003aB-Fw for nfsv4@ietf.org; Wed, 28 Nov 2007 19:41:58 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAT0fv6A012609 for ; Thu, 29 Nov 2007 00:41:57 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAT0fuUV024685 for ; Wed, 28 Nov 2007 17:41:56 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAT0fu7d002635; Wed, 28 Nov 2007 18:41:56 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAT0futI002634; Wed, 28 Nov 2007 18:41:56 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Nov 2007 18:41:56 -0600 From: Nicolas Williams To: "J. Bruce Fields" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129004155.GG2540@Sun.COM> Mail-Followup-To: "J. Bruce Fields" , Mike Eisler , nfsv4@ietf.org References: <20071128234231.GH7376@fieldses.org> <688823.34235.qm@web38106.mail.mud.yahoo.com> <20071129001917.GJ7376@fieldses.org> <20071129002512.GE2540@Sun.COM> <20071129003752.GL7376@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071129003752.GL7376@fieldses.org> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Mike Eisler , 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, Nov 28, 2007 at 07:37:52PM -0500, J. Bruce Fields wrote: > On Wed, Nov 28, 2007 at 06:25:12PM -0600, Nicolas Williams wrote: > > Users already need to create symlinks with valid pathnames when that is > > what they want. If a user is running in a non-UTF-8, non-ASCII locale > > and they cut-and-paste what should be a UTF-8 path but which has been > > codeset converted to another locale, well, they'll create a bogus > > symlink. This is true. > > That's not the example that concerns me. > > If some file on another filesystem only exists under a path that > contains non-utf8 characters, how will a user create a symlink to it on > an nfsv4 filesystem? If we define symlink contents as opaque then it should just work, modulo local implementation details. > > The only way out of that is to have the client convert back to UTF-8 > > when creating the symlink. In such an environment the client would have > > to be converting to/grom UTF-8 in lots of other places, so might as > > well. > > > > That doesn't mean that the spec should REQUIRE that symlink content be > > UTF-8 -- it need only REQUIRE or RECOMMEND that symlink content that is > > intended to be traversable as a pathname be in the correct codeset, > > namely (for an all NFSv4/UTF-8 environment) UTF-8. > > > > > Symlinks on an nfsv4-mounted /home should be able to refer to paths on > > > an ext3-mounted /. > > > > Off-topic: can't you use UTF-8 in ext3 filesystems? > > Sure. The filesystem doesn't know or care that you're using utf-8, > though. But it might. What stops you from having an option to reject non-UTF-8 creates? Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 19:49: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 1IxXas-0003vA-9Q; Wed, 28 Nov 2007 19:49:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXar-0003v5-ID for nfsv4@ietf.org; Wed, 28 Nov 2007 19:49:29 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxXar-0003uv-8V for nfsv4@ietf.org; Wed, 28 Nov 2007 19:49:29 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IxXap-0001Kh-GH; Wed, 28 Nov 2007 19:49:27 -0500 Date: Wed, 28 Nov 2007 19:49:27 -0500 To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129004927.GM7376@fieldses.org> References: <20071129001531.GD2540@Sun.COM> <230454.46502.qm@web38106.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <230454.46502.qm@web38106.mail.mud.yahoo.com> User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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, Nov 28, 2007 at 04:29:43PM -0800, Mike Eisler wrote: > Either a server can cope with UTF-8 or not. > > If it cannot, and is going to ignore the spec, then what difference > does it make if we mandate UTF-8? Bruce will deal with his > unsolvable problem by returning non-UTF-8 every where, and > allowing non0UTF-8 every where. If that's what his server does > and if clients are OK with that, why should we care? OK with me. I guess I took for granted the original claim that there was an interoperability problem if some implementations treated symlinks as utf-8 and some didn't. If that's true, then the spec should state that many (most? all?) servers don't actually do this, as that's the information that will help future implementations interoperate with the ones that are actually deployed. But probably the interoperability problems aren't a big deal, fair enough. Other than the obvious "I tried to cp this symlink from A to B, and B won't accept it", which I suppose has already existed for filenames for a while. Seems a silly to me, but whatever. --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Reynant@Kayne.com Wed Nov 28 21:33:35 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZDb-0003XU-71 for nfsv4-archive@lists.ietf.org; Wed, 28 Nov 2007 21:33:35 -0500 Received: from i209-195-104-155.cia.com ([209.195.104.155] helo=i209-195-71-170.cia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxZDa-0003bh-Sf for nfsv4-archive@lists.ietf.org; Wed, 28 Nov 2007 21:33:35 -0500 Received: from rula-8jakj8vdgl by Kayne.com with ASMTP id E09638E8 for ; Wed, 28 Nov 2007 21:33:52 -0500 Received: from rula-8jakj8vdgl ([139.102.1.198]) by Kayne.com with ESMTP id 99FA8F5A8DF6 for ; Wed, 28 Nov 2007 21:33:52 -0500 Message-ID: <000601c83230$382113d0$aa47c3d1@rula8jakj8vdgl> From: "Reynant Hargrave" To: Subject: eloksret Date: Wed, 28 Nov 2007 21:33:26 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C83206.4F4C9270" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.3 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0007_01C83206.4F4C9270 Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable You only live once so why not be the best that you can be? = http://www.elastram.com/ ------=_NextPart_000_0007_01C83206.4F4C9270 Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
You only live once so why not be the best that you = can be?=20 http://www.elastram.com/
------=_NextPart_000_0007_01C83206.4F4C9270-- From nfsv4-bounces@ietf.org Wed Nov 28 21:38: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 1IxZI5-0000nl-B0; Wed, 28 Nov 2007 21:38:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZI4-0000ng-4C for nfsv4@ietf.org; Wed, 28 Nov 2007 21:38:12 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxZI3-0003mX-Kp for nfsv4@ietf.org; Wed, 28 Nov 2007 21:38:12 -0500 X-IronPort-AV: E=Sophos;i="4.23,226,1194249600"; d="scan'208";a="127086218" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 28 Nov 2007 18:38:10 -0800 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 lAT2cAgp012306; Wed, 28 Nov 2007 18:38:10 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 18:38:10 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 18:38:09 -0800 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] symlinks: opaque or UTF-8 Date: Wed, 28 Nov 2007 21:38:17 -0500 Message-ID: In-Reply-To: <20071129004927.GM7376@fieldses.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgyIbmE6RC44FV3RG6YyIXGVwgwuwAAPDOQ From: "Noveck, Dave" To: "J. Bruce Fields" , "Mike Eisler" X-OriginalArrivalTime: 29 Nov 2007 02:38:09.0947 (UTC) FILETIME=[E147FEB0:01C83230] X-Spam-Score: 0.2 (/) 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 > I guess I took for granted the original claim that there was an=20 > interoperability problem if some implementations treated symlinks=20 > as utf-8 and some didn't. If that's true, then the spec should=20 > state that many (most? all?) servers don't actually do this, as=20 > that's the information that will help future implementations=20 > interoperate with the ones that are actually deployed. Huh? How can the spec doing a meaningful survey of v4.1 servers at this point, which is when we are ready to close on it. We=20 could do a survey of v4.0 servers but the v4.0 spec is already done. Anyway the v4.1 spec is not intended to be an Informational RFC. Its job is to define what the clients and servers should do=20 in order to interoperate. If some 75% of the servers are=20 treating this as opaque then stating that would help client be compatible with 75% of the servers but that is not good. The idea of interoperablity is that you can be compatible with 100%, if we all obey the protocol.=20 > But probably the interoperability problems aren't a big deal,=20 > fair enough. They are a big deal. If clients don't treat this data as UTF-8, servers can't either, and vice versa. The thing we have to decide is whether that is a desirable (or unavoidable) state of affairs. I think Mike should have been explicit about his "" and "" tags. -----Original Message----- From: J. Bruce Fields [mailto:bfields@fieldses.org]=20 Sent: Wednesday, November 28, 2007 7:49 PM To: Mike Eisler Cc: nfsv4@ietf.org Subject: Re: [nfsv4] symlinks: opaque or UTF-8 On Wed, Nov 28, 2007 at 04:29:43PM -0800, Mike Eisler wrote: > Either a server can cope with UTF-8 or not. >=20 > If it cannot, and is going to ignore the spec, then what difference=20 > does it make if we mandate UTF-8? Bruce will deal with his unsolvable=20 > problem by returning non-UTF-8 every where, and allowing non0UTF-8=20 > every where. If that's what his server does and if clients are OK with > that, why should we care? OK with me. I guess I took for granted the original claim that there was an interoperability problem if some implementations treated symlinks as utf-8 and some didn't. If that's true, then the spec should state that many (most? all?) servers don't actually do this, as that's the information that will help future implementations interoperate with the ones that are actually deployed. But probably the interoperability problems aren't a big deal, fair enough. Other than the obvious "I tried to cp this symlink from A to B, and B won't accept it", which I suppose has already existed for filenames for a while. Seems a silly to me, but whatever. --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 Wed Nov 28 21:40: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 1IxZKe-0004LF-Qr; Wed, 28 Nov 2007 21:40:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZKc-0004Kw-Ga for nfsv4@ietf.org; Wed, 28 Nov 2007 21:40:50 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxZKb-0007Bx-TP for nfsv4@ietf.org; Wed, 28 Nov 2007 21:40:50 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAT2enY1028935 for ; Thu, 29 Nov 2007 02:40:49 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS800801Y35HX00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 28 Nov 2007 19:40:49 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS800D9VY3SEW40@mail-amer.sun.com>; Wed, 28 Nov 2007 19:40:41 -0700 (MST) Date: Wed, 28 Nov 2007 20:40:41 -0600 From: Spencer Shepler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 In-reply-to: <20071129004927.GM7376@fieldses.org> To: "J. Bruce Fields" Message-id: <41F38D4E-1870-44C9-8EA0-4CFA6298B395@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: <20071129001531.GD2540@Sun.COM> <230454.46502.qm@web38106.mail.mud.yahoo.com> <20071129004927.GM7376@fieldses.org> X-Spam-Score: -0.8 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Mike Eisler , 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 Nov 28, 2007, at 6:49 PM, J. Bruce Fields wrote: > On Wed, Nov 28, 2007 at 04:29:43PM -0800, Mike Eisler wrote: >> Either a server can cope with UTF-8 or not. >> >> If it cannot, and is going to ignore the spec, then what difference >> does it make if we mandate UTF-8? Bruce will deal with his >> unsolvable problem by returning non-UTF-8 every where, and >> allowing non0UTF-8 every where. If that's what his server does >> and if clients are OK with that, why should we care? > > OK with me. Okay with me as well. > > I guess I took for granted the original claim that there was an > interoperability problem if some implementations treated symlinks as > utf-8 and some didn't. If that's true, then the spec should state > that > many (most? all?) servers don't actually do this, as that's the > information that will help future implementations interoperate with > the > ones that are actually deployed. This should not be in the specification. THe NFSv4.1 specification is not even complete so there are no implementation in existence and the decision about will be implemented will change over time so any statement about current capabilities will be stale. Spencer > > But probably the interoperability problems aren't a big deal, fair > enough. > > Other than the obvious "I tried to cp this symlink from A to B, and B > won't accept it", which I suppose has already existed for filenames > for > a while. Seems a silly to me, but whatever. > > --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 Wed Nov 28 22:18: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 1IxZvC-0000YB-W4; Wed, 28 Nov 2007 22:18:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZvC-0000Wc-4F for nfsv4@ietf.org; Wed, 28 Nov 2007 22:18:38 -0500 Received: from web38112.mail.mud.yahoo.com ([209.191.124.139]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxZvB-0008D1-Q6 for nfsv4@ietf.org; Wed, 28 Nov 2007 22:18:38 -0500 Received: (qmail 57703 invoked by uid 60001); 29 Nov 2007 03:18:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ch17aZjd9wvTlQr2wOQOFG9SwOW/WLHBl3LhxIAMnBEcUm2lXh45fsfdCdOyXK9u8yeJyZFqcCkNw6SwrkGscjcUBgGTZAbokQjf96a/7nizY9u9DCIYV1C9m4MCI6HQhaPbaH6sx5YVrmmlTHRqT+j6Fe/OvcB6UMswok5vV2Q=; X-YMail-OSG: pZEK8T0VM1mEFoNTaepq0LEKrt0AD5m5_kQvRnL2gNBczMUGobTu2YDkChs.96mOoFzPuL_Mkg-- Received: from [198.95.226.230] by web38112.mail.mud.yahoo.com via HTTP; Wed, 28 Nov 2007 19:18:37 PST Date: Wed, 28 Nov 2007 19:18:37 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <310151.56853.qm@web38112.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > I think Mike should have been explicit about his "" > and "" tags. I'm not being sarcastic. The protocol has an i18n requirement. No one has shown how we can meet the i18n requirement and cope with servers that have no clue what character set their metadata is in. Given that there are servers that can meet the requirement, why should we water down the protocol, and make interoperability even harder? _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 22:31: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 1Ixa82-0000X7-7S; Wed, 28 Nov 2007 22:31:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixa80-0000WR-Bw for nfsv4@ietf.org; Wed, 28 Nov 2007 22:31:52 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixa7z-0007Sp-Nc for nfsv4@ietf.org; Wed, 28 Nov 2007 22:31:51 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAT3VoVp029341 for ; Thu, 29 Nov 2007 03:31:50 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS900J010E1WZ00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 28 Nov 2007 20:31:50 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS9003B90H1UL30@mail-amer.sun.com>; Wed, 28 Nov 2007 20:31:50 -0700 (MST) Date: Wed, 28 Nov 2007 21:31:51 -0600 From: Spencer Shepler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 In-reply-to: <310151.56853.qm@web38112.mail.mud.yahoo.com> To: email2mre-ietf@yahoo.com Message-id: <0BEAB99B-0F15-41A5-A122-0EF1EF11E783@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 References: <310151.56853.qm@web38112.mail.mud.yahoo.com> X-Spam-Score: -0.8 (/) 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 Nov 28, 2007, at 9:18 PM, Mike Eisler wrote: > > --- "Noveck, Dave" wrote: > > >> I think Mike should have been explicit about his "" >> and "" tags. > > I'm not being sarcastic. > > The protocol has an i18n requirement. No one has shown how we can > meet the i18n requirement and cope with servers that have no clue what > character set their metadata is in. Given that there are servers that > can meet the requirement, why should we water down the protocol, and > make interoperability even harder? Yes, we need to move forward not backwards. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Wed Nov 28 22:38: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 1IxaEX-0000o0-32; Wed, 28 Nov 2007 22:38:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxaEV-0000nW-PS for nfsv4@ietf.org; Wed, 28 Nov 2007 22:38:35 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxaET-0004GD-It for nfsv4@ietf.org; Wed, 28 Nov 2007 22:38:35 -0500 X-IronPort-AV: E=Sophos;i="4.23,226,1194249600"; d="scan'208";a="127099322" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 28 Nov 2007 19:38:02 -0800 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 lAT3c2N9026872; Wed, 28 Nov 2007 19:38:02 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 19:38:02 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 19:38:02 -0800 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] symlinks: opaque or UTF-8 Date: Wed, 28 Nov 2007 22:38:09 -0500 Message-ID: In-Reply-To: <310151.56853.qm@web38112.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgyNvNrmhxvw1NcT8CkcuSVRhRgKQAALSNg From: "Noveck, Dave" To: , X-OriginalArrivalTime: 29 Nov 2007 03:38:02.0203 (UTC) FILETIME=[3E6EC2B0:01C83239] X-Spam-Score: -3.8 (---) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 not being sarcastic. Then I'm totally confused. > why should we water down the protocol, and make interoperability even harder?=20 Can you stop arguing for your position for a second and focus on making it clear what it is? So far, the only thing I had been sure of in this debate is that you and Bruce disagree on what should be done so when you argue for your position (with or without sarcasm) and Bruce's response is "OK with me", I'm at a total loss. Bruce is has been basically saying that we should treat this as opaque and that doesn't sound to me like what you are saying, unless I am totally confused, which is possible. So help me: Bruce, what is it that you are OK with? Spencer, what is it that you are OK with? Mike, what is it that Spencer and Bruce are OK with? :-) =20 -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Wednesday, November 28, 2007 10:19 PM To: nfsv4@ietf.org Subject: RE: [nfsv4] symlinks: opaque or UTF-8 --- "Noveck, Dave" wrote: > I think Mike should have been explicit about his "" > and "" tags. I'm not being sarcastic. The protocol has an i18n requirement. No one has shown how we can meet the i18n requirement and cope with servers that have no clue what character set their metadata is in. Given that there are servers that can meet the requirement, why should we water down the protocol, and make interoperability even harder?=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 Wed Nov 28 22:54: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 1IxaUC-00068n-8q; Wed, 28 Nov 2007 22:54:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxaUB-00068T-Op for nfsv4@ietf.org; Wed, 28 Nov 2007 22:54:47 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxaUA-0004aU-UI for nfsv4@ietf.org; Wed, 28 Nov 2007 22:54:47 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAT3sjvb017964 for ; Thu, 29 Nov 2007 03:54:45 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JS9000011IID400@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Wed, 28 Nov 2007 20:54:45 -0700 (MST) Received: from [10.1.232.183] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JS900DNV1J9EW40@mail-amer.sun.com>; Wed, 28 Nov 2007 20:54:45 -0700 (MST) Date: Wed, 28 Nov 2007 21:54:46 -0600 From: Spencer Shepler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 In-reply-to: To: "Noveck, Dave" Message-id: <5640D418-1C89-48A1-935E-03CEE1BE0AC8@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.2 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Nov 28, 2007, at 9:38 PM, Noveck, Dave wrote: >> I'm not being sarcastic. > > Then I'm totally confused. > >> why should we water down the protocol, and make interoperability even > harder? > > Can you stop arguing for your position for a second and focus on > making > it clear what it is? > > So far, the only thing I had been sure of in this debate is that > you and > Bruce disagree on what should be done so when you argue for your > position (with or without sarcasm) and Bruce's response is "OK with > me", > I'm at a total loss. > > Bruce is has been basically saying that we should treat this as opaque > and that doesn't sound to me like what you are saying, unless I am > totally confused, which is possible. > > So help me: > > Bruce, what is it that you are OK with? > > Spencer, what is it that you are OK with? Symlink text (linktext4) remains utf8str_cs just as with other filesystem object names, component4, are required to be. If the server or client have issues with UTF8 then they translate to or from as appropriate for their environments but what flows over NFSv4.1 is UTF8. Or in other words, I am agreeing to the text that Mike proposed earlier in this thread. Spencer > Mike, what is it that Spencer and Bruce are OK with? :-) > > > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > Sent: Wednesday, November 28, 2007 10:19 PM > To: nfsv4@ietf.org > Subject: RE: [nfsv4] symlinks: opaque or UTF-8 > > > --- "Noveck, Dave" wrote: > > >> I think Mike should have been explicit about his "" >> and "" tags. > > I'm not being sarcastic. > > The protocol has an i18n requirement. No one has shown how we can meet > the i18n requirement and cope with servers that have no clue what > character set their metadata is in. Given that there are servers that > can meet the requirement, why should we water down the protocol, and > make interoperability even harder? > > > _______________________________________________ > 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 tello@alphaquad.com Wed Nov 28 23:17:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxaqU-0003jZ-1T; Wed, 28 Nov 2007 23:17:50 -0500 Received: from [189.135.55.103] (helo=gig-d6c844b9a08) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxaqS-00032w-66; Wed, 28 Nov 2007 23:17:50 -0500 Received: from [189.135.55.103] by mx73a.emailfiltering.com; Wed, 28 Nov 2007 22:17:42 -0600 From: "Major Vera" To: Subject: Magnet Album Man Printer Woman Computer Mist Date: Wed, 28 Nov 2007 22:17:42 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: Aca6QIGJJ365GC0BC41X90U3TWSR8M== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Message-ID: <01c8320c$7e73be10$673787bd@tello> X-Spam-Score: 2.1 (++) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Holiday gifts are on sale http://ladonnahutchensxn.googlepages.com From nfsv4-bounces@ietf.org Wed Nov 28 23:30: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 1Ixb2g-0001zt-I2; Wed, 28 Nov 2007 23:30:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixb2g-0001zc-0I for nfsv4@ietf.org; Wed, 28 Nov 2007 23:30:26 -0500 Received: from web38109.mail.mud.yahoo.com ([209.191.124.136]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ixb2f-0004lE-Il for nfsv4@ietf.org; Wed, 28 Nov 2007 23:30:25 -0500 Received: (qmail 96272 invoked by uid 60001); 29 Nov 2007 04:30:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=6pF17qtxHpG+L4nOq+xWGa/RnV3iXq7NqzOfdcvssSYg7zYoY18ug5IoHWVEM+RrDTRmNrun628g/DzJePHj89bltaJwvA9baxciKU2EpF9Gu+J4Wrt6jCyRUWXLHuv7m0mtglSJJWFoObRprdO50syhvQGQalZDx9htX4IjAuA=; X-YMail-OSG: Sjov_akVM1lkJTR2Xv65GY9oihcfj5M.x7ZsRDNHR7XpCR9JYyRJGDQQyKqtTbMVwtV3Vw-- Received: from [198.95.226.230] by web38109.mail.mud.yahoo.com via HTTP; Wed, 28 Nov 2007 20:30:24 PST Date: Wed, 28 Nov 2007 20:30:24 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] symlinks: opaque or UTF-8 To: "Noveck, Dave" , email2mre-ietf@yahoo.com, nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <608553.94539.qm@web38109.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > Bruce, what is it that you are OK with? > > Spencer, what is it that you are OK with? > > Mike, what is it that Spencer and Bruce are OK with? :-) I believe Spencer and Bruce are OK with the NFSv4.1 spec mandating that the server return components and pathnames always in UTF-8 encoding, whether from READLINK, READDIR, or anything other operation that returns UTF-8 data types. Bruce is saying he cannot actually implement a Linux server to do this all the time. I believe Bruce and Spencer are OK with the fact Bruce's server won't comply with the specification. Any possible interest I had in changing the spec to accommodate Bruce evaporated when he said that his READDIR implementation returned non-UTF-8 component names. So for that reason, I am OK with Bruce's server not returning UTF-8. As an aside, UCS-4 has codes for characters numbering from 0x80 through 0xFF does it not? Why can't Bruce's "just-use-8" server convert bytes with values 0x80 through 0xFF into their corresponding UTF-8 two character sequences in the results, and similarly accept the UTF-8 two character sequences that correspond to 0x80 through 0xFF in requests? I.e., UCS characters 00000080 through 000007FF are converted to: 110xxxxx 10xxxxxx. 0x80 would then be 11000010 10000000 or C2 80. 0xFF would be 11000011 10111111 or C3 BF Bruce's server would then reject any UTF-8 encoding in a request not "between" C2 80 and C3 BF with NFS4ERR_BADCHAR. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 00:03: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 1IxbYv-0003Os-Lp; Thu, 29 Nov 2007 00:03:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxbYu-0003Oe-BV for nfsv4@ietf.org; Thu, 29 Nov 2007 00:03:44 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxbYs-0007wk-FY for nfsv4@ietf.org; Thu, 29 Nov 2007 00:03:44 -0500 Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IxbYq-00050l-AG; Thu, 29 Nov 2007 06:03:40 +0100 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 1IxbYp-0007ql-Tx; Thu, 29 Nov 2007 06:03:40 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IxbYp-0007qa-FY; Thu, 29 Nov 2007 06:03:39 +0100 Subject: RE: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: email2mre-ietf@yahoo.com In-Reply-To: <608553.94539.qm@web38109.mail.mud.yahoo.com> References: <608553.94539.qm@web38109.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 29 Nov 2007 00:03:37 -0500 Message-Id: <1196312617.7950.24.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.2, required=12.0, autolearn=disabled, AWL=-0.231) X-UiO-Scanned: 451A91E612D74E9B498043F27868E0500F8E3DCB X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -1 maxlevel 200 minaction 2 bait 0 mail/h: 15 total 5447059 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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, 2007-11-28 at 20:30 -0800, Mike Eisler wrote: > --- "Noveck, Dave" wrote: > > > > Bruce, what is it that you are OK with? > > > > Spencer, what is it that you are OK with? > > > > Mike, what is it that Spencer and Bruce are OK with? :-) > > I believe Spencer and Bruce are OK with the NFSv4.1 spec mandating > that the server return components and pathnames always in UTF-8 > encoding, whether from READLINK, READDIR, or anything other operation > that returns UTF-8 data types. > > Bruce is saying he cannot actually implement a Linux server to do this > all the time. I believe Bruce and Spencer are OK with the fact Bruce's > server won't comply with the specification. > > Any possible interest I had in changing the spec to > accommodate Bruce evaporated when he > said that his READDIR implementation returned non-UTF-8 component > names. So for that reason, I am OK with Bruce's server not returning > UTF-8. > > As an aside, UCS-4 has codes for characters numbering from 0x80 > through 0xFF does it not? Why can't Bruce's "just-use-8" > server convert bytes with values 0x80 through 0xFF into their > corresponding UTF-8 two character sequences in the results, > and similarly accept the UTF-8 two character > sequences that correspond to 0x80 through 0xFF in requests? > > I.e., UCS characters 00000080 through 000007FF > are converted to: 110xxxxx 10xxxxxx. 0x80 would then be > 11000010 10000000 or C2 80. > 0xFF would be > 11000011 10111111 or C3 BF > > Bruce's server would then reject any UTF-8 encoding in a request > not "between" C2 80 and C3 BF with NFS4ERR_BADCHAR. The standard unix definition of a symlink does not allow for any form of server proofreading of the string contents. It is entirely up to the user/application on the client to define something that it thinks will work. See http://www.opengroup.org/onlinepubs/009695399/functions/readlink.html and http://www.opengroup.org/onlinepubs/009695399/functions/symlink.html In fact, the symlink() operation explicitly states that "The string pointed to by path1 shall be treated only as a character string and shall not be validated as a pathname.". Note that it does not state that you are allowed to validate it in terms of a particular character set, or that you are required to stringprep it either. Any attempt to require that NFSv4 must stringprep is therefore likely to confuse applications which will see that the string is either being refused by the server with an error code that is not sanctioned by the POSIX/Single Unix Spec for symlink(), or is not being returned correctly verbatim by readlink(). Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 01:12:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxcdV-0005vK-8i; Thu, 29 Nov 2007 01:12:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxcdT-0005no-SF for nfsv4@ietf.org; Thu, 29 Nov 2007 01:12:31 -0500 Received: from web38108.mail.mud.yahoo.com ([209.191.124.135]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxcdS-0005NV-7g for nfsv4@ietf.org; Thu, 29 Nov 2007 01:12:31 -0500 Received: (qmail 24464 invoked by uid 60001); 29 Nov 2007 06:12:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=mM9C2GQSJ0OdI4+KdAO9FJjSJlMrKglgIVH3US4juOqbDNESmi7esVEUByu8S1HumWO4WQtTTBGpcxUUP5AACkG6K7QaLeXtwQXodElDgoVnyNtKRg49HKONBpMB3z6SEkc8qRGQmMgjmG0oRe6BK2xb8/uOwirxq//zB6zEkno=; X-YMail-OSG: GiMM9T8VM1ldHM4hiJvAP30M6dw8hn5ZZqDHw31BgR1IClhAsaxMJBN27pzP7HQPdbPzmXeUH7kqKhISssW3hosk3SSam2sbbk.eS05yTLEzdEZMQJE- Received: from [198.95.226.230] by web38108.mail.mud.yahoo.com via HTTP; Wed, 28 Nov 2007 22:12:29 PST Date: Wed, 28 Nov 2007 22:12:29 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <1196312617.7950.24.camel@heimdal.trondhjem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <604776.23383.qm@web38108.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Trond Myklebust wrote: > The standard unix definition of a symlink does not allow for any form > of > server proofreading of the string contents. It is entirely up to the > user/application on the client to define something that it thinks > will > work. See > > http://www.opengroup.org/onlinepubs/009695399/functions/readlink.html > > and > > http://www.opengroup.org/onlinepubs/009695399/functions/symlink.html > > In fact, the symlink() operation explicitly states that "The string > pointed to by path1 shall be treated only as a character string and > shall not be validated as a pathname.". Note that it does not state Who wrote on this thread that NFSv4.1's CREATE operation should validate the symlink as a path. It doesn't say anything about whether the character set can be validated or not, and even if it did, that would be irrelevant, because we are specifying a networking protocol, and are free to specify the encoding anyway we want. For example, ever since NFSv2, all pathnames and components can legally include nul ASCII characters, even though this violates POSIX. NFS != POSIX. So everything you claim about readlink and symlink would apply to open, link, stat, etc., and therefore UTF-8 would not be appropriate for OPEN, LINK, LOOKUP, etc. > that > you are allowed to validate it in terms of a particular character > set, > or that you are required to stringprep it either. I don't care about stringprep one way or the other. IESG forced in on us, but if it gets in the way, don't use it. Normalization strikes me as complex or stupid or both. If you want start a separate thread on stringprep, go ahead, we'll see how much enthusiasm there is this time to address it. But this thread is about UTF-8. > Any attempt to require that NFSv4 must stringprep is therefore likely > to > confuse applications which will see that the string is either being > refused by the server with an error code that is not sanctioned by > the > POSIX/Single Unix Spec for symlink(), or is not being returned > correctly > verbatim by readlink(). > > 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 Thu Nov 29 02:16: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 1IxddG-0006lK-50; Thu, 29 Nov 2007 02:16:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxddE-0006l0-BR for nfsv4@ietf.org; Thu, 29 Nov 2007 02:16:20 -0500 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxddD-0007xF-Av for nfsv4@ietf.org; Thu, 29 Nov 2007 02:16:19 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAT7G9gm009650 for ; Thu, 29 Nov 2007 07:16:18 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAT7G9lH029155 for ; Thu, 29 Nov 2007 00:16:09 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAT7G90C002712; Thu, 29 Nov 2007 01:16:09 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAT7G8wx002711; Thu, 29 Nov 2007 01:16:08 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Nov 2007 01:16:08 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129071608.GI2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <20071128222954.GK1524@Sun.COM> <771812.91113.qm@web38102.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <771812.91113.qm@web38102.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) 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 On Wed, Nov 28, 2007 at 04:17:42PM -0800, Mike Eisler wrote: > --- Nicolas Williams wrote: > > That said, symlinks can and do contain non-pathname contents in many > > cases. Restricting symlinks to UTF-8 may not be the best thing to > > do. > > So when an app like the ls command reads a symlink and displays > its contents, what does it display when it finds non-utf-8 in it? The actual contents. It's up to the terminal to do something interesting with unexpected octets. > > But when a client follows a symlink it will have to know what to do > > with any non-UTF-8 sequences therein -- the only reasonable thing to > > do, at first blush, in such cases is to return an error to the > > application. > > What does one do at second blush? By "at first blush" I meant that I hadn't taken unassigned codepoints into consideration (but I wrote about those right below). > > > My proposal: > > > > - let symlinks be opaque<> > > why stop there? Because symlink content need not be filesystem object names or paths. Filesystem object names should always be in UTF-8. We need to allow for legacy filesystem contents -- it's a reality, so really we need to restrict at least CREATEs to UTF-8 only. > > http://blogs.sun.com/nico/entry/filesystem_i18n > > > > Short version: > > > > - Your best bet on the server is to treat all UTF-8-looking octet > > sequences as per NFSv4/NFSv4.1, have a knob to reject/allow > > non-UTF-8, and implement normalization-insenstive LOOKUPs. > > > > - On the client side you should refrain from using non-UTF-8 > > locales. > > Alternatively you should implement codeset conversions in your > > libc/glibc system call stubs when in non-UTF-8/ASCII/C locales. > > > > - Provide tools for finding and converting legacy filesystem > > contents. > > The problem is that NFSv3 implemented to be 8 bit clean. And many NFSv4 implementations are also just-use-8. > Many, if not most, non-ASCII deployments of NFSv3 don't use UTF-8. Indeed. > Lots of data today is stored on NAS devices that allow access via file > access protocols like CIFS that do mandate things like Unicode, no > weaseling out permitted. Yup. > What to do? There's a number of things that can be done. > - declare the character set for the fsid I don't think this works well. You might not know what that codeset should be, or there may be many in use. > - convert from the character set to Unicode if using CIFS This doesn't work well for the same reasons as above. But if you do know that a single codeset is in use for a given fs then doing the codeset conversions in the filesystem itself is the best bet. > - convert from the character set to UTF-8 if using NFSv4 Same as above. > - for NFSv3, if the declared character set uses 8 bit characters > do not convert. If the declared character set uses 16 bit or > higher characters, convert to UTF-8 and hope for best. Sure. Some additional options: - just-send-8 for existing non-UTF-8 fs object names and hope for the best - force the user to convert legacy fs object names - perform potentially lossy conversions (e.g., convert all non-ASCII, non-UTF-8 octet sequences to question marks, or encode them as backslashed octal) and hope for the best (i.e., when the user notices they might then go convert the names' codesets) But this is about legacy fs object names, and that's off-topic for this thread, which was about symlink contents. As far as symlink contents is concerned, using opaque is fine, and probably even the best thing to do, with the caveats I mentioned earlier. OTOH, I won't cry if symlink content is required to be UTF-8. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 02:27: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 1Ixdnr-0008PA-QT; Thu, 29 Nov 2007 02:27:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixdnq-0008Oq-L4 for nfsv4@ietf.org; Thu, 29 Nov 2007 02:27:18 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixdno-0002Z9-W9 for nfsv4@ietf.org; Thu, 29 Nov 2007 02:27:18 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAT7RGIY027250 for ; Thu, 29 Nov 2007 07:27:16 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAT7RFes033510 for ; Thu, 29 Nov 2007 00:27:15 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAT7RF4D002723; Thu, 29 Nov 2007 01:27:15 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAT7RFJS002722; Thu, 29 Nov 2007 01:27:15 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Nov 2007 01:27:15 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129072715.GJ2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <20071129001531.GD2540@Sun.COM> <230454.46502.qm@web38106.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <230454.46502.qm@web38106.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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, Nov 28, 2007 at 04:29:43PM -0800, Mike Eisler wrote: > --- Nicolas Williams wrote: > > > > We give it to the filesystem and let it decide. If you want a > > > > fully NFSv4-compliant(TM) server then you should be exporting a > > > > filesystem that enforces the utf-8 requirement. > > > > > > So your server's READDIR will return directory entries that > > > aren't legal UTF-8? > > > > Clients need to be ready to deal with such servers, because legacy > > filesystem contents exists. Servers might well reject CREATEs of > > non-UTF-8 names while still allowing LOOKUPs of and READDIRs that > > include existing non-UTF-8 names. > > So if servers can return non-UTF-8 in readdir and readlink, > then what's the point? Readlink is distinct from READDIR because READIR deals in fs object names, but readlink deals in symlink contents which need not have anything to do with fs object naming. > Either a server can cope with UTF-8 or not. Servers should definitely reject non-UTF-8 in CREATEs. > If it cannot, and is going to ignore the spec, then what difference > does it make if we mandate UTF-8? Bruce will deal with his unsolvable > problem by returning non-UTF-8 every where, and allowing non0UTF-8 > every where. If that's what his server does and if clients are OK with > that, why should we care? Dealing with UTF-8 has been as much a simple matter of specs as of programming. I don't support "allowing non-UTF-8" everywhere; I didn't say or imply that I did. > It's not like anyone cared until Dave kicked the hornets' nest. > > UTF-8 is a tool, use it or not, but I don't see why we should > weaken the spec because some cannot or will not use it. Requiring UTF-8 on create, supporting normalization-insensitive LOOKUPs (or normalization on CREATE), those are all simple matters of programming (hard, but not all that hard). Converting legacy filesystem, OTOH, content is not a simple matter of programming -- it requires user input, possibly *lots* of user input. I think the spec should deal with legacy content. One way would to allow the server to indicate that some fsid contains non-UTF-8 names. I described other alternatives just before this post. > > > I don't follow how it is different. You seem to be saying that > > > regardless what the specification says, your server treats > > > component names as 8 bit opaque characters. > > > > It is different because symlinks have been defined from the get-go > > as being allowed to contain non-pathname data. Therefore > > constraining them to contain UTF-8 seems a bit harsh (though > > probably livable). > > Sorry, I don't see the difference. User names in NFSv4 don't have path > names data and they are mandated to have UTF-8 (not that I have any > faith that all NFSv4 user names are encoded in UTF-8). Symlink content need be neither usernames nor pathnames. They can be anything, except that they can't contain '\0'. Historically anyways. Yes, we could limit them to UTF-8. Not limiting them to UTF-8 != throwing I18N out the window (which you seem to be arguing). > > > How do you expect clients to display the right glyphs for a > > > character if the server renders illegal utf-8? > > > > "renders"? > > > > The answer is: the way clients generally tend to do in many other > > cases, namely, by replacing them with question marks or some other > > appropriate glyph. > > Well that's useful. :-( Legacy content is painful to deal with, but it is useful to the user (otherwise we'd not have legacy content to deal with). Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 02:35: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 1Ixdw9-0002At-Hs; Thu, 29 Nov 2007 02:35:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixdw8-0002Ae-Af for nfsv4@ietf.org; Thu, 29 Nov 2007 02:35:52 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixdw6-0003HW-Ks for nfsv4@ietf.org; Thu, 29 Nov 2007 02:35:52 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAT7ZorH015120 for ; Thu, 29 Nov 2007 07:35:50 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAT7ZnA4037480 for ; Thu, 29 Nov 2007 00:35:49 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAT7Znhj002733; Thu, 29 Nov 2007 01:35:49 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAT7Zncv002732; Thu, 29 Nov 2007 01:35:49 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Nov 2007 01:35:49 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129073549.GK2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <1196312617.7950.24.camel@heimdal.trondhjem.org> <604776.23383.qm@web38108.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <604776.23383.qm@web38108.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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, Nov 28, 2007 at 10:12:29PM -0800, Mike Eisler wrote: > --- Trond Myklebust wrote: > > The standard unix definition of a symlink does not allow for any form > > of > > server proofreading of the string contents. It is entirely up to the > > user/application on the client to define something that it thinks > > will > > work. See > > > > http://www.opengroup.org/onlinepubs/009695399/functions/readlink.html > > > > and > > > > http://www.opengroup.org/onlinepubs/009695399/functions/symlink.html > > > > In fact, the symlink() operation explicitly states that "The string > > pointed to by path1 shall be treated only as a character string and > > shall not be validated as a pathname.". Note that it does not state > > Who wrote on this thread that NFSv4.1's CREATE operation should > validate the symlink as a path. Noone. > It doesn't say anything about whether the character set can be > validated or not, and even if it did, that would be irrelevant, > because we are specifying a networking protocol, and are free to > specify the encoding anyway we want. NFSv4/4.1 impose a stringprep requirement on symlink contents that is not compatible with the definition of symlinks. IN PRACTICE I suspect noone will care -- non-pathname content uses of symlinks that I know about are all about application locks and aren't likely to run into codeset issues. > For example, ever since NFSv2, all pathnames and components can > legally include nul ASCII characters, even though this violates > POSIX. NFS != POSIX. True. But there's no need to gratouitously diverge either. > So everything you claim about readlink and symlink would apply to > open, link, stat, etc., and therefore UTF-8 would not be appropriate > for OPEN, LINK, LOOKUP, etc. The definition of symlink content sets symlinks apart from the others. > > that > > you are allowed to validate it in terms of a particular character > > set, > > or that you are required to stringprep it either. > > I don't care about stringprep one way or the other. > IESG forced in on us, but if it gets in the way, don't use it. I would force it on you also. That doesn't mean that it's appropriate for every string slot in a protocol. > Normalization strikes me as complex or stupid or both. It's complex, but not stupid. It may arise from what you might think of as stupid decisions in the past, but the past is what it is. > If you want start a separate thread on stringprep, go ahead, > we'll see how much enthusiasm there is this time to address it. Stringprep should stay in, with unspecified normalization as in NFSv4.0. > But this thread is about UTF-8. I thought it was about symlink contents. > > Any attempt to require that NFSv4 must stringprep is therefore > > likely to confuse applications which will see that the string is ^^^^^^ Well, I don't think it's likely. Possible, yes. That's why I wouldn't mind if symlink content were required to be UTF-8, but I think the natural thing to do is exempt it. > > either being refused by the server with an error code that is not > > sanctioned by the POSIX/Single Unix Spec for symlink(), or is not > > being returned correctly verbatim by readlink(). Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 06:36: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 1Ixhh7-0003qm-0B; Thu, 29 Nov 2007 06:36:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixhh5-0003q9-E2 for nfsv4@ietf.org; Thu, 29 Nov 2007 06:36:35 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixhh3-0000Mr-SU for nfsv4@ietf.org; Thu, 29 Nov 2007 06:36:35 -0500 X-IronPort-AV: E=Sophos;i="4.23,228,1194249600"; d="scan'208";a="127199877" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 29 Nov 2007 03:36:18 -0800 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 lATBaI3Z011837; Thu, 29 Nov 2007 03:36:18 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 03:36:17 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 03:36:17 -0800 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] symlinks: opaque or UTF-8 Date: Thu, 29 Nov 2007 06:36:24 -0500 Message-ID: In-Reply-To: <608553.94539.qm@web38109.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgyQKxjCuPKOfN1R5WpeanM5tl1xQAOfkww From: "Noveck, Dave" To: , X-OriginalArrivalTime: 29 Nov 2007 11:36:17.0705 (UTC) FILETIME=[0E48E190:01C8327C] X-Spam-Score: -3.8 (---) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Since I don't have to interoperate with Bruce's server, he can violate the spec all he wants and I won't mind. The problem is if clients need to adapt to Bruce's server, and as a result have problems interoperating with a server that does obey the protocol. We can't stop people from not obeying the ptotocol, but I want to make sure we are not somehow agreeing to write down that the link has to be UTF-8, with the tacit understanding that Bruce (and others?) will treat it as opaque. If Bruce violates the protocol as far as READDIR then that's an OK analogy fro READLINK, but does he violate it on LOOKUP? If so, and clients are adapting to that we have a problem. Simlarly, are we supposing he will violate it on CREATE? It this is just a legacy thing, then fine.=20 -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Wednesday, November 28, 2007 11:30 PM To: Noveck, Dave; email2mre-ietf@yahoo.com; nfsv4@ietf.org Subject: RE: [nfsv4] symlinks: opaque or UTF-8 --- "Noveck, Dave" wrote: > Bruce, what is it that you are OK with? >=20 > Spencer, what is it that you are OK with? >=20 > Mike, what is it that Spencer and Bruce are OK with? :-) I believe Spencer and Bruce are OK with the NFSv4.1 spec mandating that the server return components and pathnames always in UTF-8 encoding, whether from READLINK, READDIR, or anything other operation that returns UTF-8 data types.=20 Bruce is saying he cannot actually implement a Linux server to do this all the time. I believe Bruce and Spencer are OK with the fact Bruce's server won't comply with the specification.=20 Any possible interest I had in changing the spec to accommodate Bruce evaporated when he said that his READDIR implementation returned non-UTF-8 component names. So for that reason, I am OK with Bruce's server not returning UTF-8.=20 As an aside, UCS-4 has codes for characters numbering from 0x80 through 0xFF does it not? Why can't Bruce's "just-use-8"=20 server convert bytes with values 0x80 through 0xFF into their corresponding UTF-8 two character sequences in the results, and similarly accept the UTF-8 two character sequences that correspond to 0x80 through 0xFF in requests? I.e., UCS characters 00000080 through 000007FF are converted to: 110xxxxx 10xxxxxx. 0x80 would then be 11000010 10000000 or C2 80. 0xFF would be 11000011 10111111 or C3 BF Bruce's server would then reject any UTF-8 encoding in a request not "between" C2 80 and C3 BF with NFS4ERR_BADCHAR.=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From Pickle@loov.ee Thu Nov 29 10:55:01 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxljB-0002Mf-Ug for nfsv4-archive@lists.ietf.org; Thu, 29 Nov 2007 10:55:01 -0500 Received: from [41.248.1.173] (helo=[41.248.1.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxljB-0003wq-6L for nfsv4-archive@lists.ietf.org; Thu, 29 Nov 2007 10:55:01 -0500 Received: from mohamed-d11b9e2 ([193.123.165.55] helo=mohamed-d11b9e2) by [41.248.1.173] ( sendmail 8.13.3/8.13.1) with esmtpa id 1zjDnU-000ODL-Ve for nfsv4-archive@lists.ietf.org; Wed, 28 Nov 2007 15:59:17 +0100 Message-ID: <000801c831cf$2fbebdc0$ad01f829@mohamedd11b9e2> From: "Pickle crossett" To: Subject: blatjang Date: Wed, 28 Nov 2007 15:58:50 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C831D7.918325C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 2.1 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a ------=_NextPart_000_0005_01C831D7.918325C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable more and more guys make it bigger, dont be shy and just do it = http://ldahomes.com/ ------=_NextPart_000_0005_01C831D7.918325C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
more and more guys make it bigger, = dont be=20 shy and just do it http://ldahomes.com/
------=_NextPart_000_0005_01C831D7.918325C0-- From nfsv4-bounces@ietf.org Thu Nov 29 14:58: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 1IxpX2-00026X-10; Thu, 29 Nov 2007 14:58:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxpX0-00026R-LG for nfsv4@ietf.org; Thu, 29 Nov 2007 14:58:42 -0500 Received: from web38107.mail.mud.yahoo.com ([209.191.124.134]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxpX0-0004vo-8V for nfsv4@ietf.org; Thu, 29 Nov 2007 14:58:42 -0500 Received: (qmail 40634 invoked by uid 60001); 29 Nov 2007 19:58:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=1/0ME9jLrpV8d4JdltJodlO4c6m4z/oTaP8fdnijRCEDqAQZvRuiEc/xS/z3D6U+yi8LlcObULq0ChXVmsEZUlXdkdGjXYF9L13uQ+zbA1caV25q+rUE2fw/4Cd89wesb5YhwGrXGPqPn0GANTia7FBhV+RPeSG9F83Q8l9xovA=; X-YMail-OSG: d0TsfFgVM1nljKznamBk2Rgx0NCkL0BJtjoIUNyBYtdrow4rfk5jXXJ9xyzYNWOgQJGr8SzUKw-- Received: from [198.95.226.230] by web38107.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 11:58:41 PST Date: Thu, 29 Nov 2007 11:58:41 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071129071608.GI2540@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <732993.40146.qm@web38107.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Nicolas Williams wrote: > > > My proposal: > > > > > > - let symlinks be opaque<> > > > > why stop there? > > Because symlink content need not be filesystem object names or paths. The majority of the time they are. We should design for the situation where an app is using symlink for something better served by a named attribute? Suppose the locale on the client is set to something other than US-ASCII or UTF-8. A process on the client creates a symlink containing path component separators, and 8 bit characters with the higher bit set. Another process using the same locale issues an open() system call on a pathname to symlink, and per the NFSv4.1 spec, the path *to* the symlink is UTF-8 (so the char set of locale is converted to UTF-8). How does the NFS filesystem on the client cope with a logical pathname composed of a combination of UTF-8 and "just-use-8"? How does the NFS filesystem on the client even know char set the second half of the logical pathname is? > Filesystem object names should always be in UTF-8. We need to allow > for > legacy filesystem contents -- it's a reality, so really we need to > restrict at least CREATEs to UTF-8 only. Legacy content in the range 0x80 to 0xFF can be converted to to UTF-8. > > - declare the character set for the fsid > > I don't think this works well. You might not know what that codeset > should be, or there may be many in use. I'm not sure if most of my customers would agree with you. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 15:09: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 1Ixphf-0000X8-Mw; Thu, 29 Nov 2007 15:09:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixphf-0000X3-1S for nfsv4@ietf.org; Thu, 29 Nov 2007 15:09:43 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixphd-0006xq-FN for nfsv4@ietf.org; Thu, 29 Nov 2007 15:09:43 -0500 Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Ixphc-00086y-Oy; Thu, 29 Nov 2007 21:09:40 +0100 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 1Ixphc-0004Q3-Ba; Thu, 29 Nov 2007 21:09:40 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ixphb-0004Pp-Vj; Thu, 29 Nov 2007 21:09:40 +0100 Subject: Re: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: email2mre-ietf@yahoo.com In-Reply-To: <732993.40146.qm@web38107.mail.mud.yahoo.com> References: <732993.40146.qm@web38107.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 29 Nov 2007 15:09:38 -0500 Message-Id: <1196366978.19682.11.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.4, required=12.0, autolearn=disabled, AWL=-0.355) X-UiO-Scanned: 5FBC051B8E4098858C4CB59C7EDBE7189E10D585 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -3 maxlevel 200 minaction 2 bait 0 mail/h: 154 total 5467881 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) 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 Thu, 2007-11-29 at 11:58 -0800, Mike Eisler wrote: > Suppose the locale on the client is set to something other > than US-ASCII or UTF-8. A process on the client creates a symlink > containing path component separators, and 8 bit characters with the > higher bit set. Another process using the same locale issues an > open() system call on a pathname to symlink, and per > the NFSv4.1 spec, the path *to* the symlink is UTF-8 (so > the char set of locale is converted to UTF-8). How does the NFS > filesystem on the client cope with a logical pathname composed of a > combination of UTF-8 and "just-use-8"? How does the NFS filesystem on > the client even know char set the second half of the logical pathname > is? So how, in this scenario, does the NFS filesystem get to figure out what locale the application is using? > > Filesystem object names should always be in UTF-8. We need to allow > > for > > legacy filesystem contents -- it's a reality, so really we need to > > restrict at least CREATEs to UTF-8 only. > > Legacy content in the range 0x80 to 0xFF can be converted to > to UTF-8. That also assumes that the kernel knows what charset the app was using. Otherwise you are converting blindly 'just-use-8' to UTF-8. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 15:12: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 1IxpkJ-0005aO-HD; Thu, 29 Nov 2007 15:12:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxpkH-0005Ut-PP for nfsv4@ietf.org; Thu, 29 Nov 2007 15:12:25 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxpkH-0005fg-AK for nfsv4@ietf.org; Thu, 29 Nov 2007 15:12:25 -0500 X-IronPort-AV: E=Sophos;i="4.23,230,1194249600"; d="scan'208";a="127357398" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 29 Nov 2007 12:10:23 -0800 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 lATKAMXI011819; Thu, 29 Nov 2007 12:10:23 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 12:10:22 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 12:10:22 -0800 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] symlinks: opaque or UTF-8 Date: Thu, 29 Nov 2007 15:10:21 -0500 Message-ID: In-Reply-To: <732993.40146.qm@web38107.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: Acgywos6iy8I4K3cT3275vUVRrNSsAAAGhMg From: "Noveck, Dave" To: , X-OriginalArrivalTime: 29 Nov 2007 20:10:22.0453 (UTC) FILETIME=[DF2FEA50:01C832C3] X-Spam-Score: 0.2 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 > The majority of the time they are. We should design for the=20 > situation where an app is using symlink for something better served > by a named attribute? This may be a rare exception, but normally yes. We should design to support existing applications and API's, and not consider ourselves absolved of that responsibility because we think they should have used some other facility (and note that servers need not support named attributes and client need not provide an API to access them on any partiuclar OS). -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Thursday, November 29, 2007 2:59 PM To: nfsv4@ietf.org Subject: Re: [nfsv4] symlinks: opaque or UTF-8 --- Nicolas Williams wrote: > > > My proposal: > > >=20 > > > - let symlinks be opaque<> > >=20 > > why stop there? >=20 > Because symlink content need not be filesystem object names or paths. The majority of the time they are. We should design for the=20 situation where an app is using symlink for something better served by a named attribute? Suppose the locale on the client is set to something other than US-ASCII or UTF-8. A process on the client creates a symlink containing path component separators, and 8 bit characters with the higher bit set. Another process using the same locale issues an open() system call on a pathname to symlink, and per the NFSv4.1 spec, the path *to* the symlink is UTF-8 (so the char set of locale is converted to UTF-8). How does the NFS filesystem on the client cope with a logical pathname composed of a combination of UTF-8 and "just-use-8"? How does the NFS filesystem on the client even know char set the second half of the logical pathname is? > Filesystem object names should always be in UTF-8. We need to allow > for > legacy filesystem contents -- it's a reality, so really we need to > restrict at least CREATEs to UTF-8 only. Legacy content in the range 0x80 to 0xFF can be converted to to UTF-8. > > - declare the character set for the fsid >=20 > I don't think this works well. You might not know what that codeset > should be, or there may be many in use. I'm not sure if most of my customers would agree with you. _______________________________________________ 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 Nov 29 15:12: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 1Ixpkl-0006De-9T; Thu, 29 Nov 2007 15:12:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixpkj-00068b-9I for nfsv4@ietf.org; Thu, 29 Nov 2007 15:12:53 -0500 Received: from web38102.mail.mud.yahoo.com ([209.191.124.129]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ixpki-000782-Oo for nfsv4@ietf.org; Thu, 29 Nov 2007 15:12:53 -0500 Received: (qmail 46685 invoked by uid 60001); 29 Nov 2007 20:12:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=WkJ/6Uf9Px4+LHBMM14Z5umKrvwnjdqrmvfwFaMBPQDK5sg9wQOcPPWVec6UXlMFHLcs6M0WphtyyM2lIUsq9KQLNEwoghMnI7jss6yydRtQVAV9Jc08tEdsVfcweM9FKgZ+4UwHta0VYOkN7LpyuXcOKcdRObqXbSmSyVJ2MQU=; X-YMail-OSG: mpN2104VM1nzlJ1qTTv7HGoKdzfXLiamcnuyimI6DXI1SZMJ_BanN6m8pfvAVHnP_wOtLGBjYQ-- Received: from [198.95.226.230] by web38102.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 12:12:52 PST Date: Thu, 29 Nov 2007 12:12:52 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <276084.44429.qm@web38102.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > Since I don't have to interoperate with Bruce's server, he can > violate > the spec all he wants and I won't mind. > > The problem is if clients need to adapt to Bruce's server, and as a > result have problems interoperating with a server that does obey the > protocol. I see. So my idea of Bruce converting bytes 0x80 through 0xFF won't work in general. So ... If Bruce accepts UTF-8 on LOOKUP, OPEN, CREATE (including symlink contents), and returns the UTF-8 the client "wrote" to a directory or symlink via OPEN and CREATE, then the client can operate the same way to his server and a compliant server. > We can't stop people from not obeying the ptotocol, but I want to > make > sure we are not somehow agreeing to write down that the link has to > be > UTF-8, with the tacit understanding that Bruce (and others?) will > treat > it as opaque. If Bruce treats it as opaque, then Bruce will accept UTF-8. > > If Bruce violates the protocol as far as READDIR then that's an OK > analogy fro READLINK, but does he violate it on LOOKUP? If so, and > clients are adapting to that we have a problem. Simlarly, are we > supposing he will violate it on CREATE? It this is just a legacy > thing, > then fine. > > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > Sent: Wednesday, November 28, 2007 11:30 PM > To: Noveck, Dave; email2mre-ietf@yahoo.com; nfsv4@ietf.org > Subject: RE: [nfsv4] symlinks: opaque or UTF-8 > > > --- "Noveck, Dave" wrote: > > > > Bruce, what is it that you are OK with? > > > > Spencer, what is it that you are OK with? > > > > Mike, what is it that Spencer and Bruce are OK with? :-) > > I believe Spencer and Bruce are OK with the NFSv4.1 spec mandating > that > the server return components and pathnames always in UTF-8 encoding, > whether from READLINK, READDIR, or anything other operation that > returns > UTF-8 data types. > > Bruce is saying he cannot actually implement a Linux server to do > this > all the time. I believe Bruce and Spencer are OK with the fact > Bruce's > server won't comply with the specification. > > Any possible interest I had in changing the spec to accommodate Bruce > evaporated when he said that his READDIR implementation returned > non-UTF-8 component names. So for that reason, I am OK with Bruce's > server not returning UTF-8. > > As an aside, UCS-4 has codes for characters numbering from 0x80 > through > 0xFF does it not? Why can't Bruce's "just-use-8" > server convert bytes with values 0x80 through 0xFF into their > corresponding UTF-8 two character sequences in the results, and > similarly accept the UTF-8 two character sequences that correspond to > 0x80 through 0xFF in requests? > > I.e., UCS characters 00000080 through 000007FF are converted to: > 110xxxxx 10xxxxxx. 0x80 would then be > 11000010 10000000 or C2 80. > 0xFF would be > 11000011 10111111 or C3 BF > > Bruce's server would then reject any UTF-8 encoding in a request not > "between" C2 80 and C3 BF with NFS4ERR_BADCHAR. > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 15:16: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 1Ixpnk-00017E-5o; Thu, 29 Nov 2007 15:16:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixpnj-000179-Jp for nfsv4@ietf.org; Thu, 29 Nov 2007 15:15:59 -0500 Received: from web38102.mail.mud.yahoo.com ([209.191.124.129]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ixpnj-0005qS-7G for nfsv4@ietf.org; Thu, 29 Nov 2007 15:15:59 -0500 Received: (qmail 47710 invoked by uid 60001); 29 Nov 2007 20:15:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ixMU3SjQX+jBgqZCWEnyl4NZ3K7WJCzsV71AXGOfW/2fuZzEoJB7dk87iyb13RphE/BFtgXaXfq3xh0YS1V3HEn//l9c5xuJiMfB026zv5OHDDW3Jrg5eOIn70DA9hTmOhdg7GPmMwNJS5kKQxtITr3v42+weB2l6/vlXbg9uxo=; X-YMail-OSG: yMP08psVM1noMbGfTzgrTwY63TzF_N_Z8MjEZug7cBRJ3zRkfEJHfHDZUab7i8CtRoL_N37lDA-- Received: from [198.95.226.230] by web38102.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 12:15:58 PST Date: Thu, 29 Nov 2007 12:15:58 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <1196366978.19682.11.camel@heimdal.trondhjem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <765591.47243.qm@web38102.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com 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 Thu, 2007-11-29 at 11:58 -0800, Mike Eisler wrote: > > > Suppose the locale on the client is set to something other > > than US-ASCII or UTF-8. A process on the client creates a symlink > > containing path component separators, and 8 bit characters with the > > higher bit set. Another process using the same locale issues an > > open() system call on a pathname to symlink, and per > > the NFSv4.1 spec, the path *to* the symlink is UTF-8 (so > > the char set of locale is converted to UTF-8). How does the NFS > > filesystem on the client cope with a logical pathname composed of a > > combination of UTF-8 and "just-use-8"? How does the NFS filesystem > on > > the client even know char set the second half of the logical > pathname > > is? > > So how, in this scenario, does the NFS filesystem get to figure out > what > locale the application is using? The locale is kept in an LC_* environment variable. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 15:23: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 1Ixpux-000463-MI; Thu, 29 Nov 2007 15:23:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixpuw-000411-9G for nfsv4@ietf.org; Thu, 29 Nov 2007 15:23:26 -0500 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixpuu-0007fV-0m for nfsv4@ietf.org; Thu, 29 Nov 2007 15:23:26 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lATKNNOg010174 for ; Thu, 29 Nov 2007 20:23:23 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lATKNMib037646 for ; Thu, 29 Nov 2007 13:23:22 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lATKNIFT003201; Thu, 29 Nov 2007 14:23:18 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lATKNITx003200; Thu, 29 Nov 2007 14:23:18 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Nov 2007 14:23:18 -0600 From: Nicolas Williams To: Trond Myklebust Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129202318.GT2540@Sun.COM> Mail-Followup-To: Trond Myklebust , email2mre-ietf@yahoo.com, nfsv4@ietf.org References: <732993.40146.qm@web38107.mail.mud.yahoo.com> <1196366978.19682.11.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196366978.19682.11.camel@heimdal.trondhjem.org> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 Thu, Nov 29, 2007 at 03:09:38PM -0500, Trond Myklebust wrote: > On Thu, 2007-11-29 at 11:58 -0800, Mike Eisler wrote: > > Suppose the locale on the client is set to something other > > than US-ASCII or UTF-8. A process on the client creates a symlink > > containing path component separators, and 8 bit characters with the > > higher bit set. Another process using the same locale issues an > > open() system call on a pathname to symlink, and per > > the NFSv4.1 spec, the path *to* the symlink is UTF-8 (so > > the char set of locale is converted to UTF-8). How does the NFS > > filesystem on the client cope with a logical pathname composed of a > > combination of UTF-8 and "just-use-8"? How does the NFS filesystem on > > the client even know char set the second half of the logical pathname > > is? > > So how, in this scenario, does the NFS filesystem get to figure out what > locale the application is using? First define some suitable boundaries, define what codeset is used between each, and the answers become clear. You can push all codeset conversions into the NFSv4 client module (in a modular system) if you like, but then you need to pass codeset information up and down the operating system stack between the application and the filesystem. Or you can avoid having to track user-land codeset information in kernel- land by pushing codeset conversions to the edges of the operating system (e.g., the system call layer and the VFS<->filesystem interface). Or you can just get rid of non-UTF-8 locales. All of these choices present various difficulties and/or performance issues, but all are workable. > > > Filesystem object names should always be in UTF-8. We need to allow > > > for > > > legacy filesystem contents -- it's a reality, so really we need to > > > restrict at least CREATEs to UTF-8 only. > > > > Legacy content in the range 0x80 to 0xFF can be converted to > > to UTF-8. > > That also assumes that the kernel knows what charset the app was using. Right, and that's not necessarily the case. A big homedir server in a cosmopolitan company might have content in many codesets. > Otherwise you are converting blindly 'just-use-8' to UTF-8. Either you can't do that at all or you risk a lossy conversion. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 15:38: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 1Ixq9q-0000UN-0T; Thu, 29 Nov 2007 15:38:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixq9o-0000U7-MT for nfsv4@ietf.org; Thu, 29 Nov 2007 15:38:48 -0500 Received: from web38114.mail.mud.yahoo.com ([209.191.124.141]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ixq9o-0008OZ-2a for nfsv4@ietf.org; Thu, 29 Nov 2007 15:38:48 -0500 Received: (qmail 24329 invoked by uid 60001); 29 Nov 2007 20:38:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=OsDwFimBElfh0h2UpWQgsX8+mc/SY2kCvjLDfBzjcWJiUrqrHO6M6LvOhpjUQpp9SR/fz7RueHQ9sl36lX+UKToUXQLPmsuOPmoLhqjfmkl0yFAYCg0BsmdB/rGDCcc4SGKw4Giyd+TZ9aKSRK5QMmX364Q/zPsvUGsR3C94qvI=; X-YMail-OSG: 4oOB_TUVM1luyAmMHEyMWcpBlOP8U0CkDQEPEd7Q4d1HZwh4ZNDqGc2y2gBXv8ll9klkdMdB2tD8BWIWw9wxVHoOniHvzJD5m2gxiWcFJQslwUk- Received: from [198.95.226.230] by web38114.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 12:38:47 PST Date: Thu, 29 Nov 2007 12:38:47 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] symlinks: opaque or UTF-8 To: "Noveck, Dave" , email2mre-ietf@yahoo.com, nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <582185.24287.qm@web38114.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > > The majority of the time they are. We should design for the > > situation where an app is using symlink for something better served > > by a named attribute? > > This may be a rare exception, but normally yes. We should design to > support existing applications and API's, and not consider ourselves > absolved of that responsibility because we think they should have > used > some other facility (and note that servers need not support named > attributes and client need not provide an API to access them on any > partiuclar OS). OK, I set my LC_ environment variable to a non-UTF-8, non-ASCII locale. I issue the symlink() system call using the character set corresponding to LC_. I then issue an open() on that symlink. My NFSv4.1 client follows the link, has to issue OPEN in UTF-8 and it finds that the symlink content is not legal UTF-8. What do I send to the server. If symlinks are opaque, then this means: - We are mandating processes on clients use the UTF-8 locale. They can't even use a supposedly UTF-8 compatible locale like UCS-2 or UCS-4. OR - they can use non-UTF-8 locales, but they cannot use symlinks to for path redirection, unless the symlinks contain just 7bit US-ASCII. All for the sake of rare exceptions. > > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > Sent: Thursday, November 29, 2007 2:59 PM > To: nfsv4@ietf.org > Subject: Re: [nfsv4] symlinks: opaque or UTF-8 > > > > --- Nicolas Williams wrote: > > > > > > My proposal: > > > > > > > > - let symlinks be opaque<> > > > > > > why stop there? > > > > Because symlink content need not be filesystem object names or > paths. > > The majority of the time they are. We should design for the > situation where an app is using symlink for something better served > by a named attribute? > > Suppose the locale on the client is set to something other > than US-ASCII or UTF-8. A process on the client creates a symlink > containing path component separators, and 8 bit characters with the > higher bit set. Another process using the same locale issues an > open() system call on a pathname to symlink, and per > the NFSv4.1 spec, the path *to* the symlink is UTF-8 (so > the char set of locale is converted to UTF-8). How does the NFS > filesystem on the client cope with a logical pathname composed of a > combination of UTF-8 and "just-use-8"? How does the NFS filesystem on > the client even know char set the second half of the logical pathname > is? > > > > Filesystem object names should always be in UTF-8. We need to > allow > > for > > legacy filesystem contents -- it's a reality, so really we need to > > restrict at least CREATEs to UTF-8 only. > > Legacy content in the range 0x80 to 0xFF can be converted to > to UTF-8. > > > > > - declare the character set for the fsid > > > > I don't think this works well. You might not know what that > codeset > > should be, or there may be many in use. > > I'm not sure if most of my customers would agree with you. > > > _______________________________________________ > 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 Nov 29 15:43: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 1IxqEO-0004r3-4H; Thu, 29 Nov 2007 15:43:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxqEM-0004qj-VQ for nfsv4@ietf.org; Thu, 29 Nov 2007 15:43:30 -0500 Received: from [2001:468:e9c:3060::4] (helo=citi.umich.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxqEM-00008y-KB for nfsv4@ietf.org; Thu, 29 Nov 2007 15:43:30 -0500 Received: from citi.umich.edu (d-107.253.eecs.umich.edu [141.212.107.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Jim Rees", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id B00F047E8; Thu, 29 Nov 2007 15:43:29 -0500 (EST) Date: Thu, 29 Nov 2007 15:43:29 -0500 From: Jim Rees To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129204329.GB13956@citi.umich.edu> References: <1196366978.19682.11.camel@heimdal.trondhjem.org> <765591.47243.qm@web38102.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <765591.47243.qm@web38102.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Mike Eisler wrote: The locale is kept in an LC_* environment variable. Is it? % printenv |grep LC % _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 15:46: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 1IxqHN-0005SM-5O; Thu, 29 Nov 2007 15:46:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxqHM-0005SD-5F for nfsv4@ietf.org; Thu, 29 Nov 2007 15:46:36 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxqHK-0000FU-Cb for nfsv4@ietf.org; Thu, 29 Nov 2007 15:46:36 -0500 X-IronPort-AV: E=Sophos;i="4.23,230,1194249600"; d="scan'208";a="127369652" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 29 Nov 2007 12:46:33 -0800 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 lATKkWRa020567; Thu, 29 Nov 2007 12:46:33 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 12:46:32 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 12:46:32 -0800 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] symlinks: opaque or UTF-8 Date: Thu, 29 Nov 2007 15:46:31 -0500 Message-ID: In-Reply-To: <20071129202318.GT2540@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgyxbwMNcVD3y++SpqQHeS5jHUoLwAAjFTA From: "Noveck, Dave" To: "Nicolas Williams" , "Trond Myklebust" X-OriginalArrivalTime: 29 Nov 2007 20:46:32.0467 (UTC) FILETIME=[EC9DC630:01C832C8] X-Spam-Score: -3.8 (---) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 > First define some suitable boundaries, define what codeset is used > between each, and the answers become clear. You can push all codeset > conversions into the NFSv4 client module (in a modular system) if you > like, but then you need to pass codeset information up and down the > operating system stack between the application and the filesystem. Or > you can avoid having to track user-land codeset information in kernel- > land by pushing codeset conversions to the edges of the operating system > (e.g., the system call layer and the VFS<->filesystem interface). Or > you can avoid having to track user-land codeset information in kernel- > land by pushing codeset conversions to the edges of the operating system > (e.g., the system call layer and the VFS<->filesystem interface). Or > you can just get rid of non-UTF-8 locales. All of these choices present > various difficulties and/or performance issues, but all are workable. Right, but the point is, that that requirement has been in force since RFC3530, for path components names. The only question we are discussing is whether it should be extended to symlinks, but even it isn't, if you implement a v4.x client you have to have one of the mechanisms you describe to perfore the conversions to and from UTF-8 (or have to ban any use of=20 non-UTF8). Or permaps I should switch tenses and say if you have implemented a v4.x client, you must have already done one of those things.=20 -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Thursday, November 29, 2007 3:23 PM To: Trond Myklebust Cc: email2mre-ietf@yahoo.com; nfsv4@ietf.org Subject: Re: [nfsv4] symlinks: opaque or UTF-8 On Thu, Nov 29, 2007 at 03:09:38PM -0500, Trond Myklebust wrote: > On Thu, 2007-11-29 at 11:58 -0800, Mike Eisler wrote: > > Suppose the locale on the client is set to something other > > than US-ASCII or UTF-8. A process on the client creates a symlink > > containing path component separators, and 8 bit characters with the > > higher bit set. Another process using the same locale issues an > > open() system call on a pathname to symlink, and per > > the NFSv4.1 spec, the path *to* the symlink is UTF-8 (so > > the char set of locale is converted to UTF-8). How does the NFS > > filesystem on the client cope with a logical pathname composed of a > > combination of UTF-8 and "just-use-8"? How does the NFS filesystem on > > the client even know char set the second half of the logical pathname > > is? >=20 > So how, in this scenario, does the NFS filesystem get to figure out what > locale the application is using? First define some suitable boundaries, define what codeset is used between each, and the answers become clear. You can push all codeset conversions into the NFSv4 client module (in a modular system) if you like, but then you need to pass codeset information up and down the operating system stack between the application and the filesystem. Or you can avoid having to track user-land codeset information in kernel- land by pushing codeset conversions to the edges of the operating system (e.g., the system call layer and the VFS<->filesystem interface). Or you can just get rid of non-UTF-8 locales. All of these choices present various difficulties and/or performance issues, but all are workable. > > > Filesystem object names should always be in UTF-8. We need to allow > > > for > > > legacy filesystem contents -- it's a reality, so really we need to > > > restrict at least CREATEs to UTF-8 only. > >=20 > > Legacy content in the range 0x80 to 0xFF can be converted to > > to UTF-8. >=20 > That also assumes that the kernel knows what charset the app was using. Right, and that's not necessarily the case. A big homedir server in a cosmopolitan company might have content in many codesets. > Otherwise you are converting blindly 'just-use-8' to UTF-8. Either you can't do that at all or you risk a lossy conversion. Nico --=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 Nov 29 15:49: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 1IxqKT-00067a-7E; Thu, 29 Nov 2007 15:49:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxqKR-00067U-Sq for nfsv4@ietf.org; Thu, 29 Nov 2007 15:49:47 -0500 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxqKR-0007M7-Aa for nfsv4@ietf.org; Thu, 29 Nov 2007 15:49:47 -0500 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IxqKQ-0000DL-Ao; Thu, 29 Nov 2007 21:49:46 +0100 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 1IxqKP-0001tj-Uq; Thu, 29 Nov 2007 21:49:46 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IxqKP-0001tZ-Ek; Thu, 29 Nov 2007 21:49:45 +0100 Subject: Re: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: email2mre-ietf@yahoo.com In-Reply-To: <765591.47243.qm@web38102.mail.mud.yahoo.com> References: <765591.47243.qm@web38102.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 29 Nov 2007 15:49:43 -0500 Message-Id: <1196369383.20292.19.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.089) X-UiO-Scanned: F4BDE0726215642A0C429199EC17051DBF322EB7 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 782 total 5468509 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Thu, 2007-11-29 at 12:15 -0800, Mike Eisler wrote: > --- Trond Myklebust wrote: > > > > > On Thu, 2007-11-29 at 11:58 -0800, Mike Eisler wrote: > > > > > Suppose the locale on the client is set to something other > > > than US-ASCII or UTF-8. A process on the client creates a symlink > > > containing path component separators, and 8 bit characters with the > > > higher bit set. Another process using the same locale issues an > > > open() system call on a pathname to symlink, and per > > > the NFSv4.1 spec, the path *to* the symlink is UTF-8 (so > > > the char set of locale is converted to UTF-8). How does the NFS > > > filesystem on the client cope with a logical pathname composed of a > > > combination of UTF-8 and "just-use-8"? How does the NFS filesystem > > on > > > the client even know char set the second half of the logical > > pathname > > > is? > > > > So how, in this scenario, does the NFS filesystem get to figure out > > what > > locale the application is using? > > The locale is kept in an LC_* environment variable. Sorry, but those environment variables are not, and have never been, part of the official Linux syscall interface. Any information they may contain cannot be used in the filesystem code. Even if it could, then that would break locale-savvy applications, which use the glibc setlocale() interface: the latter does not change the environment variables, nor does it call down into the kernel. Basically, our syscall interfaces take character string arguments, not wide character strings, and not multi-byte character strings. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 15:57: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 1IxqRr-0004W3-VO; Thu, 29 Nov 2007 15:57:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxqRq-0004Vl-Em for nfsv4@ietf.org; Thu, 29 Nov 2007 15:57:26 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxqRp-0007f5-Vf for nfsv4@ietf.org; Thu, 29 Nov 2007 15:57:26 -0500 X-IronPort-AV: E=Sophos;i="4.23,230,1194249600"; d="scan'208";a="127372798" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 29 Nov 2007 12:57:25 -0800 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 lATKvKol022986; Thu, 29 Nov 2007 12:57:25 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 12:57:24 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 12:57:23 -0800 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] symlinks: opaque or UTF-8 Date: Thu, 29 Nov 2007 15:57:22 -0500 Message-ID: In-Reply-To: <1196369383.20292.19.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgyyWlmCXHcL4pkRDyQfAlOQQ6GrgAADMqw From: "Noveck, Dave" To: "Trond Myklebust" , X-OriginalArrivalTime: 29 Nov 2007 20:57:23.0975 (UTC) FILETIME=[70F20170:01C832CA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 baffled. Forget symlinks (How I wish I could). Someone running a non-UTF8 locale issues a remove or open or rename. You get a string that is not UTF-8. You have an NFSv4 client that sends requests to a server that expects UTF-8 strings (he sends you NFS4ERR_INVAL if you send them, just as RFC3530 says he should. I assume you need to translate them to UTF8 so you can do the required operation rather than return EINVAL and listen to him scream. How do you do it? -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Thursday, November 29, 2007 3:50 PM To: email2mre-ietf@yahoo.com Cc: nfsv4@ietf.org Subject: Re: [nfsv4] symlinks: opaque or UTF-8 On Thu, 2007-11-29 at 12:15 -0800, Mike Eisler wrote: > --- Trond Myklebust wrote: >=20 > >=20 > > On Thu, 2007-11-29 at 11:58 -0800, Mike Eisler wrote: > >=20 > > > Suppose the locale on the client is set to something other > > > than US-ASCII or UTF-8. A process on the client creates a symlink > > > containing path component separators, and 8 bit characters with the > > > higher bit set. Another process using the same locale issues an > > > open() system call on a pathname to symlink, and per > > > the NFSv4.1 spec, the path *to* the symlink is UTF-8 (so > > > the char set of locale is converted to UTF-8). How does the NFS > > > filesystem on the client cope with a logical pathname composed of a > > > combination of UTF-8 and "just-use-8"? How does the NFS filesystem > > on > > > the client even know char set the second half of the logical > > pathname > > > is? > >=20 > > So how, in this scenario, does the NFS filesystem get to figure out > > what > > locale the application is using? >=20 > The locale is kept in an LC_* environment variable. Sorry, but those environment variables are not, and have never been, part of the official Linux syscall interface. Any information they may contain cannot be used in the filesystem code. Even if it could, then that would break locale-savvy applications, which use the glibc setlocale() interface: the latter does not change the environment variables, nor does it call down into the kernel. Basically, our syscall interfaces take character string arguments, not wide character strings, and not multi-byte character strings. 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 Thu Nov 29 16:05: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 1IxqZZ-0000x9-Qh; Thu, 29 Nov 2007 16:05:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxqZX-0000wS-By for nfsv4@ietf.org; Thu, 29 Nov 2007 16:05:23 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxqZW-0001O4-SR for nfsv4@ietf.org; Thu, 29 Nov 2007 16:05:23 -0500 Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IxqZV-00064W-8m; Thu, 29 Nov 2007 22:05:21 +0100 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 1IxqZU-0004WJ-Uf; Thu, 29 Nov 2007 22:05:21 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IxqZU-0004Vr-Fx; Thu, 29 Nov 2007 22:05:20 +0100 Subject: RE: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Thu, 29 Nov 2007 16:05:18 -0500 Message-Id: <1196370318.20292.26.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.3, required=12.0, autolearn=disabled, AWL=-0.278) X-UiO-Scanned: FEE3C55447B7EBA166597192CAA2588C60C52B95 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -2 maxlevel 200 minaction 2 bait 0 mail/h: 55 total 5468700 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Thu, 2007-11-29 at 15:57 -0500, Noveck, Dave wrote: > I'm baffled. Forget symlinks (How I wish I could). > > Someone running a non-UTF8 locale issues a remove or open or rename. > You get a string that is not UTF-8. You have an NFSv4 client that sends > requests to a server that expects UTF-8 strings (he sends you > NFS4ERR_INVAL if you send them, just as RFC3530 says he should. I > assume you need to translate them to UTF8 so you can do the required > operation rather than return EINVAL and listen to him scream. How do > you do it? We don't. We never have, and we never will. The NFS client code faithfully sends whatever the user sends down in the syscall, and returns faithfully whatever the server sends us in its READDIR/READLINK/... reply. There is no stringprep, there is no locale conversion other than whatever was done in userland by the application. If the server chooses to enforce a particular encoding, then that is entirely up to it. The reason why I'm objecting in the particular case of symlinks, is that symlinks refer to the _client_ namespace. They are inherently non-portable, because on my machine, I can mount whatever I like, whereever I like, and that changes the meaning of the symlink. That is what makes symlinks special, and is why I don't agree with the server performing any checking whatsoever on the contents. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 16:06: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 1IxqaL-0001Ia-6X; Thu, 29 Nov 2007 16:06:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxqaJ-0001ID-IJ for nfsv4@ietf.org; Thu, 29 Nov 2007 16:06:11 -0500 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxqaI-0001gk-4f for nfsv4@ietf.org; Thu, 29 Nov 2007 16:06:11 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lATL69Md028564 for ; Thu, 29 Nov 2007 21:06:09 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lATL68eU000464 for ; Thu, 29 Nov 2007 14:06:09 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lATL68xJ003251; Thu, 29 Nov 2007 15:06:08 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lATL68lG003250; Thu, 29 Nov 2007 15:06:08 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Nov 2007 15:06:08 -0600 From: Nicolas Williams To: "Noveck, Dave" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129210607.GY2540@Sun.COM> Mail-Followup-To: "Noveck, Dave" , Trond Myklebust , email2mre-ietf@yahoo.com, nfsv4@ietf.org References: <20071129202318.GT2540@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: email2mre-ietf@yahoo.com, 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 Thu, Nov 29, 2007 at 03:46:31PM -0500, Noveck, Dave wrote: > Right, but the point is, that that requirement has been in force since > RFC3530, for path components names. The only question we are discussing > is whether it should be extended to symlinks, but even it isn't, if you > implement a v4.x client you have to have one of the mechanisms you > describe to perfore the conversions to and from UTF-8 (or have to ban > any use of non-UTF8). Or permaps I should switch tenses and say if > you have implemented a v4.x client, you must have already done one of > those things. I agree entirely. For me this thread is primarily about symlink contents. There are interesting sub-threads, but as far as NFSv4.1 the only substantive issue here is what to say about symlink contents. On that score I recomment opaque, but UTF-8 is OK -- I don't foresee a lot of problems arising from using UTF-8 for symlink contents. (All that said, I suspect most NFSv4 implementations haven't gotten the I18N stuff right, but will eventually.) Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 16:09: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 1Ixqdo-0002ty-Fj; Thu, 29 Nov 2007 16:09:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixqdm-0002tK-Kp for nfsv4@ietf.org; Thu, 29 Nov 2007 16:09:46 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixqdl-0002CO-SQ for nfsv4@ietf.org; Thu, 29 Nov 2007 16:09:46 -0500 X-IronPort-AV: E=Sophos;i="4.23,230,1194249600"; d="scan'208";a="127376676" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 29 Nov 2007 13:09:44 -0800 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 lATL9iIB026521; Thu, 29 Nov 2007 13:09:44 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 13:09:44 -0800 Received: from exsvl02.hq.netapp.com ([10.56.8.60]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 13:09:43 -0800 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] symlinks: opaque or UTF-8 Date: Thu, 29 Nov 2007 13:09:42 -0800 Message-ID: <992BA60650F1584BA63E339312CE42030C9B8E5A@exsvl02.hq.netapp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgyyWlmCXHcL4pkRDyQfAlOQQ6GrgAADMqwAACIypA= From: "Yoder, Alan" To: "Noveck, Dave" , "Trond Myklebust" , X-OriginalArrivalTime: 29 Nov 2007 21:09:43.0820 (UTC) FILETIME=[29ED64C0:01C832CC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 thought it was the client's job to translate non-UTF-8 strings into UTF-8 and back when communicating with the server? A Windows NFS client would certainly have to do this, for example, as their internal format is Unicode. Alan > -----Original Message----- > From: Noveck, Dave=20 > Sent: Thursday, November 29, 2007 12:57 PM > To: Trond Myklebust; email2mre-ietf@yahoo.com > Cc: nfsv4@ietf.org > Subject: RE: [nfsv4] symlinks: opaque or UTF-8 >=20 > I'm baffled. Forget symlinks (How I wish I could). >=20 > Someone running a non-UTF8 locale issues a remove or open or rename. > You get a string that is not UTF-8. You have an NFSv4 client=20 > that sends > requests to a server that expects UTF-8 strings (he sends you > NFS4ERR_INVAL if you send them, just as RFC3530 says he should. I > assume you need to translate them to UTF8 so you can do the required > operation rather than return EINVAL and listen to him scream. How do > you do it? >=20 > -----Original Message----- > From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 > Sent: Thursday, November 29, 2007 3:50 PM > To: email2mre-ietf@yahoo.com > Cc: nfsv4@ietf.org > Subject: Re: [nfsv4] symlinks: opaque or UTF-8 >=20 >=20 >=20 > On Thu, 2007-11-29 at 12:15 -0800, Mike Eisler wrote: > > --- Trond Myklebust wrote: > >=20 > > >=20 > > > On Thu, 2007-11-29 at 11:58 -0800, Mike Eisler wrote: > > >=20 > > > > Suppose the locale on the client is set to something other > > > > than US-ASCII or UTF-8. A process on the client creates=20 > a symlink > > > > containing path component separators, and 8 bit characters with > the > > > > higher bit set. Another process using the same locale issues an > > > > open() system call on a pathname to symlink, and per > > > > the NFSv4.1 spec, the path *to* the symlink is UTF-8 (so > > > > the char set of locale is converted to UTF-8). How does the NFS > > > > filesystem on the client cope with a logical pathname=20 > composed of > a > > > > combination of UTF-8 and "just-use-8"? How does the NFS=20 > filesystem > > > on > > > > the client even know char set the second half of the logical > > > pathname > > > > is? > > >=20 > > > So how, in this scenario, does the NFS filesystem get to=20 > figure out > > > what > > > locale the application is using? > >=20 > > The locale is kept in an LC_* environment variable. >=20 > Sorry, but those environment variables are not, and have never been, > part of the official Linux syscall interface. Any information they may > contain cannot be used in the filesystem code. > Even if it could, then that would break locale-savvy=20 > applications, which > use the glibc setlocale() interface: the latter does not change the > environment variables, nor does it call down into the kernel. >=20 > Basically, our syscall interfaces take character string arguments, not > wide character strings, and not multi-byte character strings. >=20 > Trond >=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 >=20 >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 16: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 1Ixqi6-0004mg-P9; Thu, 29 Nov 2007 16:14:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixqi5-0004mM-6M for nfsv4@ietf.org; Thu, 29 Nov 2007 16:14:13 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixqi4-0005Xh-Sw for nfsv4@ietf.org; Thu, 29 Nov 2007 16:14:13 -0500 Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Ixqi3-0002E4-Br; Thu, 29 Nov 2007 22:14:11 +0100 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 1Ixqi2-0003Dq-Ki; Thu, 29 Nov 2007 22:14:10 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ixqi2-0003DP-7t; Thu, 29 Nov 2007 22:14:10 +0100 Subject: RE: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: "Yoder, Alan" In-Reply-To: <992BA60650F1584BA63E339312CE42030C9B8E5A@exsvl02.hq.netapp.com> References: <992BA60650F1584BA63E339312CE42030C9B8E5A@exsvl02.hq.netapp.com> Content-Type: text/plain Date: Thu, 29 Nov 2007 16:14:08 -0500 Message-Id: <1196370848.20292.29.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.3, required=12.0, autolearn=disabled, AWL=-0.350) X-UiO-Scanned: 681871158071D987FEF1D381E2A1773195C50990 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -2 maxlevel 200 minaction 2 bait 0 mail/h: 154 total 5468799 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: email2mre-ietf@yahoo.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 On Thu, 2007-11-29 at 13:09 -0800, Yoder, Alan wrote: > I thought it was the client's job to translate > non-UTF-8 strings into UTF-8 and back when > communicating with the server? A Windows NFS > client would certainly have to do this, for > example, as their internal format is Unicode. Why? A Windows symlink would only make sense on that windows client. They don't even use the same pathname separators as UNIX machines and nor do we impose this upon them in the spec. Symlinks are non-portable. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 16:48: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 1IxrFP-0000qv-K2; Thu, 29 Nov 2007 16:48:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrFO-0000qn-UY for nfsv4@ietf.org; Thu, 29 Nov 2007 16:48:38 -0500 Received: from web38102.mail.mud.yahoo.com ([209.191.124.129]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxrFO-0006m1-Is for nfsv4@ietf.org; Thu, 29 Nov 2007 16:48:38 -0500 Received: (qmail 84884 invoked by uid 60001); 29 Nov 2007 21:48:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=6GFpqS73Kcs76gX/vn/glET+VXv4CInuqCkV36jzzNGkAM8a1Cl7Ple+++TWgam+QvQHYderJkfgsQqjWSTmXcPUJTFMwNcoQZQLXp+2RHPM7pNK18U3itH9bl/RHC2in7P9qwPi4SgjAFPeCHoR0aUz7Gx1dWZp+0IyTYxDsqM=; X-YMail-OSG: Sexx3EMVM1kNa5EGGvM9rTmZ2_2QtV93ov16kkqkUYZlYB5Ja4vR.wYSDk3W8d8mTVWnOMsVgA-- Received: from [198.95.226.230] by web38102.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 13:48:38 PST Date: Thu, 29 Nov 2007 13:48:38 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071129202318.GT2540@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <145045.84532.qm@web38102.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Nicolas Williams wrote: > > So how, in this scenario, does the NFS filesystem get to figure out > what > > locale the application is using? > > First define some suitable boundaries, define what codeset is used > between each, and the answers become clear. You can push all codeset > conversions into the NFSv4 client module (in a modular system) if you > like, but then you need to pass codeset information up and down the > operating system stack between the application and the filesystem. > Or > you can avoid having to track user-land codeset information in > kernel- > land by pushing codeset conversions to the edges of the operating > system > (e.g., the system call layer and the VFS<->filesystem interface). Or > you can just get rid of non-UTF-8 locales. All of these choices > present > various difficulties and/or performance issues, but all are workable. I know from customer experience with NFSv4 that getting rid of non-UTF-8 locales is a non-starter. People who live in locales that express their characters in 8 bits often don't want to move to 16 bit UTF-8 sequences. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 16:49: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 1IxrGW-0002cF-Ny; Thu, 29 Nov 2007 16:49:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrGV-0002a2-M7 for nfsv4@ietf.org; Thu, 29 Nov 2007 16:49:47 -0500 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxrGV-0005N9-8P for nfsv4@ietf.org; Thu, 29 Nov 2007 16:49:47 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lATLnjn7005418 for ; Thu, 29 Nov 2007 21:49:46 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lATLnjtL019774 for ; Thu, 29 Nov 2007 14:49:45 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lATLnjju003282; Thu, 29 Nov 2007 15:49:45 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lATLnjK5003281; Thu, 29 Nov 2007 15:49:45 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Nov 2007 15:49:45 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129214944.GA2540@Sun.COM> Mail-Followup-To: Mike Eisler , "Noveck, Dave" , nfsv4@ietf.org References: <582185.24287.qm@web38114.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <582185.24287.qm@web38114.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Thu, Nov 29, 2007 at 12:38:47PM -0800, Mike Eisler wrote: > OK, I set my LC_ environment variable to a non-UTF-8, non-ASCII > locale. I issue the symlink() system call using the character set > corresponding to LC_. I then issue an open() on that symlink. > My NFSv4.1 client follows the link, has to issue OPEN in UTF-8 and > it finds that the symlink content is not legal UTF-8. What do I send > to the server. Yes, I see your point. If symlink contents is opaque then you have to be careful to create them with UTF-8 contents only when their contents is intended to be a path. > If symlinks are opaque, then this means: > > [...] > > All for the sake of rare exceptions. Sold. Symlink contents must be UTF-8. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 16:52: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 1IxrIv-0008Bs-JI; Thu, 29 Nov 2007 16:52:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrIu-00086y-HB for nfsv4@ietf.org; Thu, 29 Nov 2007 16:52:16 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxrIu-0005kN-65 for nfsv4@ietf.org; Thu, 29 Nov 2007 16:52:16 -0500 X-IronPort-AV: E=Sophos;i="4.23,230,1194249600"; d="scan'208";a="127390578" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 29 Nov 2007 13:52:15 -0800 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 lATLqEWe007022; Thu, 29 Nov 2007 13:52:15 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 13:52:09 -0800 Received: from exsvl02.hq.netapp.com ([10.56.8.60]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 13:52:09 -0800 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] symlinks: opaque or UTF-8 Date: Thu, 29 Nov 2007 13:52:08 -0800 Message-ID: <992BA60650F1584BA63E339312CE42030C9B8E96@exsvl02.hq.netapp.com> In-Reply-To: <1196370848.20292.29.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgyzMwRszqJGSHwTo2PxlA0X8U4hAABHlGQ From: "Yoder, Alan" To: "Trond Myklebust" X-OriginalArrivalTime: 29 Nov 2007 21:52:09.0368 (UTC) FILETIME=[17313180:01C832D2] X-Spam-Score: -3.8 (---) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: email2mre-ietf@yahoo.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 I was speaking about file and directory names. I disagree with the assertion that symlinks should be noninteroperable. But if versioning rules won't let us fix that, I guess there you have it. Alan=20 > -----Original Message----- > From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 > Sent: Thursday, November 29, 2007 1:14 PM > To: Yoder, Alan > Cc: Noveck, Dave; email2mre-ietf@yahoo.com; nfsv4@ietf.org > Subject: RE: [nfsv4] symlinks: opaque or UTF-8 >=20 >=20 > On Thu, 2007-11-29 at 13:09 -0800, Yoder, Alan wrote: > > I thought it was the client's job to translate > > non-UTF-8 strings into UTF-8 and back when > > communicating with the server? A Windows NFS > > client would certainly have to do this, for > > example, as their internal format is Unicode. >=20 > Why? A Windows symlink would only make sense on that windows client. > They don't even use the same pathname separators as UNIX machines and > nor do we impose this upon them in the spec. Symlinks are=20 > non-portable. >=20 > Trond >=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 16:57:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrNV-0005k3-Rg; Thu, 29 Nov 2007 16:57:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrNU-0005ja-PD for nfsv4@ietf.org; Thu, 29 Nov 2007 16:57:00 -0500 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxrNS-00087E-WB for nfsv4@ietf.org; Thu, 29 Nov 2007 16:57:00 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lATLuwrO013145 for ; Thu, 29 Nov 2007 21:56:58 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lATLuwxK024894 for ; Thu, 29 Nov 2007 14:56:58 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lATLuvbP003293; Thu, 29 Nov 2007 15:56:57 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lATLuvgi003292; Thu, 29 Nov 2007 15:56:57 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Nov 2007 15:56:57 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129215657.GB2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <20071129202318.GT2540@Sun.COM> <145045.84532.qm@web38102.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <145045.84532.qm@web38102.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Thu, Nov 29, 2007 at 01:48:38PM -0800, Mike Eisler wrote: > I know from customer experience with NFSv4 that getting rid of > non-UTF-8 locales is a non-starter. People who live in locales that > express their characters in 8 bits often don't want to move to 16 bit > UTF-8 sequences. Indeed, there are good reasons why getting rid of non-UTF-8, non-US-ASCII locales cannot be part of most vendors' I18N strategy. That leaves at least two other designs :) NFSv4 I18N is definitely feasible. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 17:00: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 1IxrQb-0001T3-VY; Thu, 29 Nov 2007 17:00:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrQa-0001Ne-7d for nfsv4@ietf.org; Thu, 29 Nov 2007 17:00:12 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxrQZ-00008F-Ib for nfsv4@ietf.org; Thu, 29 Nov 2007 17:00:12 -0500 X-IronPort-AV: E=Sophos;i="4.23,230,1194249600"; d="scan'208";a="127393256" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 29 Nov 2007 14:00:09 -0800 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 lATM0868008950; Thu, 29 Nov 2007 14:00:08 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 14:00:08 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 14:00:07 -0800 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] symlinks: opaque or UTF-8 Date: Thu, 29 Nov 2007 17:00:06 -0500 Message-ID: In-Reply-To: <1196370848.20292.29.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgyzMxqaoFmEGRcThaAjgV8qEPmGgAA9Gbg From: "Noveck, Dave" To: "Trond Myklebust" , "Yoder, Alan" X-OriginalArrivalTime: 29 Nov 2007 22:00:07.0936 (UTC) FILETIME=[3470E000:01C832D3] X-Spam-Score: -3.8 (---) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 I think you should consider Alan's remarks as relevant to the more general question of non-symlink pathname components. Since you have stated a general (and ostensibly final) position regarding charracter translation in general, not just for symlinks, I understood his remarks in that light. The spec simply says that the strings are UTF8 at the server interface (i.e. in the protocol). It doesn't state, whether the responsibilility to make them so belongs to the client or to the application, although I always assumed that the client would be doing this translation. =20 A widnows client could take a position parallel to Trond's, that it will not do translation from UCS-2 to UTF-8 and the application should do it. The spec has nothing to say about that. I imagine Windows users and application writers might have a great deal to say about it. -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Thursday, November 29, 2007 4:14 PM To: Yoder, Alan Cc: Noveck, Dave; email2mre-ietf@yahoo.com; nfsv4@ietf.org Subject: RE: [nfsv4] symlinks: opaque or UTF-8 On Thu, 2007-11-29 at 13:09 -0800, Yoder, Alan wrote: > I thought it was the client's job to translate > non-UTF-8 strings into UTF-8 and back when > communicating with the server? A Windows NFS > client would certainly have to do this, for > example, as their internal format is Unicode. Why? A Windows symlink would only make sense on that windows client. They don't even use the same pathname separators as UNIX machines and nor do we impose this upon them in the spec. Symlinks are non-portable. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 17:04:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrUq-00083z-G1; Thu, 29 Nov 2007 17:04:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrUo-00083i-SI for nfsv4@ietf.org; Thu, 29 Nov 2007 17:04:34 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxrUo-0007h2-DO for nfsv4@ietf.org; Thu, 29 Nov 2007 17:04:34 -0500 X-IronPort-AV: E=Sophos;i="4.23,230,1194249600"; d="scan'208";a="127394867" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 29 Nov 2007 14:04:34 -0800 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 lATM4XPX010209; Thu, 29 Nov 2007 14:04:33 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 14:04:33 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 14:04:32 -0800 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] symlinks: opaque or UTF-8 Date: Thu, 29 Nov 2007 17:04:31 -0500 Message-ID: In-Reply-To: <145045.84532.qm@web38102.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: Acgy0gyVDdw2mRqqQFCwfEKAMQMVxwAAWaNA From: "Noveck, Dave" To: , X-OriginalArrivalTime: 29 Nov 2007 22:04:32.0747 (UTC) FILETIME=[D247D3B0:01C832D3] X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Or even 24-bit. Many quite widely used non-CJK languages are outside the=20 range that fits in 16 bits in UTF-8. For example, Hindi. -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Thursday, November 29, 2007 4:49 PM To: nfsv4@ietf.org Subject: Re: [nfsv4] symlinks: opaque or UTF-8 --- Nicolas Williams wrote: > > So how, in this scenario, does the NFS filesystem get to figure out > what > > locale the application is using? >=20 > First define some suitable boundaries, define what codeset is used > between each, and the answers become clear. You can push all codeset > conversions into the NFSv4 client module (in a modular system) if you > like, but then you need to pass codeset information up and down the > operating system stack between the application and the filesystem.=20 > Or > you can avoid having to track user-land codeset information in > kernel- > land by pushing codeset conversions to the edges of the operating > system > (e.g., the system call layer and the VFS<->filesystem interface). Or > you can just get rid of non-UTF-8 locales. All of these choices > present > various difficulties and/or performance issues, but all are workable. I know from customer experience with NFSv4 that getting rid of non-UTF-8 locales is a non-starter. People who live in locales that express their characters in 8 bits often don't want to move to 16 bit UTF-8 sequences. _______________________________________________ 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 Nov 29 17:07:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrXg-00044N-7z; Thu, 29 Nov 2007 17:07:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrXf-000443-HE for nfsv4@ietf.org; Thu, 29 Nov 2007 17:07:31 -0500 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxrXe-0001IQ-W9 for nfsv4@ietf.org; Thu, 29 Nov 2007 17:07:31 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lATM7TQJ005499 for ; Thu, 29 Nov 2007 22:07:29 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lATM7TPG032260 for ; Thu, 29 Nov 2007 15:07:29 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lATM7Siw003310; Thu, 29 Nov 2007 16:07:28 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lATM7Sll003309; Thu, 29 Nov 2007 16:07:28 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Nov 2007 16:07:28 -0600 From: Nicolas Williams To: "Noveck, Dave" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129220728.GD2540@Sun.COM> Mail-Followup-To: "Noveck, Dave" , Trond Myklebust , email2mre-ietf@yahoo.com, nfsv4@ietf.org References: <1196369383.20292.19.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: email2mre-ietf@yahoo.com, 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 Thu, Nov 29, 2007 at 03:57:22PM -0500, Noveck, Dave wrote: > I'm baffled. Forget symlinks (How I wish I could). > > Someone running a non-UTF8 locale issues a remove or open or rename. > You get a string that is not UTF-8. You have an NFSv4 client that sends > requests to a server that expects UTF-8 strings (he sends you > NFS4ERR_INVAL if you send them, just as RFC3530 says he should. I > assume you need to translate them to UTF8 so you can do the required > operation rather than return EINVAL and listen to him scream. How do > you do it? Local detail. The client, somewhere, has all the necessary information. For most Unix and Unix-like clients *today* that somewhere is the libc system call stubs, *provided* that one is willing to declare that below the system call layer in the kernel all filesystem object names must be in one particular codeset and encoding (e.g., UTF-8). Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 17:08: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 1IxrYz-0004jq-Mm; Thu, 29 Nov 2007 17:08:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrYy-0004jD-L3 for nfsv4@ietf.org; Thu, 29 Nov 2007 17:08:52 -0500 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxrYy-0008S5-8C for nfsv4@ietf.org; Thu, 29 Nov 2007 17:08:52 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lATM8pwC016606 for ; Thu, 29 Nov 2007 22:08:51 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lATM8oTv032865 for ; Thu, 29 Nov 2007 15:08:51 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lATM8on8003317; Thu, 29 Nov 2007 16:08:50 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lATM8o2L003316; Thu, 29 Nov 2007 16:08:50 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Nov 2007 16:08:50 -0600 From: Nicolas Williams To: Trond Myklebust Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129220850.GE2540@Sun.COM> Mail-Followup-To: Trond Myklebust , "Noveck, Dave" , email2mre-ietf@yahoo.com, nfsv4@ietf.org References: <1196370318.20292.26.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196370318.20292.26.camel@heimdal.trondhjem.org> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: email2mre-ietf@yahoo.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 On Thu, Nov 29, 2007 at 04:05:18PM -0500, Trond Myklebust wrote: > The reason why I'm objecting in the particular case of symlinks, is that > symlinks refer to the _client_ namespace. They are inherently > non-portable, because on my machine, I can mount whatever I like, > whereever I like, and that changes the meaning of the symlink. That is > what makes symlinks special, and is why I don't agree with the server > performing any checking whatsoever on the contents. I18N is not specific to NFSv4. You should think of it as pervasive, affecting *all* your filesystems. Then this problem goes away. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 17:09: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 1IxrZJ-0004pk-22; Thu, 29 Nov 2007 17:09:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrZH-0004pY-AI for nfsv4@ietf.org; Thu, 29 Nov 2007 17:09:11 -0500 Received: from web38113.mail.mud.yahoo.com ([209.191.124.140]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxrZG-0008Vm-SX for nfsv4@ietf.org; Thu, 29 Nov 2007 17:09:11 -0500 Received: (qmail 86068 invoked by uid 60001); 29 Nov 2007 22:09:10 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=3WOX4kx82TYtqVdLLh8lHKbOuoYbl+bqHy9D5H0s+0eeC0AuoDuAnWS9YwuBgJksUnNY/6NK5lsHZjKOwJdnOuBuP6EF0KeSCUruf445hFX7FJj3QVVemFNcxTvkLtaiDZsbc+GBNhKKlCgN0BP5YOP8j7DGPwnNIIgd92eKcZM=; X-YMail-OSG: x00EoOoVM1l.FClMNB2nM70V4lRDD13KjO4ePbCyRh8HC_cMNLTA98mqBUP7w42KnQbmXMI1Cz_UySUJ.wX4Tvt13z9h3sWYmkOGY4qAhO4LNzIJ2Jg- Received: from [198.95.226.230] by web38113.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 14:09:10 PST Date: Thu, 29 Nov 2007 14:09:10 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <346360.85621.qm@web38113.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Yes I understand, but as should be clear from Trond's comments about how Linux works, someone using an 8 bit character set would be well advised to stick with just-use-8. Hindi and other speaks that used Linux are simply out of luck. --- "Noveck, Dave" wrote: > Or even 24-bit. Many quite widely used non-CJK languages are outside > the > range that fits in 16 bits in UTF-8. For example, Hindi. > > -----Original Message----- > From: Mike Eisler [mailto:email2mre-ietf@yahoo.com] > Sent: Thursday, November 29, 2007 4:49 PM > To: nfsv4@ietf.org > Subject: Re: [nfsv4] symlinks: opaque or UTF-8 > > > > --- Nicolas Williams wrote: > > > > > So how, in this scenario, does the NFS filesystem get to figure > out > > what > > > locale the application is using? > > > > First define some suitable boundaries, define what codeset is used > > between each, and the answers become clear. You can push all > codeset > > conversions into the NFSv4 client module (in a modular system) if > you > > like, but then you need to pass codeset information up and down the > > operating system stack between the application and the filesystem. > > Or > > you can avoid having to track user-land codeset information in > > kernel- > > land by pushing codeset conversions to the edges of the operating > > system > > (e.g., the system call layer and the VFS<->filesystem interface). > Or > > you can just get rid of non-UTF-8 locales. All of these choices > > present > > various difficulties and/or performance issues, but all are > workable. > > I know from customer experience with NFSv4 that getting rid of > non-UTF-8 locales is a non-starter. People who live in locales that > express their > characters in 8 bits often don't want to move to 16 bit UTF-8 > sequences. > > > _______________________________________________ > 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 Nov 29 17:13:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixrdk-0006ka-IZ; Thu, 29 Nov 2007 17:13:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixrdj-0006kN-Ch for nfsv4@ietf.org; Thu, 29 Nov 2007 17:13:47 -0500 Received: from web38108.mail.mud.yahoo.com ([209.191.124.135]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ixrdi-0000uW-VC for nfsv4@ietf.org; Thu, 29 Nov 2007 17:13:47 -0500 Received: (qmail 94976 invoked by uid 60001); 29 Nov 2007 22:13:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=w9F9yz54uO75nNQyVK7Aj/TOHhx0dZPl4DSJv/qrncvqMF1RYI7YGKwN0aHNoA7anJv/B4FpzRZjO4lapc81B1YtLqEa0RstFYpgOsn+qz7vtmOOlhPh5JKV7FdaQqDbbYY9dFfT5Y8FsOwDXmUoHrA/S4Ae7+L1h9CyVyCkqts=; X-YMail-OSG: 7QmeYqUVM1mHHXc_jK.72fGUfwC4oz3vPUbDbOwIupFnuSYn53uMtL9Hedjat6BlKhUriQEvnQ-- Received: from [198.95.226.230] by web38108.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 14:13:43 PST Date: Thu, 29 Nov 2007 14:13:43 -0800 (PST) From: Mike Eisler To: nfsv4@ietf.org In-Reply-To: <1196370318.20292.26.camel@heimdal.trondhjem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <651457.94366.qm@web38108.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [nfsv4] UTF-8 or or "just-use-8" X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org Given the market position of the Linux client in the NFS space, and given that it is going to send non-UTF-8 characters, NFSv4.x is untenable in non-English-speaking locales. So I think we should do one of: - change the spec to allow the client and server to indicate to each other that both are using a "just-use-8" model - get rid of UTF-8 all together. If we decide latter requires us to add OPEN2, CREATE2, etc., I'd rather we just moved to NFSv5. --- Trond Myklebust wrote: > > On Thu, 2007-11-29 at 15:57 -0500, Noveck, Dave wrote: > > I'm baffled. Forget symlinks (How I wish I could). > > > > Someone running a non-UTF8 locale issues a remove or open or > rename. > > You get a string that is not UTF-8. You have an NFSv4 client that > sends > > requests to a server that expects UTF-8 strings (he sends you > > NFS4ERR_INVAL if you send them, just as RFC3530 says he should. I > > assume you need to translate them to UTF8 so you can do the > required > > operation rather than return EINVAL and listen to him scream. How > do > > you do it? > > We don't. We never have, and we never will. > > The NFS client code faithfully sends whatever the user sends down in > the > syscall, and returns faithfully whatever the server sends us in its > READDIR/READLINK/... reply. There is no stringprep, there is no > locale > conversion other than whatever was done in userland by the > application. > If the server chooses to enforce a particular encoding, then that is > entirely up to it. > > The reason why I'm objecting in the particular case of symlinks, is > that > symlinks refer to the _client_ namespace. They are inherently > non-portable, because on my machine, I can mount whatever I like, > whereever I like, and that changes the meaning of the symlink. That > is > what makes symlinks special, and is why I don't agree with the server > performing any checking whatsoever on the contents. > > Trond > > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 17:14: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 1IxreU-00076R-2K; Thu, 29 Nov 2007 17:14:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxreT-00076E-F0 for nfsv4@ietf.org; Thu, 29 Nov 2007 17:14:33 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxreT-00013I-3y for nfsv4@ietf.org; Thu, 29 Nov 2007 17:14:33 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IxreB-0000Ap-MU; Thu, 29 Nov 2007 17:14:15 -0500 Date: Thu, 29 Nov 2007 17:14:15 -0500 To: "Noveck, Dave" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129221415.GJ23321@fieldses.org> References: <1196369383.20292.19.camel@heimdal.trondhjem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: email2mre-ietf@yahoo.com, 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 Thu, Nov 29, 2007 at 03:57:22PM -0500, Noveck, Dave wrote: > I'm baffled. Forget symlinks (How I wish I could). > > Someone running a non-UTF8 locale issues a remove or open or rename. > You get a string that is not UTF-8. You have an NFSv4 client that sends > requests to a server that expects UTF-8 strings (he sends you > NFS4ERR_INVAL if you send them, just as RFC3530 says he should. I > assume you need to translate them to UTF8 so you can do the required > operation rather than return EINVAL and listen to him scream. How do > you do it? OK, I didn't know that there were OS's that would return different answers to open(path,...) for the same string of bytes "path", depending on the current locale. My guess would be that the chances of that happening in some future version of the Linux kernel are, for all practical purposes, zero. --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 17:16: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 1IxrgY-00005d-7N; Thu, 29 Nov 2007 17:16:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrgX-00005Q-8z for nfsv4@ietf.org; Thu, 29 Nov 2007 17:16:41 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxrgW-0002zS-Ts for nfsv4@ietf.org; Thu, 29 Nov 2007 17:16:41 -0500 X-IronPort-AV: E=Sophos;i="4.23,230,1194249600"; d="scan'208";a="127398509" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 29 Nov 2007 14:16:40 -0800 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 lATMGeUX013011; Thu, 29 Nov 2007 14:16:40 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 14:16:40 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 14:16:39 -0800 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] symlinks: opaque or UTF-8 Date: Thu, 29 Nov 2007 17:16:38 -0500 Message-ID: In-Reply-To: <20071129220850.GE2540@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: Acgy1HNnTp2JL6JpSIemLTmzPOarcgAAKN9g From: "Noveck, Dave" To: "Nicolas Williams" , "Trond Myklebust" X-OriginalArrivalTime: 29 Nov 2007 22:16:39.0543 (UTC) FILETIME=[837C1870:01C832D5] X-Spam-Score: -3.8 (---) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 I'm really thinking of it as pervasive, honest, and I see it affects all my filesystems. But the problem hasn't gone away :-) Maybe I just need to think harder about it being pervasive. However, that could result in me deciding to get into a different line of work :-) -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Thursday, November 29, 2007 5:09 PM To: Trond Myklebust Cc: email2mre-ietf@yahoo.com; Noveck, Dave; nfsv4@ietf.org Subject: Re: [nfsv4] symlinks: opaque or UTF-8 On Thu, Nov 29, 2007 at 04:05:18PM -0500, Trond Myklebust wrote: > The reason why I'm objecting in the particular case of symlinks, is that > symlinks refer to the _client_ namespace. They are inherently > non-portable, because on my machine, I can mount whatever I like, > whereever I like, and that changes the meaning of the symlink. That is > what makes symlinks special, and is why I don't agree with the server > performing any checking whatsoever on the contents. I18N is not specific to NFSv4. You should think of it as pervasive, affecting *all* your filesystems. Then this problem goes away. Nico --=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 Nov 29 17:20: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 1Ixrk2-0000do-3S; Thu, 29 Nov 2007 17:20:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixrk0-0000dF-9C for nfsv4@ietf.org; Thu, 29 Nov 2007 17:20:16 -0500 Received: from web38109.mail.mud.yahoo.com ([209.191.124.136]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ixrjz-0003bF-Sb for nfsv4@ietf.org; Thu, 29 Nov 2007 17:20:16 -0500 Received: (qmail 9287 invoked by uid 60001); 29 Nov 2007 22:20:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=LPrceSXQHpIlecCPrxaUcURx+puFSQX2ye9BnkvcvS9i7USnLgw9Jyh5/l7B0Eyjvu63YQHL2mIppvWLMebALDi7D6k9ZphWILKPUI8FmnbnUHdtrTUKs/9taNHyfKfTrWWl8Dq2yXVTQ2/6yGKI6Ac9W/e0c9LC1/qOjJR/CK4=; X-YMail-OSG: xUND.vIVM1kHT4ycW7TOfdjgxfLpvEg5gMLnjde7cXH0ZkL1PnO6VP0M__PatG5GLb9rYKGThZyp18cso3KCXvPhz.PioH7RxoEH9n3aMvEF5riwMUs- Received: from [198.95.226.230] by web38109.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 14:20:12 PST Date: Thu, 29 Nov 2007 14:20:12 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <992BA60650F1584BA63E339312CE42030C9B8E96@exsvl02.hq.netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <351334.7583.qm@web38109.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Yoder, Alan" wrote: > > I was speaking about file and directory names. > > I disagree with the assertion that symlinks should > be noninteroperable. But if versioning rules won't > let us fix that, I guess there you have it. The outline of a portable symlink would be a symlink create operation that took an explicit array of components, and a readlink operation that returned an explicit array of components, both with an indicate whether the pathname is relative or absolute. E.g., from a Windows client, aa\bb would be conveyed in CREATE as: "aa", "bb" and stored on a UNIX server as: "aa/bb". A client, UNIX or Windows, would get from READLINK "aa", "bb" The client insert the appropriate component separators in the result from the readlink system API. > > Alan > > > -----Original Message----- > > From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no] > > Sent: Thursday, November 29, 2007 1:14 PM > > To: Yoder, Alan > > Cc: Noveck, Dave; email2mre-ietf@yahoo.com; nfsv4@ietf.org > > Subject: RE: [nfsv4] symlinks: opaque or UTF-8 > > > > > > On Thu, 2007-11-29 at 13:09 -0800, Yoder, Alan wrote: > > > I thought it was the client's job to translate > > > non-UTF-8 strings into UTF-8 and back when > > > communicating with the server? A Windows NFS > > > client would certainly have to do this, for > > > example, as their internal format is Unicode. > > > > Why? A Windows symlink would only make sense on that windows > client. > > They don't even use the same pathname separators as UNIX machines > and > > nor do we impose this upon them in the spec. Symlinks are > > non-portable. > > > > 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 Thu Nov 29 17:33: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 1Ixrwa-0003Ze-TD; Thu, 29 Nov 2007 17:33:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxrwZ-0003Z7-Bq for nfsv4@ietf.org; Thu, 29 Nov 2007 17:33:15 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxrwY-00057y-SS for nfsv4@ietf.org; Thu, 29 Nov 2007 17:33:15 -0500 X-IronPort-AV: E=Sophos;i="4.23,230,1194249600"; d="scan'208";a="127402978" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 29 Nov 2007 14:32:51 -0800 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 lATMWown017356; Thu, 29 Nov 2007 14:32:50 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 14:32:50 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 14:32:50 -0800 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] symlinks: opaque or UTF-8 Date: Thu, 29 Nov 2007 17:32:49 -0500 Message-ID: In-Reply-To: <351334.7583.qm@web38109.mail.mud.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: Acgy1gzjr18WO5z6TmCZ3V3A1Tq4EQAAMUIw From: "Noveck, Dave" To: , X-OriginalArrivalTime: 29 Nov 2007 22:32:50.0465 (UTC) FILETIME=[C6330910:01C832D7] X-Spam-Score: 0.2 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 You could have two different object types so that would solve the versioning problem for CREATE. For reading I think READLINK would become mandatory to not implement and a new READPATH would return a flag indicating whether you had the new interoperable type or the old and union would have the appropriate return data for each case. I want it to be clear that I am only speaking of such a thing for v4.x, x >=3D 2. -----Original Message----- From: Mike Eisler [mailto:email2mre-ietf@yahoo.com]=20 Sent: Thursday, November 29, 2007 5:20 PM To: nfsv4@ietf.org Subject: RE: [nfsv4] symlinks: opaque or UTF-8 --- "Yoder, Alan" wrote: >=20 > I was speaking about file and directory names. >=20 > I disagree with the assertion that symlinks should > be noninteroperable. But if versioning rules won't > let us fix that, I guess there you have it. The outline of a portable symlink would be a symlink create operation that took an explicit array of components, and a readlink operation that returned an explicit array of components, both with an indicate whether the pathname is relative or absolute. E.g., from a Windows client, aa\bb would be conveyed in CREATE as: "aa", "bb" and stored on a UNIX server as: "aa/bb". A client, UNIX or Windows, would get from READLINK "aa", "bb" The client insert the appropriate component separators in the result from the readlink system API. >=20 > Alan=20 >=20 > > -----Original Message----- > > From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 > > Sent: Thursday, November 29, 2007 1:14 PM > > To: Yoder, Alan > > Cc: Noveck, Dave; email2mre-ietf@yahoo.com; nfsv4@ietf.org > > Subject: RE: [nfsv4] symlinks: opaque or UTF-8 > >=20 > >=20 > > On Thu, 2007-11-29 at 13:09 -0800, Yoder, Alan wrote: > > > I thought it was the client's job to translate > > > non-UTF-8 strings into UTF-8 and back when > > > communicating with the server? A Windows NFS > > > client would certainly have to do this, for > > > example, as their internal format is Unicode. > >=20 > > Why? A Windows symlink would only make sense on that windows > client. > > They don't even use the same pathname separators as UNIX machines > and > > nor do we impose this upon them in the spec. Symlinks are=20 > > non-portable. > >=20 > > Trond > >=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 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 17:36: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 1Ixrzp-0004om-C7; Thu, 29 Nov 2007 17:36:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixrzo-0004oR-4w for nfsv4@ietf.org; Thu, 29 Nov 2007 17:36:36 -0500 Received: from web38115.mail.mud.yahoo.com ([209.191.124.142]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ixrzn-0007Zd-R5 for nfsv4@ietf.org; Thu, 29 Nov 2007 17:36:36 -0500 Received: (qmail 18106 invoked by uid 60001); 29 Nov 2007 22:36:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=dCVUENuCwyBpxRphvVlModj52Euf7pxI04M+qYQJOJ/fiep26psWok82ST9DG/oGGyUsYbROR6QWFfcBSvqzvbD/OWaYQcSQRku8+A/a2hGP570nHB3OlXpuPBU7Y0FWm1AZSfGw9bhhEFPsIvMS5lxs61vbLiYiRp87T/EDdCU=; X-YMail-OSG: UzaupIcVM1khE9giRmraa9sakkQYwgsueKKuIdE_3uols1Qg1o5KhI_i9KYk.aX5NPoiz7wVBg-- Received: from [198.95.226.230] by web38115.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 14:36:35 PST Date: Thu, 29 Nov 2007 14:36:35 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <430818.18077.qm@web38115.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > I want it to be clear that I am only speaking of such a thing for > v4.x, > x >= 2. Ditto, but given that we are going back to first principles on NFSv4 (UTF-8), might as well think about v4.2 now, because v4.1 has just been thrown a huge monkey wrench. I mean, we've been at this 10 years, and Linux developers waited till *now* to tell us their NFSv4 implementations will never stop sending non-UTF-8? _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From SueduplicableNix@inphotos.org Thu Nov 29 17:39:18 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixs2Q-0006Hi-R6; Thu, 29 Nov 2007 17:39:18 -0500 Received: from [66.184.73.127] (helo=home16aedfd585) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ixs2Q-0006zW-Be; Thu, 29 Nov 2007 17:39:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host58975527.inphotos.org (8.13.1/8.13.1) with SMTP id kJOZ1tf891.156350.j8I.TI7.4745897424156 for ; Thu, 29 Nov 2007 17:39:00 +0500 Message-ID: <365b801c832d8$a9ce1840$0201a8c0@home16aedfd585> From: "Holly Coffman" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_365B4_01C832D8.A9CE1840-- From nfsv4-bounces@ietf.org Thu Nov 29 18:04: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 1IxsQv-0005Nw-G6; Thu, 29 Nov 2007 18:04:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxsQt-0005NI-Um for nfsv4@ietf.org; Thu, 29 Nov 2007 18:04:35 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxsQs-0008WP-UQ for nfsv4@ietf.org; Thu, 29 Nov 2007 18:04:35 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lATN4Y8b014250 for ; Thu, 29 Nov 2007 23:04:34 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lATN4Xuw001816 for ; Thu, 29 Nov 2007 16:04:34 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lATN4UJC003376; Thu, 29 Nov 2007 17:04:30 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lATN4UJq003375; Thu, 29 Nov 2007 17:04:30 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Nov 2007 17:04:30 -0600 From: Nicolas Williams To: "Noveck, Dave" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071129230429.GJ2540@Sun.COM> Mail-Followup-To: "Noveck, Dave" , Trond Myklebust , "Yoder, Alan" , email2mre-ietf@yahoo.com, nfsv4@ietf.org References: <1196370848.20292.29.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: email2mre-ietf@yahoo.com, "Yoder, Alan" , 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 Thu, Nov 29, 2007 at 05:00:06PM -0500, Noveck, Dave wrote: > The spec simply says that the strings are UTF8 at the server interface > (i.e. in the protocol). It doesn't state, whether the responsibilility > to make them so belongs to the client or to the application, although I > always assumed that the client would be doing this translation. That's a local problem. > A widnows client could take a position parallel to Trond's, that it will > not do translation from UCS-2 to UTF-8 and the application should do it. That's insane, but if some OS vendor wants to do that, sure. > The spec has nothing to say about that. I imagine Windows users and > application writers might have a great deal to say about it. And many others too. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 18:22: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 1Ixshh-0005kr-EK; Thu, 29 Nov 2007 18:21:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixshg-0005iM-NJ for nfsv4@ietf.org; Thu, 29 Nov 2007 18:21:56 -0500 Received: from web38101.mail.mud.yahoo.com ([209.191.124.128]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ixshg-0007F1-C4 for nfsv4@ietf.org; Thu, 29 Nov 2007 18:21:56 -0500 Received: (qmail 94822 invoked by uid 60001); 29 Nov 2007 23:21:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=cj4Z4B2a2ZXHXtRy8T28T4NQNT/FFz97RQTHbwA4bJ++q5IHVXLf8g4FxJGx+wpFohlSoC5c41HEuxVZy4YPdM8e3qNkHQB06WAKLXi03XgaiEkfsXokk3tHYnv6ax+sEulczaWD/AinPCltL1EA7gY25zoPoPLljLezUXYit8I=; X-YMail-OSG: 2iR.0OcVM1mrhbT0DM0rOvLFBCfWOooyw2_J4uLqzc.dn33vQk_g8bbw7M2vsZBKkAMTbNRrBQ-- Received: from [198.95.226.230] by web38101.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 15:21:55 PST Date: Thu, 29 Nov 2007 15:21:55 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071129221415.GJ23321@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <790008.94411.qm@web38101.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "J. Bruce Fields" wrote: > OK, I didn't know that there were OS's that would return different > answers to > > open(path,...) > > for the same string of bytes "path", depending on the current locale. > > My guess would be that the chances of that happening in some future > version of the Linux kernel are, for all practical purposes, zero. What exactly did non-English speaking users of Linux do to deserve this kind of treatment? _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 18:46: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 1Ixt5D-0001zI-Vx; Thu, 29 Nov 2007 18:46:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixt5C-0001yZ-K8 for nfsv4@ietf.org; Thu, 29 Nov 2007 18:46:14 -0500 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixt5B-0000E3-Vo for nfsv4@ietf.org; Thu, 29 Nov 2007 18:46:14 -0500 Received: from mail-mx1.uio.no ([129.240.10.29]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Ixt5A-000062-4E; Fri, 30 Nov 2007 00:46:12 +0100 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 1Ixt57-0004jz-NO; Fri, 30 Nov 2007 00:46:09 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ixt57-0004jq-9U; Fri, 30 Nov 2007 00:46:09 +0100 Subject: RE: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Thu, 29 Nov 2007 18:46:07 -0500 Message-Id: <1196379967.20292.96.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.2, required=12.0, autolearn=disabled, AWL=-0.151) X-UiO-Scanned: 686EBC8388A03E79E31ECAED70E45DE29E9C28F5 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -1 maxlevel 200 minaction 2 bait 0 mail/h: 397 total 5470388 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: email2mre-ietf@yahoo.com, "Yoder, Alan" , 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 Thu, 2007-11-29 at 17:00 -0500, Noveck, Dave wrote: > I think you should consider Alan's remarks as relevant to the more > general question of non-symlink pathname components. > > Since you have stated a general (and ostensibly final) position > regarding charracter translation in general, not just for symlinks, I > understood his remarks in that light. > > The spec simply says that the strings are UTF8 at the server interface > (i.e. in the protocol). It doesn't state, whether the responsibilility > to make them so belongs to the client or to the application, although I > always assumed that the client would be doing this translation. > > A widnows client could take a position parallel to Trond's, that it will > not do translation from UCS-2 to UTF-8 and the application should do it. > The spec has nothing to say about that. I imagine Windows users and > application writers might have a great deal to say about it. The problem with having the kernel do the charset conversion is that you have to convert both incoming and outgoing filenames. Consider if I do a readdir() on a directory, and end up with a file containing one or more characters that cannot be translated into the application's charset. Should I return EINVAL knowing that this will make the file invisible to that user? Or should I pass the raw string up to the application, and thus allow it the chance to deal with the problem, for example by displaying a mangled name, that can still be used to open the file when the user clicks on it? In my experience most users would prefer to see some form of representation of the file, even if they cannot display it perfectly rather than have the kernel (or the libc front-end for that matter) just tell them EINVAL. IOW: yes, applications like browsers and "open" dialog boxes etc need to be able to deal with charset conversion issues. It might help if everyone were to get together and state that 'the underlying charset that you use for your syscalls should really be UTF-8'. However the reality is that currently there is no such requirement on the Linux open() interface, and that it is rather late in the day to be talking about making that a hard requirement almost 20 years after the API was defined. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From MelodyindeterminablePadgett@newsweek.com Thu Nov 29 18:55:12 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxtDs-00007D-3o; Thu, 29 Nov 2007 18:55:12 -0500 Received: from c-68-37-155-166.hsd1.nj.comcast.net ([68.37.155.166] helo=familyroom.hsd1.nj.comcast.net) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxtDr-0003vh-QN; Thu, 29 Nov 2007 18:55:12 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host99518619.newsweek.com (8.13.1/8.13.1) with SMTP id XtCfFZrn21.574543.ykR.E9z.7946591273013 for ; Thu, 29 Nov 2007 18:55:04 +0500 Message-ID: <7700601c832e3$4701e290$6501a8c0@Familyroom> From: "Lee Kenney" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_77002_01C832E3.4701E290-- From nfsv4-bounces@ietf.org Thu Nov 29 19:01: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 1IxtKA-0006eb-VU; Thu, 29 Nov 2007 19:01:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxtKA-0006eC-27 for nfsv4@ietf.org; Thu, 29 Nov 2007 19:01:42 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxtK9-00063x-My for nfsv4@ietf.org; Thu, 29 Nov 2007 19:01:41 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAU01elY004128 for ; Fri, 30 Nov 2007 00:01:40 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAU01e2Z042965 for ; Thu, 29 Nov 2007 17:01:40 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAU01esJ003446; Thu, 29 Nov 2007 18:01:40 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAU01d0P003445; Thu, 29 Nov 2007 18:01:39 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Nov 2007 18:01:39 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] UTF-8 or or "just-use-8" Message-ID: <20071130000139.GN2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <1196370318.20292.26.camel@heimdal.trondhjem.org> <651457.94366.qm@web38108.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <651457.94366.qm@web38108.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) 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 Thu, Nov 29, 2007 at 02:13:43PM -0800, Mike Eisler wrote: > Given the market position of the Linux client in the NFS > space, and given that it is going to send non-UTF-8 characters, > NFSv4.x is untenable in non-English-speaking locales. Things change... Give them time. > So I think we should do one of: > > - change the spec to allow the client and server to indicate > to each other that both are using a "just-use-8" model A way to negotiate just-use-8 would be useful, and I think the IETF should allow no-I18N _options_ when it's useful for dealing with vast amounts of legacy content. > - get rid of UTF-8 all together. Absolutely not. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 19:34: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 1IxtoW-0005HS-SD; Thu, 29 Nov 2007 19:33:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxtoV-0005HD-It for nfsv4@ietf.org; Thu, 29 Nov 2007 19:33:03 -0500 Received: from web38110.mail.mud.yahoo.com ([209.191.124.137]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxtoV-00045h-78 for nfsv4@ietf.org; Thu, 29 Nov 2007 19:33:03 -0500 Received: (qmail 50048 invoked by uid 60001); 30 Nov 2007 00:33:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=spWnfKZcgMKxKfpuzwB8Fklo/+F0QvqLoWFHzqeTmBi7oYrb9bpN13i82n23gzTNWKRw4HUbnRVhVnT6dSxsxqE9EJ6jU0m8rjE5Pm6ziCuiwzcZ60rk0Ib6A9N4sDrdSCfqSW+mqtTw9o+zZo0hWO2wEt8lHHw11h9NZQ2ZgyU=; X-YMail-OSG: _GXZK2MVM1lSM5qYMPw2kkyjVYM1Teq5Yp5fz9vhC5b.FF.acoVoXroebZDj9IV8MKTKFZukrA-- Received: from [198.95.226.230] by web38110.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 16:33:02 PST Date: Thu, 29 Nov 2007 16:33:02 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] UTF-8 or or "just-use-8" To: nfsv4@ietf.org In-Reply-To: <20071130000139.GN2540@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <650253.49678.qm@web38110.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Nicolas Williams wrote: > On Thu, Nov 29, 2007 at 02:13:43PM -0800, Mike Eisler wrote: > > Given the market position of the Linux client in the NFS > > space, and given that it is going to send non-UTF-8 characters, > > NFSv4.x is untenable in non-English-speaking locales. > > Things change... Give them time. Since know Linux isn't going change, you are apparently predicting that an NS client on an operating system more friendly to non-English speakers will prevail. Perhaps after I'm dead. > > So I think we should do one of: > > > > - change the spec to allow the client and server to indicate > > to each other that both are using a "just-use-8" model > > A way to negotiate just-use-8 would be useful, and I think the IETF > should allow no-I18N _options_ when it's useful for dealing with vast > amounts of legacy content. Yet in thinking about it, I don't know how useful it would be. A Linux client is going to have no choice but to say: just-use-8 when issuing EXCHANGE_ID, because it has no way to predict if the processes using the client ID will use the UTF-8 locale. A server that assigns locales per fsid will then store the component names if the locale is not UTF-8 > > - get rid of UTF-8 all together. > > Absolutely not. Why? _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 19:52: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 1Ixu5z-0002nV-Qs; Thu, 29 Nov 2007 19:51:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixu5x-0002VP-Sj for nfsv4@ietf.org; Thu, 29 Nov 2007 19:51:05 -0500 Received: from web38107.mail.mud.yahoo.com ([209.191.124.134]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ixu5x-0008Ju-3e for nfsv4@ietf.org; Thu, 29 Nov 2007 19:51:05 -0500 Received: (qmail 53622 invoked by uid 60001); 30 Nov 2007 00:51:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=rtsHfggvQQsspp/WQarREDr26p7bj8VUGBGRdEhaVmy+pPeWK4jiQFIqsnc8nSyFmS5lqFU2JA8DBWChtXEJw7QSs90EunDWG/lHlrihitexoEsuUb7C1FTLdvFLYwRNthb59JJ9bVf+E8ndClTajZaIN65LEyNr0mUhwswB5jM=; X-YMail-OSG: _B0iwugVM1mk1GLNbyPgI2byTA8MCFWoM9ZMNpWxNAW..dvtW9fo6JdGxw_r7Q_xwzTiuAuAzpGtg71ujn4yG9osNZdruPNPNem3FfFClxNpomWHffI- Received: from [198.95.226.230] by web38107.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 16:51:04 PST Date: Thu, 29 Nov 2007 16:51:04 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071129221415.GJ23321@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <769201.53462.qm@web38107.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "J. Bruce Fields" wrote: > On Thu, Nov 29, 2007 at 03:57:22PM -0500, Noveck, Dave wrote: > > I'm baffled. Forget symlinks (How I wish I could). > > > > Someone running a non-UTF8 locale issues a remove or open or > rename. > > You get a string that is not UTF-8. You have an NFSv4 client that > sends > > requests to a server that expects UTF-8 strings (he sends you > > NFS4ERR_INVAL if you send them, just as RFC3530 says he should. I > > assume you need to translate them to UTF8 so you can do the > required > > operation rather than return EINVAL and listen to him scream. How > do > > you do it? > > OK, I didn't know that there were OS's that would return different > answers to > > open(path,...) > > for the same string of bytes "path", depending on the current locale. > > My guess would be that the chances of that happening in some future > version of the Linux kernel are, for all practical purposes, zero. Well it turns out the chances are, for all, practical purposes, 100%, if one is to believe: http://linux.die.net/man/8/smbmount http://linux.die.net/man/8/mount Apparently what Bruce and Trond really meant was, the chances are zero the Linux NFS client and server won't do this. This continues to beg the question: why? _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 20:17: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 1IxuU8-00032I-DV; Thu, 29 Nov 2007 20:16:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxuU6-0002jt-QY for nfsv4@ietf.org; Thu, 29 Nov 2007 20:16:02 -0500 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxuU6-0001I0-Cz for nfsv4@ietf.org; Thu, 29 Nov 2007 20:16:02 -0500 Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IxuU5-0007qS-Oo; Fri, 30 Nov 2007 02:16:01 +0100 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx9.uio.no) by mail-mx9.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IxuU5-0002u7-GN; Fri, 30 Nov 2007 02:16:01 +0100 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx9.uio.no with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IxuU5-0002tu-2p; Fri, 30 Nov 2007 02:16:01 +0100 Subject: Re: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: email2mre-ietf@yahoo.com In-Reply-To: <769201.53462.qm@web38107.mail.mud.yahoo.com> References: <769201.53462.qm@web38107.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 29 Nov 2007 20:15:59 -0500 Message-Id: <1196385359.20292.143.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.3, required=12.0, autolearn=disabled, AWL=-0.313) X-UiO-Scanned: 4AEC8F999994561A596AFAB154073678B6FBEF48 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -2 maxlevel 200 minaction 2 bait 0 mail/h: 69 total 5471020 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Thu, 2007-11-29 at 16:51 -0800, Mike Eisler wrote: > Well it turns out the chances are, for all, practical purposes, 100%, > if one is to believe: > http://linux.die.net/man/8/smbmount > http://linux.die.net/man/8/mount > > Apparently what Bruce and Trond really meant was, the chances are zero > the Linux NFS client and server won't do this. This continues to > beg the question: why? You did read the details of that 'solution', right? How does a mount option help you to figure out which charset the application is using? Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 20:23:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxuZz-0004no-ME; Thu, 29 Nov 2007 20:22:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxuZy-0004ni-Tg for nfsv4@ietf.org; Thu, 29 Nov 2007 20:22:06 -0500 Received: from web38101.mail.mud.yahoo.com ([209.191.124.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxuZy-0006y3-Ea for nfsv4@ietf.org; Thu, 29 Nov 2007 20:22:06 -0500 Received: (qmail 42729 invoked by uid 60001); 30 Nov 2007 01:22:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ZbP9Q7QNfCpPtKZgArdUXRecQnYVbOD21Z93Tna7duVKtQggn6cgL+fgtnQ2rSki+dLWOctN8YnN0PotqPn6Nk+lJlNk0yuoFS7u8zywD3Ee1hRVfpq9SdPBAbc7+E9NCdpBTV3bnqyo2eYgvUAv/DRwjtAXeX5XyU9ZhYb0f10=; X-YMail-OSG: pi.kKWQVM1nSBwEB6ljx5WyKak_cujHvvQcx_wJst6tsyPWYMUCjCpp8QjPhNqj0LoWlup2EyVuN0BZUVkcn1YJ.RLU5osOMDKFnKtybAx_Zo0IrFxQ- Received: from [198.95.226.230] by web38101.mail.mud.yahoo.com via HTTP; Thu, 29 Nov 2007 17:22:05 PST Date: Thu, 29 Nov 2007 17:22:05 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <1196385359.20292.143.camel@heimdal.trondhjem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <948140.42450.qm@web38101.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com 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 Thu, 2007-11-29 at 16:51 -0800, Mike Eisler wrote: > > > Well it turns out the chances are, for all, practical purposes, > 100%, > > if one is to believe: > > http://linux.die.net/man/8/smbmount > > http://linux.die.net/man/8/mount > > > > Apparently what Bruce and Trond really meant was, the chances are > zero > > the Linux NFS client and server won't do this. This continues to > > beg the question: why? > > You did read the details of that 'solution', right? How does a mount > option help you to figure out which charset the application is using? In lieu of a system call in Linux to tell the kernel what charset the process wants to use, a mount option is next best thing. There were at least two file systems on that list that set the charset. If Linux maintainers of core file name processing don't see the trend, then shame on them, but until they "get it", there is a precedent for how the NFS client and server can proceed. > > Trond > > _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From RebaschneiderLedbetter@visitannapolis.org Thu Nov 29 20:28:47 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxugR-0001q6-Ga; Thu, 29 Nov 2007 20:28:47 -0500 Received: from 164-100-20-190.adsl.terra.cl ([190.20.100.164] helo=pc1) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxugQ-0002Na-UN; Thu, 29 Nov 2007 20:28:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host08338821.visitannapolis.org (8.13.1/8.13.1) with SMTP id NYSDqXLu64.148714.Tdw.XSq.8407374368294 for ; Thu, 29 Nov 2007 22:28:16 +0400 Message-ID: <4461301c832f0$5c350ea0$9200a8c0@pc1> From: "Celeste Lay" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_4460F_01C832F0.5C350EA0-- From nfsv4-bounces@ietf.org Thu Nov 29 20:49: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 1Ixuya-00036n-0i; Thu, 29 Nov 2007 20:47:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxuyY-000356-IQ for nfsv4@ietf.org; Thu, 29 Nov 2007 20:47:30 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxuyX-0008Gj-VA for nfsv4@ietf.org; Thu, 29 Nov 2007 20:47:30 -0500 X-IronPort-AV: E=Sophos;i="4.23,231,1194249600"; d="scan'208";a="127452207" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 29 Nov 2007 17:47:29 -0800 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 lAU1lSpH001612; Thu, 29 Nov 2007 17:47:29 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 17:47:29 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 17:47:28 -0800 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] symlinks: opaque or UTF-8 Date: Thu, 29 Nov 2007 20:47:34 -0500 Message-ID: In-Reply-To: <1196379967.20292.96.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: Acgy4ibEpGICDaq8TM6ZvSNlzSGXwAADqReA From: "Noveck, Dave" To: "Trond Myklebust" X-OriginalArrivalTime: 30 Nov 2007 01:47:28.0520 (UTC) FILETIME=[F6DCD080:01C832F2] X-Spam-Score: -3.8 (---) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: email2mre-ietf@yahoo.com, "Yoder, Alan" , 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 > In my experience most users would prefer to see some form of=20 > representation of the file, even if they cannot display it=20 > perfectly rather than have the kernel (or the libc front-end=20 > for that matter) just tell them EINVAL.=20 OK. In my experience, users do not want to present a valid string (for a non-UTF-8 locale) and get EINVAL, simply because the filesystem, which was mounted yesterday as NFSv3 is now mounted as NFSv4. I would find that intolerable and I believe many people would. If you don't think that translation between the current local and UTF-8 can effectively be implemented (as opposed to believing it raises some difficult problems that must be dealt with), then I don't see how you could have agreed with what is in RFC3530, for ordinary path components, not getting into symlinks. Saying that the application should translate to UTF-8 just doesn't fly, as you yourself argue below. It is too late in the game to impose such a restriction, and furthermore translation to UTF-8 is only required on NFSv4. Is the application going to do system calls to determine whether the current fs is NFSv4 and then translate to UTF-8 or not based on the result? There are lots of problems with this stuff, whichever way you turn, and no choice is perfect. But some choices are more and some choices are less evil than others and a choice which forces the applications to be aware of the coding requirements of individual protocols seems to me to be at the more-evil end of the spectrum.=20 -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Thursday, November 29, 2007 6:46 PM To: Noveck, Dave Cc: Yoder, Alan; email2mre-ietf@yahoo.com; nfsv4@ietf.org Subject: RE: [nfsv4] symlinks: opaque or UTF-8 On Thu, 2007-11-29 at 17:00 -0500, Noveck, Dave wrote: > I think you should consider Alan's remarks as relevant to the more=20 > general question of non-symlink pathname components. >=20 > Since you have stated a general (and ostensibly final) position=20 > regarding charracter translation in general, not just for symlinks, I=20 > understood his remarks in that light. >=20 > The spec simply says that the strings are UTF8 at the server interface > (i.e. in the protocol). It doesn't state, whether the=20 > responsibilility to make them so belongs to the client or to the=20 > application, although I always assumed that the client would be doing this translation. >=20 > A widnows client could take a position parallel to Trond's, that it=20 > will not do translation from UCS-2 to UTF-8 and the application should do it. > The spec has nothing to say about that. I imagine Windows users and=20 > application writers might have a great deal to say about it. The problem with having the kernel do the charset conversion is that you have to convert both incoming and outgoing filenames. Consider if I do a readdir() on a directory, and end up with a file containing one or more characters that cannot be translated into the application's charset. Should I return EINVAL knowing that this will make the file invisible to that user? Or should I pass the raw string up to the application, and thus allow it the chance to deal with the problem, for example by displaying a mangled name, that can still be used to open the file when the user clicks on it? In my experience most users would prefer to see some form of representation of the file, even if they cannot display it perfectly rather than have the kernel (or the libc front-end for that matter) just tell them EINVAL. IOW: yes, applications like browsers and "open" dialog boxes etc need to be able to deal with charset conversion issues. It might help if everyone were to get together and state that 'the underlying charset that you use for your syscalls should really be UTF-8'. However the reality is that currently there is no such requirement on the Linux open() interface, and that it is rather late in the day to be talking about making that a hard requirement almost 20 years after the API was defined. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Thu Nov 29 20:56:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixv5e-0006ri-D2; Thu, 29 Nov 2007 20:54:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixv5d-0006rd-53 for nfsv4@ietf.org; Thu, 29 Nov 2007 20:54:49 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixv5b-000054-JT for nfsv4@ietf.org; Thu, 29 Nov 2007 20:54:49 -0500 Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Ixv5b-0002M1-0L; Fri, 30 Nov 2007 02:54:47 +0100 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 1Ixv5a-0000EN-JE; Fri, 30 Nov 2007 02:54:46 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Ixv5a-0000E6-6Y; Fri, 30 Nov 2007 02:54:46 +0100 Subject: Re: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: email2mre-ietf@yahoo.com In-Reply-To: <948140.42450.qm@web38101.mail.mud.yahoo.com> References: <948140.42450.qm@web38101.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 29 Nov 2007 20:54:44 -0500 Message-Id: <1196387684.20292.168.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.3, required=12.0, autolearn=disabled, AWL=-0.308) X-UiO-Scanned: 29A68ED11613B2961F1E6AB624F15D28C22F158D X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -2 maxlevel 200 minaction 2 bait 0 mail/h: 185 total 5471136 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) 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 Thu, 2007-11-29 at 17:22 -0800, Mike Eisler wrote: > In lieu of a system call in Linux to tell the kernel what charset > the process wants to use, a mount option is next best thing. > > There were at least two file systems on that list that set > the charset. If Linux maintainers of core file name processing > don't see the trend, then shame on them, but until they "get it", > there is a precedent for how the NFS client and server can proceed. It is a precedent, but not one that is really useful for much. For one thing the NLS charsets that are defined in the kernel are mainly there for converting between the more common Windows codepages and UTF-8, for ISO8859 charsets, or for koi-8 charsets. It will allow Bruce to export those filesystems that do define a fixed charset (i.e. BeFS, fat, hfs, hfs+, jfs, joliet, and udf) as UTF-8. What it won't help with is exporting those filesystems that don't define a charset (ext[234], gfs2, reiserfs, ocfs2, xfs, .... a.k.a. the filesystems that people actually use). Nor is it sophisticated enough to help Dave achieve Hindu charset compatible nirvana. Finally, it breaks down completely in multi-user scenarios. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 00:58: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 1Ixyte-0008SU-AJ; Fri, 30 Nov 2007 00:58:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixytc-0008SD-UZ for nfsv4@ietf.org; Fri, 30 Nov 2007 00:58:41 -0500 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixytc-0001Cs-ED for nfsv4@ietf.org; Fri, 30 Nov 2007 00:58:40 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAU5wdQ3020283 for ; Fri, 30 Nov 2007 05:58:39 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAU5wdlj002110 for ; Thu, 29 Nov 2007 22:58:39 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAU5wZVn003707; Thu, 29 Nov 2007 23:58:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAU5wZr7003706; Thu, 29 Nov 2007 23:58:35 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 29 Nov 2007 23:58:35 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] UTF-8 or or "just-use-8" Message-ID: <20071130055834.GT2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <20071130000139.GN2540@Sun.COM> <650253.49678.qm@web38110.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <650253.49678.qm@web38110.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Thu, Nov 29, 2007 at 04:33:02PM -0800, Mike Eisler wrote: > > --- Nicolas Williams wrote: > > > On Thu, Nov 29, 2007 at 02:13:43PM -0800, Mike Eisler wrote: > > > Given the market position of the Linux client in the NFS > > > space, and given that it is going to send non-UTF-8 characters, > > > NFSv4.x is untenable in non-English-speaking locales. > > > > Things change... Give them time. > > Since know Linux isn't going change, you are Looks like you missed a pronoun or names. I certainly don't know that Linux isn't going to change. > apparently predicting that an NS client on an > operating system more friendly to non-English > speakers will prevail. Perhaps after I'm dead. You're reading too much into what I write. I'm not even implying such a prediction -- I'm betting that NFSv4.x clients will grow I18N capabilities. > > > So I think we should do one of: > > > > > > - change the spec to allow the client and server to indicate > > > to each other that both are using a "just-use-8" model > > > > A way to negotiate just-use-8 would be useful, and I think the IETF > > should allow no-I18N _options_ when it's useful for dealing with vast > > amounts of legacy content. > > Yet in thinking about it, I don't know how useful it would be. > A Linux client is going to have no choice but to say: just-use-8 > when issuing EXCHANGE_ID, because it has no way to predict if > the processes using the client ID will use the UTF-8 locale. Eventually new versions would be rolled out that do know how and where to do what codeset conversions. I'm an optimist. A just-use-8 negotiation would be useful as a migration strategy, nothing more. > A server that assigns locales per fsid will then store the > component names if the locale is not UTF-8 > > > > - get rid of UTF-8 all together. > > > > Absolutely not. > > Why? Because we need an interoperable way to use internationalized filesystem object names, even if not every implementation implements I18N today, and even if it will take a few more years before all do. That requirement is not going away. Even if you succeeded in yanking out the requirement for use of UTF-8 on the wire, folks would still end up agreeing on its use anyways and would still need interop guidance. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From JackieclimaticPowers@investmentmap.com Fri Nov 30 02:55:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy0iM-0001pM-7N; Fri, 30 Nov 2007 02:55:10 -0500 Received: from 0x57379304.vjnqu1.broadband.tele.dk ([87.55.147.4] helo=acer62a170e25d.opasia.dk) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy0iL-0004G8-9F; Fri, 30 Nov 2007 02:55:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host31025064.investmentmap.com (8.13.1/8.13.1) with SMTP id a4k557zO96.500215.5At.qcQ.2281627641160 for ; Fri, 30 Nov 2007 08:52:40 -0100 Message-ID: <3704d01c83326$4fe683a0$04933757@acer62a170e25d> From: "Shannon Haynes" To: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_37049_01C83326.4FE683A0-- From nfsv4-bounces@ietf.org Fri Nov 30 05:49:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3R7-0006Hx-4v; Fri, 30 Nov 2007 05:49:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3R5-0006HE-VT for nfsv4@ietf.org; Fri, 30 Nov 2007 05:49:32 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy3R5-0004jj-FZ for nfsv4@ietf.org; Fri, 30 Nov 2007 05:49:31 -0500 X-IronPort-AV: E=Sophos;i="4.23,233,1194249600"; d="scan'208";a="127558169" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Nov 2007 02:49:15 -0800 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 lAUAnEU0013026; Fri, 30 Nov 2007 02:49:14 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 02:49:14 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 02:49:13 -0800 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] UTF-8 or or "just-use-8" Date: Fri, 30 Nov 2007 05:49:19 -0500 Message-ID: In-Reply-To: <20071130055834.GT2540@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] UTF-8 or or "just-use-8" Thread-Index: AcgzFlmFbF567IPCRE6fSFPUn+auqwAJ2XxA From: "Noveck, Dave" To: "Nicolas Williams" , "Mike Eisler" X-OriginalArrivalTime: 30 Nov 2007 10:49:13.0675 (UTC) FILETIME=[A571D9B0:01C8333E] X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 Nico is predicting that reason will prevail, eventually. Of course he's right but the history of the past years (agreement to I18N in NFSv4 but with fingers crossed), makes me wonder how far off "eventually" is. Is it in my lifetime? -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Friday, November 30, 2007 12:59 AM To: Mike Eisler Cc: nfsv4@ietf.org Subject: Re: [nfsv4] UTF-8 or or "just-use-8" On Thu, Nov 29, 2007 at 04:33:02PM -0800, Mike Eisler wrote: >=20 > --- Nicolas Williams wrote: >=20 > > On Thu, Nov 29, 2007 at 02:13:43PM -0800, Mike Eisler wrote: > > > Given the market position of the Linux client in the NFS space,=20 > > > and given that it is going to send non-UTF-8 characters, NFSv4.x=20 > > > is untenable in non-English-speaking locales. > >=20 > > Things change... Give them time. >=20 > Since know Linux isn't going change, you are Looks like you missed a pronoun or names. I certainly don't know that Linux isn't going to change. > apparently predicting that an NS client on an operating system more=20 > friendly to non-English speakers will prevail. Perhaps after I'm dead. You're reading too much into what I write. I'm not even implying such a prediction -- I'm betting that NFSv4.x clients will grow I18N capabilities. > > > So I think we should do one of: > > >=20 > > > - change the spec to allow the client and server to indicate > > > to each other that both are using a "just-use-8" model > >=20 > > A way to negotiate just-use-8 would be useful, and I think the IETF=20 > > should allow no-I18N _options_ when it's useful for dealing with=20 > > vast amounts of legacy content. >=20 > Yet in thinking about it, I don't know how useful it would be. > A Linux client is going to have no choice but to say: just-use-8 when=20 > issuing EXCHANGE_ID, because it has no way to predict if the processes > using the client ID will use the UTF-8 locale. Eventually new versions would be rolled out that do know how and where to do what codeset conversions. I'm an optimist. A just-use-8 negotiation would be useful as a migration strategy, nothing more. > A server that assigns locales per fsid will then store the component=20 > names if the locale is not UTF-8 >=20 > > > - get rid of UTF-8 all together. > >=20 > > Absolutely not. >=20 > Why? Because we need an interoperable way to use internationalized filesystem object names, even if not every implementation implements I18N today, and even if it will take a few more years before all do. That requirement is not going away. Even if you succeeded in yanking out the requirement for use of UTF-8 on the wire, folks would still end up agreeing on its use anyways and would still need interop guidance. Nico --=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 DavisinterjectHerring@chinadigitaltimes.net Fri Nov 30 06:02:10 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy3dK-0000Hd-Lo; Fri, 30 Nov 2007 06:02:10 -0500 Received: from pool-70-19-184-183.bos.east.verizon.net ([70.19.184.183] helo=bledsoe4.myhome.westell.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy3dK-0006Ym-5X; Fri, 30 Nov 2007 06:02:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host74179143.chinadigitaltimes.net (8.13.1/8.13.1) with SMTP id 21NlrAM767.814358.EuR.MMD.8649482289588 for ; Fri, 30 Nov 2007 06:01:57 +0500 Message-ID: From: "Coy Leach" To: Subject: Hi Date: Fri, 30 Nov 2007 06:01:57 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_D0ED6_01C83340.74030E60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_D0ED6_01C83340.74030E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Viagra would help you to make = better sex more often and to bring unimaginable plesure to her. Just = disolve half a pill under your tongue and get ready for action in 30 = minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Viagra gives you confidence in any chance, every time. ------=_NextPart_000_D0ED6_01C83340.74030E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_D0ED6_01C83340.74030E60-- From nfsv4-bounces@ietf.org Fri Nov 30 06:28: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 1Iy432-0002iq-9I; Fri, 30 Nov 2007 06:28:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy430-0002Zp-K7 for nfsv4@ietf.org; Fri, 30 Nov 2007 06:28:42 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy430-0000xd-1E for nfsv4@ietf.org; Fri, 30 Nov 2007 06:28:42 -0500 X-IronPort-AV: E=Sophos;i="4.23,233,1194249600"; d="scan'208";a="127565919" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 30 Nov 2007 03:28:26 -0800 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 lAUBSPQs011222; Fri, 30 Nov 2007 03:28:26 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 03:28:25 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 03:28:25 -0800 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] symlinks: opaque or UTF-8 Date: Fri, 30 Nov 2007 06:28:30 -0500 Message-ID: In-Reply-To: <1196387684.20292.168.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: Acgy9ANQHhai7+SnSo+gaMBW43ns4QAS2rjA From: "Noveck, Dave" To: "Trond Myklebust" , X-OriginalArrivalTime: 30 Nov 2007 11:28:25.0268 (UTC) FILETIME=[1F1A7740:01C83344] X-Spam-Score: 0.2 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 > What it won't help with is exporting those filesystems that don't=20 > define a charset (ext[234], gfs2, reiserfs, ocfs2, xfs, .... a.k.a.=20 > the filesystems that people actually use). It would help in allowing non-English-speaking users to obey the NFSv4 protocol when talking to commercial servers that implement the NFSv4 protocol. I'm a somewhat mercenary soul in caring about that, but it is also the case that many users of Linux who have such devices might like help in that regard. > Nor is it sophisticated enough to help Dave achieve Hindu charset=20 > compatible nirvana. Perhaps not, but it can be extended and it doesn't (yet) fall into the category of things that you have sworn never to do, so that is a plus.=20 > Finally, it breaks down completely in multi-user scenarios.=20 Exactly so. In that case you would need to do different sorts of translations for different user processes based on their, how should I put it, locales. When we wrote the requirement into RFC3530 (actually into RFC3010) that path components would be presented by clients in UTF-8 (and that if they didn't they would get NFS4ERR_INVAL and not what they asked for) my expectation was that clients would translate characters presented by those working in different character sets to UTF-8 before sending them to NFSv4 servers to avoid that NFS4ERR_INVAL. But Bruce has indicated that the probability of that being done in Linux is effectively zero and you have gone farther in almost committing yourself never to do such a thing. So when we discussed this issue when the RFC's were being written and subsequently, how did you expect the requirements of the RFC to be met? If you merely transcribe faithfully the data presented across the system call interface then you are doing exactly what was done by NFSv2 and NFSv3 clients and those do not have any such requirement. Did you expect all application writers to sign up for determining when they were connected to NFSv4 and doing appropriate translations? That would not be a reasonable expectation, and I'm assuming you didn't have it. So I need to understand, why we are only hearing about this difficulty now? If the requirement for sending names as UTF-8 is essentially unimplementable within Linux, why didn't we hear much earlier that you didn't think we could support internationalization in NFSv4 and deal with that issue then? -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Thursday, November 29, 2007 8:55 PM To: email2mre-ietf@yahoo.com Cc: nfsv4@ietf.org Subject: Re: [nfsv4] symlinks: opaque or UTF-8 On Thu, 2007-11-29 at 17:22 -0800, Mike Eisler wrote: > In lieu of a system call in Linux to tell the kernel what charset the=20 > process wants to use, a mount option is next best thing. >=20 > There were at least two file systems on that list that set the=20 > charset. If Linux maintainers of core file name processing don't see=20 > the trend, then shame on them, but until they "get it", there is a=20 > precedent for how the NFS client and server can proceed. It is a precedent, but not one that is really useful for much. For one thing the NLS charsets that are defined in the kernel are mainly there for converting between the more common Windows codepages and UTF-8, for ISO8859 charsets, or for koi-8 charsets. It will allow Bruce to export those filesystems that do define a fixed charset (i.e. BeFS, fat, hfs, hfs+, jfs, joliet, and udf) as UTF-8. What it won't help with is exporting those filesystems that don't define a charset (ext[234], gfs2, reiserfs, ocfs2, xfs, .... a.k.a. the filesystems that people actually use). Nor is it sophisticated enough to help Dave achieve Hindu charset compatible nirvana. Finally, it breaks down completely in multi-user scenarios. 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 EarlechooseMayo@ielanguages.com Fri Nov 30 07:22:27 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy4t0-0008BU-UC; Fri, 30 Nov 2007 07:22:26 -0500 Received: from cpe-68-173-180-6.nyc.res.rr.com ([68.173.180.6] helo=ejcpspc.nyc.rr.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy4t0-0007rz-M1; Fri, 30 Nov 2007 07:22:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host55155182.ielanguages.com (8.13.1/8.13.1) with SMTP id p4PG5YKb68.755646.yVE.94y.3592460572998 for ; Fri, 30 Nov 2007 07:22:10 +0500 Message-ID: From: "Abe Mckay" To: Cc: , =20

Even if you have no erection problems = Viagra would=20 help you to make better sex more often and to bring unimaginable = plesure=20 to her. Just disolve half a pill under your tongue and get ready for = action in=20 30 minutes. The tests showed that the majority of men after taking = this=20 medication were able to have perfect erection during 24 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Viagra gives you confidence in any chance, every time.

------=_NextPart_000_E36F1_01C8334B.AAD579E0-- From heidula@saint-seiya.jp Fri Nov 30 07:52:20 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy5Lw-0001GX-Du for nfsv4-archive@lists.ietf.org; Fri, 30 Nov 2007 07:52:20 -0500 Received: from [151.73.174.139] (helo=[151.73.174.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy5Lv-0003X4-TY for nfsv4-archive@lists.ietf.org; Fri, 30 Nov 2007 07:52:20 -0500 Received: by 10.188.198.75 with SMTP id qMRkoSYEJCEpa; Fri, 30 Nov 2007 13:52:23 +0100 (GMT) Received: by 192.168.46.118 with SMTP id VkIgIqLuilcvxC.7414835881429; Fri, 30 Nov 2007 13:52:21 +0100 (GMT) Message-ID: <000e01c8334f$d707ba60$8bae4997@antonellwug40p> From: "heidula Juarez" To: nfsv4-archive@lists.ietf.org Subject: upsrepok Date: Fri, 30 Nov 2007 13:52:18 +0100 Message-ID: <000e01c8334f$d707ba60$8bae4997@antonellwug40p> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 4.6 (++++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Before him I was with a couple of larger men and I did find them more satisfying as I was able to orgasm with them http://mimxmap.com/ From nfsv4-bounces@ietf.org Fri Nov 30 09:55: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 1Iy7HE-0000Qa-JT; Fri, 30 Nov 2007 09:55:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7HC-0000Pf-KR for nfsv4@ietf.org; Fri, 30 Nov 2007 09:55:34 -0500 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy7HC-0004Gw-1z for nfsv4@ietf.org; Fri, 30 Nov 2007 09:55:34 -0500 Received: from mail-mx2.uio.no ([129.240.10.30]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Iy7H9-0001Wi-EG; Fri, 30 Nov 2007 15:55:31 +0100 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 1Iy7H9-0003Y7-2r; Fri, 30 Nov 2007 15:55:31 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Iy7H8-0003Y1-MM; Fri, 30 Nov 2007 15:55:30 +0100 Subject: RE: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Fri, 30 Nov 2007 09:55:28 -0500 Message-Id: <1196434528.8031.9.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.1, required=12.0, autolearn=disabled, AWL=-0.091) X-UiO-Scanned: 08FC867C939A6A133BFC9A48C476682575F7BCFC X-UiO-Ratelimit-Test: Ratelimit X-UiO-SPAM-Test: UIO-RATELIMIT remote_host: 129.240.10.9 spam_score: 0 maxlevel 200 minaction 2 bait 0 mail/h: 1615 total 5487256 max/h 8345 blacklist 0 greylist 0 ratelimit 1 X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Fri, 2007-11-30 at 06:28 -0500, Noveck, Dave wrote: > But Bruce has indicated that the probability of that being done in Linux > is effectively zero and you have gone farther in almost committing > yourself never to do such a thing. So when we discussed this issue when > the RFC's were being written and subsequently, how did you expect the > requirements of the RFC to be met? If you merely transcribe faithfully > the data presented across the system call interface then you are doing > exactly what was done by NFSv2 and NFSv3 clients and those do not have > any such requirement. Did you expect all application writers to sign up > for determining when they were connected to NFSv4 and doing appropriate > translations? That would not be a reasonable expectation, and I'm > assuming you didn't have it. So I need to understand, why we are only > hearing about this difficulty now? If the requirement for sending names > as UTF-8 is essentially unimplementable within Linux, why didn't we hear > much earlier that you didn't think we could support internationalization > in NFSv4 and deal with that issue then? It might be nice if Linux were all about me, and what I promise to do or not do, but it isn't. This issue keeps coming up among the kernel community, and the concensus remains the same. If you want to see some of Linus' ideas on the topic, then here is one example http://article.gmane.org/gmane.linux.kernel/182509 (feel free to read through the entire thread starting at http://thread.gmane.org/gmane.linux.kernel/182053/focus=182478 ) I am not proposing to 'solve' this issue by some kernel hack, because it is current official community policy that this is an application issue. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 10:31:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7q8-0002QE-5E; Fri, 30 Nov 2007 10:31:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7q7-0002Px-6o for nfsv4@ietf.org; Fri, 30 Nov 2007 10:31:39 -0500 Received: from [2002:4519:c427:1:220:edff:fe18:5794] (helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy7q7-0001H2-0H for nfsv4@ietf.org; Fri, 30 Nov 2007 10:31:39 -0500 Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtps (tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50 #1 (Debian)) id 1Iy80k-0000bX-31; Fri, 30 Nov 2007 10:42:39 -0500 Received: from tytso by closure.thunk.org with local (Exim 4.67) (envelope-from ) id 1Iy7ov-0000yl-V9; Fri, 30 Nov 2007 10:30:25 -0500 Date: Fri, 30 Nov 2007 10:30:21 -0500 From: Theodore Tso To: Trond Myklebust Bcc: tytso@mit.edu Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130153021.GB28558@thunk.org> References: <948140.42450.qm@web38101.mail.mud.yahoo.com> <1196387684.20292.168.camel@heimdal.trondhjem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196387684.20292.168.camel@heimdal.trondhjem.org> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Thu, Nov 29, 2007 at 08:54:44PM -0500, Trond Myklebust wrote: > What it won't help with is exporting those filesystems that don't define > a charset (ext[234], gfs2, reiserfs, ocfs2, xfs, .... a.k.a. the > filesystems that people actually use). > Nor is it sophisticated enough to help Dave achieve Hindu charset > compatible nirvana. > > Finally, it breaks down completely in multi-user scenarios. If it is at all helpful, at least for ext[234], when this topic came up last time, the answer was that in multi-user scenario, the only sane answer was UTF-8. If a user wants to use some other charset in the privacy of their own system, that was fine with us, but ext[234] was *not* going to put charset conversion into the kernel. That way lies complete and utter madness, and any OS engineer who needs to do that in the kernel has my sympathies. - Ted _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 11:15: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 1Iy8WM-0005oB-NP; Fri, 30 Nov 2007 11:15:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy8WM-0005o3-3B for nfsv4@ietf.org; Fri, 30 Nov 2007 11:15:18 -0500 Received: from web38107.mail.mud.yahoo.com ([209.191.124.134]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy8WL-0003w8-FA for nfsv4@ietf.org; Fri, 30 Nov 2007 11:15:17 -0500 Received: (qmail 87275 invoked by uid 60001); 30 Nov 2007 16:15:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=GzFoB1o8dHL+hiJcxjVTbqvBNwPrloG4yZEXqTKGyLGKUsby3C77ebN180IbBcbYTODAOUCV7b+2jd0IquW43J7PnlMwAlGRUW9DzAV6xV2+NNAqjXhHnSOsVSKY6vmJjIBsvbvaCCUYc+DftZfufK+TIsrEeRkW03ZNz5u/kpc=; X-YMail-OSG: PhiU8_4VM1lz8W3whZPLj_xaoas6aTFPsEEdPhUrNeLlLA0TpcTi3Sf2Hs6G5_k5D9BAzhMXQCjMl9.nz0a4Ffkn_IHM2PmWRM.AKDsCkjgN7Qts59k- Received: from [198.95.226.230] by web38107.mail.mud.yahoo.com via HTTP; Fri, 30 Nov 2007 08:15:16 PST Date: Fri, 30 Nov 2007 08:15:16 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <1196434528.8031.9.camel@heimdal.trondhjem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <763355.86862.qm@web38107.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Trond Myklebust wrote: > If the requirement for sending > names > > as UTF-8 is essentially unimplementable within Linux, why didn't we > hear > > much earlier that you didn't think we could support > internationalization > > in NFSv4 and deal with that issue then? I don't think Dave's question has been answered. > It might be nice if Linux were all about me, and what I promise to do > or > not do, but it isn't. This issue keeps coming up among the kernel > community, and the concensus remains the same. If you want to see > some > of Linus' ideas on the topic, then here is one example > > http://article.gmane.org/gmane.linux.kernel/182509 > > (feel free to read through the entire thread starting at > http://thread.gmane.org/gmane.linux.kernel/182053/focus=182478 ) No where in that thread did Linus say that because the Linux kernel does not enforce UTF-8 on inputs and outputs to system calls, that file systems in the kernel then had a license to violate the standard they are supposedly limiting. Nor did he say that it it would be an evil thing if those file systems enforced the standard they were implementing. That there are apparently file systems in the Linux kernel that enforce character sets, reinforces this, because presumably he'd have something to say about it when the patch requests were sent in. So blaming God^WLinus doesn't work here (though with statements like: "Think about the simple (hex) string x0A x00. That's a well-defined UTF-8 string," its questionable if he understands UTF-8 :-). Yes it would be nice if he embraced the capability for processes to ask for character set translation and enforcement (even if that one character set was UTF-8), but his lack of support for a general framework does not preclude the NFS client and server in Linux from implementing its own framework (and perhaps sharing code with SMBfs, and other file systems; Ted mentioned that ext had UTF-8 support for example). > I am not proposing to 'solve' this issue by some kernel hack, because > it > is current official community policy that this is an application > issue. Where can I read the official policy documents? _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 11:27:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy8i1-000277-1n; Fri, 30 Nov 2007 11:27:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy8hz-00026h-G3 for nfsv4@ietf.org; Fri, 30 Nov 2007 11:27:19 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy8hz-0007ax-2k for nfsv4@ietf.org; Fri, 30 Nov 2007 11:27:19 -0500 X-IronPort-AV: E=Sophos;i="4.23,235,1194249600"; d="scan'208";a="127649057" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Nov 2007 08:27:15 -0800 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 lAUGRAAZ006790; Fri, 30 Nov 2007 08:27:11 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 08:27:10 -0800 Received: from exsvl02.hq.netapp.com ([10.56.8.60]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 08:27:10 -0800 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] symlinks: opaque or UTF-8 Date: Fri, 30 Nov 2007 08:27:09 -0800 Message-ID: <992BA60650F1584BA63E339312CE42030C9B9065@exsvl02.hq.netapp.com> In-Reply-To: <20071130153021.GB28558@thunk.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgzZoN3d0xhdsqlSLa4jufliXTU9AABZSQA From: "Yoder, Alan" To: "Theodore Tso" , "Trond Myklebust" X-OriginalArrivalTime: 30 Nov 2007 16:27:10.0337 (UTC) FILETIME=[DB46EF10:01C8336D] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Gas on the fire... There are numerous systems out there that already have to do charset translation, and that do it with varying degrees of excellence or suckage. =20 Netapp's product, EMC's Celerra and Samba all come=20 to mind. There are at least several others that I don't know well (HDS, ProComm etc.). These are all server-side products, interestingly. Alan > -----Original Message----- > From: Theodore Tso [mailto:tytso@mit.edu]=20 > Sent: Friday, November 30, 2007 7:30 AM > To: Trond Myklebust > Cc: email2mre-ietf@yahoo.com; nfsv4@ietf.org > Subject: Re: [nfsv4] symlinks: opaque or UTF-8 >=20 > On Thu, Nov 29, 2007 at 08:54:44PM -0500, Trond Myklebust wrote: > > What it won't help with is exporting those filesystems that=20 > don't define > > a charset (ext[234], gfs2, reiserfs, ocfs2, xfs, .... a.k.a. the > > filesystems that people actually use). > > Nor is it sophisticated enough to help Dave achieve Hindu charset > > compatible nirvana. > >=20 > > Finally, it breaks down completely in multi-user scenarios. >=20 > If it is at all helpful, at least for ext[234], when this topic came > up last time, the answer was that in multi-user scenario, the only > sane answer was UTF-8. If a user wants to use some other charset in > the privacy of their own system, that was fine with us, but ext[234] > was *not* going to put charset conversion into the kernel. That way > lies complete and utter madness, and any OS engineer who needs to do > that in the kernel has my sympathies. >=20 > - Ted >=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 Fri Nov 30 11:34: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 1Iy8oT-0005sd-SB; Fri, 30 Nov 2007 11:34:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy8oS-0005sK-QH for nfsv4@ietf.org; Fri, 30 Nov 2007 11:34:00 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy8oQ-0003pG-R2 for nfsv4@ietf.org; Fri, 30 Nov 2007 11:34:00 -0500 Received: from mail-mx3.uio.no ([129.240.10.44]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Iy8oQ-0003CA-3Q; Fri, 30 Nov 2007 17:33:58 +0100 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 1Iy8oN-0003Ib-GF; Fri, 30 Nov 2007 17:33:55 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Iy8oN-0003IM-1v; Fri, 30 Nov 2007 17:33:55 +0100 Subject: RE: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: email2mre-ietf@yahoo.com In-Reply-To: <763355.86862.qm@web38107.mail.mud.yahoo.com> References: <763355.86862.qm@web38107.mail.mud.yahoo.com> Content-Type: text/plain Date: Fri, 30 Nov 2007 11:33:53 -0500 Message-Id: <1196440433.8031.44.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.2, required=12.0, autolearn=disabled, AWL=-0.228) X-UiO-Scanned: 4899AADEA6A9EC1A557DAC5284A7385CA2227DAF X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -1 maxlevel 200 minaction 2 bait 0 mail/h: 570 total 5489157 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Fri, 2007-11-30 at 08:15 -0800, Mike Eisler wrote: > --- Trond Myklebust wrote: > > > If the requirement for sending > > names > > > as UTF-8 is essentially unimplementable within Linux, why didn't we > > hear > > > much earlier that you didn't think we could support > > internationalization > > > in NFSv4 and deal with that issue then? > > I don't think Dave's question has been answered. I've never been on record as stating that our client would perform utf-8 conversions, nor have I ever agreed to doing so. The RFC states that servers expect it, which is fine by me, but I've never planned on doing charset conversion in the kernel on behalf of applications. > > It might be nice if Linux were all about me, and what I promise to > do > > or > > not do, but it isn't. This issue keeps coming up among the kernel > > community, and the concensus remains the same. If you want to see > > some > > of Linus' ideas on the topic, then here is one example > > > > http://article.gmane.org/gmane.linux.kernel/182509 > > > > (feel free to read through the entire thread starting at > > http://thread.gmane.org/gmane.linux.kernel/182053/focus=182478 ) > > No where in that thread did Linus say that because the Linux kernel > does not enforce UTF-8 on inputs and outputs to system calls, that > file systems in the kernel then had a license to violate the > standard they are supposedly limiting. Nor did he say that > it it would be an evil thing if those file systems enforced the > standard they were implementing. That there are apparently file > systems > in the Linux kernel that enforce character sets, reinforces this, > because presumably he'd have something to say about it when the patch > requests were sent in. > > So blaming God^WLinus doesn't work here (though with statements like: > "Think about the simple (hex) string x0A x00. That's a well-defined > UTF-8 string," its questionable if he understands UTF-8 :-). > > Yes it would be nice if he embraced the capability for processes > to ask for character set translation and enforcement (even > if that one character set was UTF-8), but his lack of > support for a general framework does not preclude the NFS client > and server in Linux from implementing its own framework (and > perhaps sharing code with SMBfs, and other file systems; Ted > mentioned that ext had UTF-8 support for example). That is not going to happen. We will not do charset conversion on behalf of applications. > > I am not proposing to 'solve' this issue by some kernel hack, because > > it > > is current official community policy that this is an application > > issue. > > Where can I read the official policy documents? The mailing lists are pretty much all there is. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 12:02: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 1Iy9FZ-00088O-PR; Fri, 30 Nov 2007 12:02:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9FY-00084K-Dn for nfsv4@ietf.org; Fri, 30 Nov 2007 12:02:00 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy9FX-00036M-O6 for nfsv4@ietf.org; Fri, 30 Nov 2007 12:02:00 -0500 X-IronPort-AV: E=Sophos;i="4.23,235,1194249600"; d="scan'208";a="127662269" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Nov 2007 09:01:58 -0800 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 lAUH1MJD021370; Fri, 30 Nov 2007 09:01:56 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 09:01:45 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 09:01:45 -0800 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] symlinks: opaque or UTF-8 Date: Fri, 30 Nov 2007 12:01:44 -0500 Message-ID: In-Reply-To: <1196434528.8031.9.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgzYSQrop0pzKP/TWe4xw6eohDL/gAEYe7Q From: "Noveck, Dave" To: "Trond Myklebust" X-OriginalArrivalTime: 30 Nov 2007 17:01:45.0602 (UTC) FILETIME=[B03B3E20:01C83372] X-Spam-Score: -3.8 (---) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 > It might be nice if Linux were all about me, and what I promise to do or > not do, but it isn't. So are you saying, in response to my question, that when you agreed, or at least didn't disagree with the NFSv4 internationalization strategy, you thought Linus could be brought around, but have since found out otherwise? That's not an answer I like (in the sense it the implications for NFSv4 are not so great) but at least its an answer. I'm not that pleased that it took a discussion of symlinks to bring this fact out. I would have hoped that you could have brought the issue to the working group's attention as soon as the problem surfaced. The document you cite is from early 2004. > Choice is _inherently_ good.=20 I agree but we have a situation in which NFSv4 cannot choose a UTF-8 internationalization strategy and have Linux client implementations conform to it, which seems to me to indicate that something is amiss. It seems that some of the implementation-specifics intended to enable choice, have quite the opposite effect. > Trying to force a world-view is bad. Which is kind of strange when spoken by someone who is (apparently successfully) imposing his world-view on NFSv4. It's not as if he doesn't have a right to have his own world-view and to fight tenaciously for it. What I object to is the ex-post-facto aspect and its effect on NFSv4. I think we've been blind-sided, and our work has been unfairly interfered with and hearing about how this is all in the interests of freedom is a bit much. -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Friday, November 30, 2007 9:55 AM To: Noveck, Dave Cc: email2mre-ietf@yahoo.com; nfsv4@ietf.org Subject: RE: [nfsv4] symlinks: opaque or UTF-8 On Fri, 2007-11-30 at 06:28 -0500, Noveck, Dave wrote: > But Bruce has indicated that the probability of that being done in Linux > is effectively zero and you have gone farther in almost committing > yourself never to do such a thing. So when we discussed this issue when > the RFC's were being written and subsequently, how did you expect the > requirements of the RFC to be met? If you merely transcribe faithfully > the data presented across the system call interface then you are doing > exactly what was done by NFSv2 and NFSv3 clients and those do not have > any such requirement. Did you expect all application writers to sign up > for determining when they were connected to NFSv4 and doing appropriate > translations? That would not be a reasonable expectation, and I'm > assuming you didn't have it. So I need to understand, why we are only > hearing about this difficulty now? If the requirement for sending names > as UTF-8 is essentially unimplementable within Linux, why didn't we hear > much earlier that you didn't think we could support internationalization > in NFSv4 and deal with that issue then? It might be nice if Linux were all about me, and what I promise to do or not do, but it isn't. This issue keeps coming up among the kernel community, and the concensus remains the same. If you want to see some of Linus' ideas on the topic, then here is one example http://article.gmane.org/gmane.linux.kernel/182509 (feel free to read through the entire thread starting at http://thread.gmane.org/gmane.linux.kernel/182053/focus=3D182478 ) I am not proposing to 'solve' this issue by some kernel hack, because it is current official community policy that this is an application issue. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 12:04: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 1Iy9HX-0003IH-Fd; Fri, 30 Nov 2007 12:04:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9HV-00030O-PI for nfsv4@ietf.org; Fri, 30 Nov 2007 12:04:01 -0500 Received: from pat.uio.no ([129.240.10.15]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy9HV-0000zL-CA for nfsv4@ietf.org; Fri, 30 Nov 2007 12:04:01 -0500 Received: from mail-mx6.uio.no ([129.240.10.47]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Iy9HU-00083P-SB; Fri, 30 Nov 2007 18:04:00 +0100 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 1Iy9HS-0006ph-E9; Fri, 30 Nov 2007 18:03:58 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Iy9HS-0006pZ-1C; Fri, 30 Nov 2007 18:03:58 +0100 Subject: RE: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: email2mre-ietf@yahoo.com In-Reply-To: <763355.86862.qm@web38107.mail.mud.yahoo.com> References: <763355.86862.qm@web38107.mail.mud.yahoo.com> Content-Type: text/plain Date: Fri, 30 Nov 2007 12:03:56 -0500 Message-Id: <1196442236.8031.65.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.3, required=12.0, autolearn=disabled, AWL=-0.312) X-UiO-Scanned: D7988A9C7F2FAB0E06BF8CE17C028D01C47B9A30 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -2 maxlevel 200 minaction 2 bait 0 mail/h: 43 total 5489567 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Fri, 2007-11-30 at 08:15 -0800, Mike Eisler wrote: > Ted > mentioned that ext had UTF-8 support for example). BTW: Please read what Ted said. He said that UTF-8 was supported, but he didn't say that the kernel would reject any non UTF-8 characters nor did he say that the kernel would convert non UTF-8 characters. In fact, he explicitly told you that idea had been rejected by the developers. I agree that UTF-8 makes most sense for portability. Most Linux distributions today default to UTF-8 based locales, so filename conversion should normally not be needed. Should, however, a user choose to use a non UTF-8 locale, then the Linux client will put that filename unchanged on the wire, and it will be up to the server to decide what to do. The Linux server will currently pass that string unchanged to the filesystem, which again ensures that all legacy filesystems can be exported without requiring any special conversion. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 12:04: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 1Iy9IG-0004wa-8j; Fri, 30 Nov 2007 12:04:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9IF-0004w8-9t for nfsv4@ietf.org; Fri, 30 Nov 2007 12:04:47 -0500 Received: from web38115.mail.mud.yahoo.com ([209.191.124.142]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iy9IE-0001C8-O4 for nfsv4@ietf.org; Fri, 30 Nov 2007 12:04:47 -0500 Received: (qmail 37927 invoked by uid 60001); 30 Nov 2007 17:04:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=UD5EG+3wfIkceF4g3vA0UPFQJJRpwDSUKcIp309LzTdlnYRd490M9NaOEW9rmFdJ1d9uDRwaCEDzKZzXmyJ/LtXOSkiqu6PPCy0c4OKhtxlLMLusHoleIaxfP9v0rtSMnnmVc0oQUiGxXrppJTK4kqFsEqnw5mBEz9w0wuepXmg=; X-YMail-OSG: kNtfhJkVM1klBdbdrBp0N58_UOxkvLPIaqq7qI6hUl4xl8L8gFvOPveL.RU5PHtJTpUHAVwjOQKfhd.vB7YfVgBvAgsFqHrO1B8cjyGGY3fxfhgPyLM- Received: from [198.95.226.230] by web38115.mail.mud.yahoo.com via HTTP; Fri, 30 Nov 2007 09:04:46 PST Date: Fri, 30 Nov 2007 09:04:46 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <1196440433.8031.44.camel@heimdal.trondhjem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <104297.37433.qm@web38115.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com 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 Fri, 2007-11-30 at 08:15 -0800, Mike Eisler wrote: > > --- Trond Myklebust wrote: > > > > > If the requirement for sending > > > names > > > > as UTF-8 is essentially unimplementable within Linux, why > didn't we > > > hear > > > > much earlier that you didn't think we could support > > > internationalization > > > > in NFSv4 and deal with that issue then? > > > > I don't think Dave's question has been answered. > > I've never been on record as stating that our client would perform > utf-8 > conversions, nor have I ever agreed to doing so. The RFC states that > servers expect it, which is fine by me, but I've never planned on > doing > charset conversion in the kernel on behalf of applications. Well this would have been good to know in 2002. If there's anything else in v4.0 or v4.1 you won't be complying with, especially stuff that causes the NFSv4.[01] server to return unrecoverable errors, now would be a good time to know. > > > > It might be nice if Linux were all about me, and what I promise > to > > do > > > or > > > not do, but it isn't. This issue keeps coming up among the kernel > > > community, and the concensus remains the same. If you want to see > > > some > > > of Linus' ideas on the topic, then here is one example > > > > > > http://article.gmane.org/gmane.linux.kernel/182509 > > > > > > (feel free to read through the entire thread starting at > > > http://thread.gmane.org/gmane.linux.kernel/182053/focus=182478 ) > > > > No where in that thread did Linus say that because the Linux kernel > > > does not enforce UTF-8 on inputs and outputs to system calls, that > > file systems in the kernel then had a license to violate the > > standard they are supposedly limiting. Nor did he say that > > it it would be an evil thing if those file systems enforced the > > standard they were implementing. That there are apparently file > > systems > > in the Linux kernel that enforce character sets, reinforces this, > > because presumably he'd have something to say about it when the > patch > > requests were sent in. > > > > So blaming God^WLinus doesn't work here (though with statements > like: > > "Think about the simple (hex) string x0A x00. That's a well-defined > > UTF-8 string," its questionable if he understands UTF-8 :-). > > > > Yes it would be nice if he embraced the capability for processes > > to ask for character set translation and enforcement (even > > if that one character set was UTF-8), but his lack of > > support for a general framework does not preclude the NFS client > > and server in Linux from implementing its own framework (and > > perhaps sharing code with SMBfs, and other file systems; Ted > > mentioned that ext had UTF-8 support for example). > > That is not going to happen. We will not do charset conversion on > behalf > of applications. Please state it more plainly: "We will send non-UTF-8 to NFSv4.x servers, so tough [expletive optional]." All: I recommend we remove UTF-8 from NFSv4.1. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 12:20: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 1Iy9X8-00045e-T2; Fri, 30 Nov 2007 12:20:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9X8-00045J-2c for nfsv4@ietf.org; Fri, 30 Nov 2007 12:20:10 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy9X7-0007S4-Ia for nfsv4@ietf.org; Fri, 30 Nov 2007 12:20:10 -0500 Received: from mail-mx9.uio.no ([129.240.10.39]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Iy9X5-0006tw-TU; Fri, 30 Nov 2007 18:20:07 +0100 Received: from smtp.uio.no ([129.240.10.9] helo=mail-mx9.uio.no) by mail-mx9.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1Iy9X5-0005yo-H7; Fri, 30 Nov 2007 18:20:07 +0100 Received: from c-69-242-210-120.hsd1.mi.comcast.net ([69.242.210.120] helo=[192.168.0.101]) by mail-mx9.uio.no with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Iy9X5-0005yX-3z; Fri, 30 Nov 2007 18:20:07 +0100 Subject: RE: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Fri, 30 Nov 2007 12:20:05 -0500 Message-Id: <1196443205.8031.80.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.3, required=12.0, autolearn=disabled, AWL=-0.331) X-UiO-Scanned: B50AD67D9E0FBCC0F0DB598379ED274EDA5B897F X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -2 maxlevel 200 minaction 2 bait 0 mail/h: 237 total 5489761 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Fri, 2007-11-30 at 12:01 -0500, Noveck, Dave wrote: > > It might be nice if Linux were all about me, and what I promise to do > or > > not do, but it isn't. > > So are you saying, in response to my question, that when you agreed, or > at least didn't disagree with the NFSv4 internationalization strategy, > you thought Linus could be brought around, but have since found out > otherwise? The UTF-8 requirement was apparently decided well before I got involved with NFSv4: it is already part of RFC3010, which dates from December 2000. I was never consulted on that issue, and have never been told that there was some implicit assumption that client kernels would perform special conversions on behalf of applications. The reason why I never raised an issue is because I knew that the Linux namespace rules are compatible with UTF-8, by which I mean that there are no UTF-8 strings that will be misparsed by the VFS pathname interpreter. If the server wishes to restrict itself to UTF-8 only, then that will certainly break some userspace applications, but that is not a problem for the kernel to solve. > That's not an answer I like (in the sense it the > implications for NFSv4 are not so great) but at least its an answer. > I'm not that pleased that it took a discussion of symlinks to bring this > fact out. I would have hoped that you could have brought the issue to > the working group's attention as soon as the problem surfaced. The > document you cite is from early 2004. There have been earlier discussions too, but I preferred to quote the most recent one I can find. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 12:22: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 1Iy9Zl-00077h-GP; Fri, 30 Nov 2007 12:22:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9Zk-00070N-II for nfsv4@ietf.org; Fri, 30 Nov 2007 12:22:52 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy9Zk-0008Gl-9J for nfsv4@ietf.org; Fri, 30 Nov 2007 12:22:52 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUHMpeJ019654 for ; Fri, 30 Nov 2007 17:22:52 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUHMpR4024941 for ; Fri, 30 Nov 2007 10:22:51 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUHMplI003888; Fri, 30 Nov 2007 11:22:51 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUHMpZj003887; Fri, 30 Nov 2007 11:22:51 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 11:22:51 -0600 From: Nicolas Williams To: "Noveck, Dave" Subject: Re: [nfsv4] UTF-8 or or "just-use-8" Message-ID: <20071130172250.GW2540@Sun.COM> Mail-Followup-To: "Noveck, Dave" , Mike Eisler , nfsv4@ietf.org References: <20071130055834.GT2540@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Mike Eisler , 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 Fri, Nov 30, 2007 at 05:49:19AM -0500, Noveck, Dave wrote: > Nico is predicting that reason will prevail, eventually. > > Of course he's right but the history of the past years (agreement to > I18N in NFSv4 but with fingers crossed), makes me wonder how far off > "eventually" is. Is it in my lifetime? I think it may even be around the corner, in IETF time :^) _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 12:33: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 1Iy9jp-0001dr-06; Fri, 30 Nov 2007 12:33:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9jl-0001cU-Jx for nfsv4@ietf.org; Fri, 30 Nov 2007 12:33:13 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy9jl-0002aB-5p for nfsv4@ietf.org; Fri, 30 Nov 2007 12:33:13 -0500 X-IronPort-AV: E=Sophos;i="4.23,235,1194249600"; d="scan'208";a="127673777" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 30 Nov 2007 09:33:10 -0800 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 lAUHXAU0004163; Fri, 30 Nov 2007 09:33:10 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 09:33:10 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 09:33:09 -0800 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] symlinks: opaque or UTF-8 Date: Fri, 30 Nov 2007 12:33:08 -0500 Message-ID: In-Reply-To: <1196442236.8031.65.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgzcwjeK0jOO5h+QBmLQY/+Q1hDEQAAwbIQ From: "Noveck, Dave" To: "Trond Myklebust" , X-OriginalArrivalTime: 30 Nov 2007 17:33:09.0556 (UTC) FILETIME=[1327CF40:01C83377] X-Spam-Score: -3.8 (---) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 > Should, however, a user choose to use a non UTF-8 locale, then the Linux > client will put that filename unchanged on the wire, and it will be up > to the server to decide what to do.=20 Indeed. It can either choose to conform to the protocol and return NFS4ERR_INVAL or it can choose to do something else and not confrom to the protocol. > The Linux server will currently pass > that string unchanged to the filesystem, which again ensures that all > legacy filesystems can be exported without requiring any special > conversion. In other words, the Linux NFSv4 client and the Linux NFSv4 server both treat path components just as they were treated in NFSv3. They are interoperable, with each other, but not, in non-UTF-8 locales, with servers that implement the protocol specified in RFC3530. Further, there is a fixed determination, not to treat this interoperability issue as a problem and thereby confrom to the protocol. At least we know this now. -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Friday, November 30, 2007 12:04 PM To: email2mre-ietf@yahoo.com Cc: nfsv4@ietf.org Subject: RE: [nfsv4] symlinks: opaque or UTF-8 On Fri, 2007-11-30 at 08:15 -0800, Mike Eisler wrote: > Ted > mentioned that ext had UTF-8 support for example). BTW: Please read what Ted said. He said that UTF-8 was supported, but he didn't say that the kernel would reject any non UTF-8 characters nor did he say that the kernel would convert non UTF-8 characters. In fact, he explicitly told you that idea had been rejected by the developers. I agree that UTF-8 makes most sense for portability. Most Linux distributions today default to UTF-8 based locales, so filename conversion should normally not be needed. Should, however, a user choose to use a non UTF-8 locale, then the Linux client will put that filename unchanged on the wire, and it will be up to the server to decide what to do. The Linux server will currently pass that string unchanged to the filesystem, which again ensures that all legacy filesystems can be exported without requiring any special conversion. 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 Fri Nov 30 12:36: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 1Iy9nL-000245-3d; Fri, 30 Nov 2007 12:36:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9nK-00023i-3r for nfsv4@ietf.org; Fri, 30 Nov 2007 12:36:54 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy9nI-0003ZQ-NZ for nfsv4@ietf.org; Fri, 30 Nov 2007 12:36:54 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUHaqk4004053 for ; Fri, 30 Nov 2007 17:36:52 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUHappL034725 for ; Fri, 30 Nov 2007 10:36:52 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUHapnN003922; Fri, 30 Nov 2007 11:36:51 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUHapWD003921; Fri, 30 Nov 2007 11:36:51 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 11:36:51 -0600 From: Nicolas Williams To: Trond Myklebust Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130173650.GA2540@Sun.COM> Mail-Followup-To: Trond Myklebust , "Noveck, Dave" , email2mre-ietf@yahoo.com, nfsv4@ietf.org References: <1196434528.8031.9.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196434528.8031.9.camel@heimdal.trondhjem.org> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: email2mre-ietf@yahoo.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 On Fri, Nov 30, 2007 at 09:55:28AM -0500, Trond Myklebust wrote: > It might be nice if Linux were all about me, and what I promise to do or > not do, but it isn't. This issue keeps coming up among the kernel > community, and the concensus remains the same. If you want to see some > of Linus' ideas on the topic, then here is one example I you go with the UTF-8-in-the-middle approach then you can push the conversions to the edge, namely [g]libc syscall stubs and filesystem modules, thus neatly bypassing kernel architecture issues. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 12:49:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9zC-0004Nl-E2; Fri, 30 Nov 2007 12:49:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9zB-0004NB-18 for nfsv4@ietf.org; Fri, 30 Nov 2007 12:49:09 -0500 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy9z8-0006xF-PD for nfsv4@ietf.org; Fri, 30 Nov 2007 12:49:09 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUHn5JO025952 for ; Fri, 30 Nov 2007 17:49:05 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUHn4YK042620 for ; Fri, 30 Nov 2007 10:49:05 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUHn4lW003931; Fri, 30 Nov 2007 11:49:04 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUHn47T003930; Fri, 30 Nov 2007 11:49:04 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 11:49:04 -0600 From: Nicolas Williams To: Theodore Tso Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130174903.GB2540@Sun.COM> Mail-Followup-To: Theodore Tso , Trond Myklebust , email2mre-ietf@yahoo.com, nfsv4@ietf.org References: <948140.42450.qm@web38101.mail.mud.yahoo.com> <1196387684.20292.168.camel@heimdal.trondhjem.org> <20071130153021.GB28558@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071130153021.GB28558@thunk.org> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: email2mre-ietf@yahoo.com, 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 Fri, Nov 30, 2007 at 10:30:21AM -0500, Theodore Tso wrote: > > Finally, it breaks down completely in multi-user scenarios. > > If it is at all helpful, at least for ext[234], when this topic came > up last time, the answer was that in multi-user scenario, the only > sane answer was UTF-8. If a user wants to use some other charset in > the privacy of their own system, that was fine with us, but ext[234] > was *not* going to put charset conversion into the kernel. That way > lies complete and utter madness, and any OS engineer who needs to do > that in the kernel has my sympathies. The easiest thing to do is to push codeset/encoding conversions to the edge and use UTF-8 by convention in the middle. On the filesystem edge very few filesystms should have to do any conversions (e.g., an NTFS module would have to do UTF-8<->UTF-16 conversions, and some filesystems might have options for dealing with legacy to convert to non-Unicode codesets, like ISO-8859-*). The other edge of the middle is the system call stubs in user-land, where knowledge of the current locale's codeset is available. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 12:56: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 1IyA6K-0002rx-UQ; Fri, 30 Nov 2007 12:56:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyA6K-0002ri-AA for nfsv4@ietf.org; Fri, 30 Nov 2007 12:56:32 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyA6J-0006NS-TC for nfsv4@ietf.org; Fri, 30 Nov 2007 12:56:32 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUHuUcs029871 for ; Fri, 30 Nov 2007 17:56:30 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUHuUU6048063 for ; Fri, 30 Nov 2007 10:56:30 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUHuUn7003941; Fri, 30 Nov 2007 11:56:30 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUHuUmV003940; Fri, 30 Nov 2007 11:56:30 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 11:56:30 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130175629.GC2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <1196440433.8031.44.camel@heimdal.trondhjem.org> <104297.37433.qm@web38115.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <104297.37433.qm@web38115.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) 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 On Fri, Nov 30, 2007 at 09:04:46AM -0800, Mike Eisler wrote: > --- Trond Myklebust wrote: > > > Yes it would be nice if he embraced the capability for processes > > > to ask for character set translation and enforcement (even > > > if that one character set was UTF-8), but his lack of > > > support for a general framework does not preclude the NFS client > > > and server in Linux from implementing its own framework (and > > > perhaps sharing code with SMBfs, and other file systems; Ted > > > mentioned that ext had UTF-8 support for example). > > > > That is not going to happen. We will not do charset conversion on > > behalf of applications. > > Please state it more plainly: > > "We will send non-UTF-8 to NFSv4.x servers, so tough [expletive > optional]." It's completely agreeable that his client won't do the necessary conversions -- those belong elsewhere in the system. > All: I recommend we remove UTF-8 from NFSv4.1. No. That'd be overreacting. We may need more flexibility in the protocol to deal with legacy content (client: "hi, do you have non-UTF-8 content in this ? I want to be able to warn my users about that or even disallow them access", server: "yes I do" or "yes I do, use ISO-8859-15" or "yes I do, sorry, but new content must be UTF-8" or "no I don't and don't accept non-UTF-8 content"). But giving up on I18N won't do for the reasons that I described earlier. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 13: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 1IyAJO-0000nt-JW; Fri, 30 Nov 2007 13:10:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAJN-0000nF-R4 for nfsv4@ietf.org; Fri, 30 Nov 2007 13:10:01 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyAJN-0001p7-Aw for nfsv4@ietf.org; Fri, 30 Nov 2007 13:10:01 -0500 X-IronPort-AV: E=Sophos;i="4.23,235,1194249600"; d="scan'208";a="127687428" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Nov 2007 10:09:28 -0800 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 lAUI8EZd017462; Fri, 30 Nov 2007 10:08:38 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 10:08:14 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 10:08:14 -0800 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] symlinks: opaque or UTF-8 Date: Fri, 30 Nov 2007 13:08:12 -0500 Message-ID: In-Reply-To: <20071130174903.GB2540@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgzeZr14LpxViq3Qhm58OfjXsmR1QAANiQQ From: "Noveck, Dave" To: "Nicolas Williams" , "Theodore Tso" X-OriginalArrivalTime: 30 Nov 2007 18:08:14.0362 (UTC) FILETIME=[F9B7B7A0:01C8337B] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: email2mre-ietf@yahoo.com, 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 Yes this can be done, and if it is important for some reason, political, technical or otherwise, to keep it outside the kernel, then I imagine that need can be accommodated. The issue I see is that however you do this, this is a lot of work, and I don't sense a willingness to undertake that work, just because the internationalization requirements in RFC3530 together with the needs of non-English-speaking users of Linux, make it necessary (my opinion). We hear a lot about what will not be done, ever. What we don't hear is any understanding of the fundamental problem, or acceptance that it is a problem. Without that as a base, design effort to work around specific restrictions on what can be done where is beside the point. -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Friday, November 30, 2007 12:49 PM To: Theodore Tso Cc: email2mre-ietf@yahoo.com; nfsv4@ietf.org; Trond Myklebust Subject: Re: [nfsv4] symlinks: opaque or UTF-8 On Fri, Nov 30, 2007 at 10:30:21AM -0500, Theodore Tso wrote: > > Finally, it breaks down completely in multi-user scenarios. >=20 > If it is at all helpful, at least for ext[234], when this topic came > up last time, the answer was that in multi-user scenario, the only > sane answer was UTF-8. If a user wants to use some other charset in > the privacy of their own system, that was fine with us, but ext[234] > was *not* going to put charset conversion into the kernel. That way > lies complete and utter madness, and any OS engineer who needs to do > that in the kernel has my sympathies. The easiest thing to do is to push codeset/encoding conversions to the edge and use UTF-8 by convention in the middle. On the filesystem edge very few filesystms should have to do any conversions (e.g., an NTFS module would have to do UTF-8<->UTF-16 conversions, and some filesystems might have options for dealing with legacy to convert to non-Unicode codesets, like ISO-8859-*). The other edge of the middle is the system call stubs in user-land, where knowledge of the current locale's codeset is available. _______________________________________________ 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 Nov 30 13:20: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 1IyAT8-0001wN-CM; Fri, 30 Nov 2007 13:20:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAT6-0001w4-Vt for nfsv4@ietf.org; Fri, 30 Nov 2007 13:20:04 -0500 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyAT6-00076y-FT for nfsv4@ietf.org; Fri, 30 Nov 2007 13:20:04 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAUIK3RU002115 for ; Fri, 30 Nov 2007 18:20:03 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUIK2K4000591 for ; Fri, 30 Nov 2007 11:20:03 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUIK2E6004000; Fri, 30 Nov 2007 12:20:02 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUIK1Rf003999; Fri, 30 Nov 2007 12:20:01 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 12:20:01 -0600 From: Nicolas Williams To: "Noveck, Dave" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130182001.GH2540@Sun.COM> Mail-Followup-To: "Noveck, Dave" , Theodore Tso , email2mre-ietf@yahoo.com, nfsv4@ietf.org, Trond Myklebust References: <20071130174903.GB2540@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: email2mre-ietf@yahoo.com, Theodore Tso , 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 Fri, Nov 30, 2007 at 01:08:12PM -0500, Noveck, Dave wrote: > Yes this can be done, and if it is important for some reason, political, > technical or otherwise, to keep it outside the kernel, then I imagine > that need can be accommodated. The issue I see is that however you do > this, this is a lot of work, and I don't sense a willingness to > undertake that work, just because the internationalization requirements > in RFC3530 together with the needs of non-English-speaking users of > Linux, make it necessary (my opinion). Actually, I believe it's not a lot of work _once_ you have the necessary I18N infrastructure (i.e., codeset conversion tools). Which I believe Linux does have. It's a SMOP in glibc, mostly, and I'm not being sarcastic, it's really a small. For perf reasons one might like a way to turn this off though; getting the interface details for such a knob right may be a bit more difficult, but hardly insurmountable. > We hear a lot about what will not be done, ever. What we don't hear is > any understanding of the fundamental problem, or acceptance that it is a > problem. Without that as a base, design effort to work around specific > restrictions on what can be done where is beside the point. You've certainly heard from me about the technical details of the problem and its possible solutions. I don't represent the Linux community though, but, who does? Trond et. al. need to talk to the glibc folks, and it might help if they had proof of concept patches on hand. The rest of us shouldn't respond to the apparent unwillingness of the Linux community to come together on this by ripping I18N out of NFSv4. I say "apparent" because it's not clear that this has been discussed in the right places. I think the syscall-libc-stubs-convert approach is so sensible (with a global/environmental on/off knob) that once it reaches the right places (glibc community) it will be implemented. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 13:32: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 1IyAeb-0006JI-MK; Fri, 30 Nov 2007 13:31:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAeZ-0006Ir-NR for nfsv4@ietf.org; Fri, 30 Nov 2007 13:31:55 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyAeZ-000825-8N for nfsv4@ietf.org; Fri, 30 Nov 2007 13:31:55 -0500 X-IronPort-AV: E=Sophos;i="4.23,235,1194249600"; d="scan'208";a="127697925" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Nov 2007 10:31:54 -0800 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 lAUIVnhQ027606; Fri, 30 Nov 2007 10:31:50 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 10:31:49 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 10:31:49 -0800 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] symlinks: opaque or UTF-8 Date: Fri, 30 Nov 2007 13:31:48 -0500 Message-ID: In-Reply-To: <20071130182001.GH2540@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgzfcBlCmGgRxKMTHqJj3XR4uuzOgAADlGQ From: "Noveck, Dave" To: "Nicolas Williams" X-OriginalArrivalTime: 30 Nov 2007 18:31:49.0496 (UTC) FILETIME=[45340780:01C8337F] X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: email2mre-ietf@yahoo.com, Theodore Tso , 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 > apparent unwillingness How about "declared unwillingness"? =20 If you can make this happen, then that would be great. You would deserve a quite fulsome acknowledgment, but there might be difficulty in coming up with a generally acceptable formulation. "Got the Linux community to see reason" might be considered unduly provocative. I think we'd be able to negotiate something, though. -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Friday, November 30, 2007 1:20 PM To: Noveck, Dave Cc: Theodore Tso; email2mre-ietf@yahoo.com; nfsv4@ietf.org; Trond Myklebust Subject: Re: [nfsv4] symlinks: opaque or UTF-8 On Fri, Nov 30, 2007 at 01:08:12PM -0500, Noveck, Dave wrote: > Yes this can be done, and if it is important for some reason, political, > technical or otherwise, to keep it outside the kernel, then I imagine > that need can be accommodated. The issue I see is that however you do > this, this is a lot of work, and I don't sense a willingness to > undertake that work, just because the internationalization requirements > in RFC3530 together with the needs of non-English-speaking users of > Linux, make it necessary (my opinion). Actually, I believe it's not a lot of work _once_ you have the necessary I18N infrastructure (i.e., codeset conversion tools). Which I believe Linux does have. It's a SMOP in glibc, mostly, and I'm not being sarcastic, it's really a small. For perf reasons one might like a way to turn this off though; getting the interface details for such a knob right may be a bit more difficult, but hardly insurmountable. > We hear a lot about what will not be done, ever. What we don't hear is > any understanding of the fundamental problem, or acceptance that it is a > problem. Without that as a base, design effort to work around specific > restrictions on what can be done where is beside the point. You've certainly heard from me about the technical details of the problem and its possible solutions. I don't represent the Linux community though, but, who does? Trond et. al. need to talk to the glibc folks, and it might help if they had proof of concept patches on hand. The rest of us shouldn't respond to the apparent unwillingness of the Linux community to come together on this by ripping I18N out of NFSv4. I say "apparent" because it's not clear that this has been discussed in the right places. I think the syscall-libc-stubs-convert approach is so sensible (with a global/environmental on/off knob) that once it reaches the right places (glibc community) it will be implemented. Nico --=20 _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 13:39: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 1IyAlN-0007lO-5c; Fri, 30 Nov 2007 13:38:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAlM-0007l1-CU for nfsv4@ietf.org; Fri, 30 Nov 2007 13:38:56 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyAlL-0001Ro-Tk for nfsv4@ietf.org; Fri, 30 Nov 2007 13:38:56 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUIcsIW002566 for ; Fri, 30 Nov 2007 18:38:55 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUIcsxQ012873 for ; Fri, 30 Nov 2007 11:38:54 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUIcs8O004020; Fri, 30 Nov 2007 12:38:54 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUIcrgM004019; Fri, 30 Nov 2007 12:38:53 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 12:38:53 -0600 From: Nicolas Williams To: "Noveck, Dave" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130183853.GJ2540@Sun.COM> Mail-Followup-To: "Noveck, Dave" , Theodore Tso , email2mre-ietf@yahoo.com, nfsv4@ietf.org, Trond Myklebust References: <20071130182001.GH2540@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: email2mre-ietf@yahoo.com, Theodore Tso , 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 Fri, Nov 30, 2007 at 01:31:48PM -0500, Noveck, Dave wrote: > > apparent unwillingness > > How about "declared unwillingness"? > > If you can make this happen, then that would be great. You would Hey! Back off! :) I'm not volunteering. I work on OpenSolaris stuff and I'm busy enough as it is. I've taken a keen interest in fs I18N in the past and I'm offering my technical advice, and beyond that my advice not to give up on I18N (actually, my position on that is stronger, as you've seen). But that's it. > deserve a quite fulsome acknowledgment, but there might be difficulty in > coming up with a generally acceptable formulation. "Got the Linux > community to see reason" might be considered unduly provocative. I > think we'd be able to negotiate something, though. I'll settle for getting the same thing (codeset conversions in libc fs syscall stubs) implemented in Solaris. We can lead by example, and Linux can follow if the Linux community cares to. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 13:43: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 1IyApl-00027B-SO; Fri, 30 Nov 2007 13:43:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyApl-00026v-4q for nfsv4@ietf.org; Fri, 30 Nov 2007 13:43:29 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyApk-0002ly-PJ for nfsv4@ietf.org; Fri, 30 Nov 2007 13:43:29 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IyApg-00070K-O4; Fri, 30 Nov 2007 13:43:24 -0500 Date: Fri, 30 Nov 2007 13:43:24 -0500 To: "Noveck, Dave" , Theodore Tso , email2mre-ietf@yahoo.com, nfsv4@ietf.org, Trond Myklebust Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130184324.GB24887@fieldses.org> References: <20071130182001.GH2540@Sun.COM> <20071130183853.GJ2540@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071130183853.GJ2540@Sun.COM> User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.2 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 On Fri, Nov 30, 2007 at 12:38:53PM -0600, Nicolas Williams wrote: > On Fri, Nov 30, 2007 at 01:31:48PM -0500, Noveck, Dave wrote: > > > apparent unwillingness > > > > How about "declared unwillingness"? > > > > If you can make this happen, then that would be great. You would > > Hey! Back off! :) I'm not volunteering. I work on OpenSolaris stuff > and I'm busy enough as it is. I've taken a keen interest in fs I18N in > the past and I'm offering my technical advice, and beyond that my advice > not to give up on I18N (actually, my position on that is stronger, as > you've seen). But that's it. > > > deserve a quite fulsome acknowledgment, but there might be difficulty in > > coming up with a generally acceptable formulation. "Got the Linux > > community to see reason" might be considered unduly provocative. I > > think we'd be able to negotiate something, though. > > I'll settle for getting the same thing (codeset conversions in libc fs > syscall stubs) implemented in Solaris. We can lead by example, and > Linux can follow if the Linux community cares to. What does Solaris currently do? --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 13:44:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAqJ-0002a3-Az; Fri, 30 Nov 2007 13:44:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAqI-0002ZR-0W for nfsv4@ietf.org; Fri, 30 Nov 2007 13:44:02 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyAqH-0002wI-Jb for nfsv4@ietf.org; Fri, 30 Nov 2007 13:44:01 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUIi1C3026112 for ; Fri, 30 Nov 2007 18:44:01 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUIi0b4016352 for ; Fri, 30 Nov 2007 11:44:00 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUIi0nL004028; Fri, 30 Nov 2007 12:44:00 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUIi0w6004027; Fri, 30 Nov 2007 12:44:00 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 12:44:00 -0600 From: Nicolas Williams To: "Noveck, Dave" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130184359.GK2540@Sun.COM> Mail-Followup-To: "Noveck, Dave" , Trond Myklebust , email2mre-ietf@yahoo.com, nfsv4@ietf.org References: <1196442236.8031.65.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: email2mre-ietf@yahoo.com, 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 Fri, Nov 30, 2007 at 12:33:08PM -0500, Noveck, Dave wrote: > In other words, the Linux NFSv4 client and the Linux NFSv4 server both > treat path components just as they were treated in NFSv3. They are > interoperable, with each other, but not, in non-UTF-8 locales, with > servers that implement the protocol specified in RFC3530. BTW, MacOS X treats path components in NFSv3 as in NFSv4 (in fact, it normalizes to NFD on CREATE). > Further, there is a fixed determination, not to treat this > interoperability issue as a problem and thereby confrom to the protocol. > > At least we know this now. But you don't "know this." Trond does not represent the whole Linux community. You, and/or at least Mike, seem desperate to find in your representation of the Linux situation a strong enough reason to ditch NFS I18N. That would be most unfortunate, and definitely premature. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 13:45: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 1IyAs9-0004Kc-9c; Fri, 30 Nov 2007 13:45:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAs8-0004KJ-PQ for nfsv4@ietf.org; Fri, 30 Nov 2007 13:45:56 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyAs8-0005kQ-Fj for nfsv4@ietf.org; Fri, 30 Nov 2007 13:45:56 -0500 Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IyAs4-0000Wp-89; Fri, 30 Nov 2007 19:45:52 +0100 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 1IyAs3-0004oe-6v; Fri, 30 Nov 2007 19:45:51 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IyAs2-0004oU-OX; Fri, 30 Nov 2007 19:45:51 +0100 Subject: Re: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: Nicolas Williams In-Reply-To: <20071130183853.GJ2540@Sun.COM> References: <20071130182001.GH2540@Sun.COM> <20071130183853.GJ2540@Sun.COM> Content-Type: text/plain Date: Fri, 30 Nov 2007 13:45:48 -0500 Message-Id: <1196448348.8031.96.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.2, required=12.0, autolearn=disabled, AWL=-0.166) X-UiO-Scanned: 5748F414D61B39D4EB62D747C4B771A78C3B86A8 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -1 maxlevel 200 minaction 2 bait 0 mail/h: 386 total 5490558 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: email2mre-ietf@yahoo.com, Theodore Tso , "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 Fri, 2007-11-30 at 12:38 -0600, Nicolas Williams wrote: > I'll settle for getting the same thing (codeset conversions in libc fs > syscall stubs) implemented in Solaris. We can lead by example, and > Linux can follow if the Linux community cares to. So can I take it that from the above comment this isn't "just another Linux issue", and that the current Solaris client implementation does not perform UTF-8 encoding of filenames? Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 14:10:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBGF-0004Pk-1s; Fri, 30 Nov 2007 14:10:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBGE-0004Pa-Du for nfsv4@ietf.org; Fri, 30 Nov 2007 14:10:50 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyBGD-00021U-OZ for nfsv4@ietf.org; Fri, 30 Nov 2007 14:10:50 -0500 X-IronPort-AV: E=Sophos;i="4.23,235,1194249600"; d="scan'208";a="127711027" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Nov 2007 11:10:38 -0800 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 lAUJAbs4011675; Fri, 30 Nov 2007 11:10:37 -0800 (PST) Received: from exsvlrb02.hq.netapp.com ([10.56.8.63]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 11:10:37 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb02.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 11:10:37 -0800 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] symlinks: opaque or UTF-8 Date: Fri, 30 Nov 2007 14:10:36 -0500 Message-ID: In-Reply-To: <20071130184324.GB24887@fieldses.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgzgO6PgqpdiNvUSwKTfp8+H4vNKAAAdsGA From: "Noveck, Dave" To: "J. Bruce Fields" , "Theodore Tso" , , , "Trond Myklebust" X-OriginalArrivalTime: 30 Nov 2007 19:10:37.0415 (UTC) FILETIME=[B0C04770:01C83384] X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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'll settle for getting the same thing (codeset conversions in libc fs > > syscall stubs) implemented in Solaris. We can lead by example, and > > Linux can follow if the Linux community cares to. > What does Solaris currently do? I thought he just told you. It converts to UTF8 (presumably based on current locale) in libc fs syscall stubs. This given the client per se nothing much to do to conform to the RFC. I assume that the inverse conversions for data returned happen on the way back. One interesting question is what do the Solaris libc fs syscall stubs do for symlinks (create and readlink). The other issue is what the Solaris server does does if you send non-UTF-8 path components. I presume it obeys the RFC but getting confirmation would be nice. I guess a similar issue applies to symlinks. Does it check those for UTF-8-ness, on create, on readlink? The more data we have on what people actually do, the better off we are in figuring out how to deal with our current situation in which we have a lack of interoperability. With regards to Nico's claim that I am desperately trying to drop I18N from NFSv4, I have not suggested that. It may be necessary but I would also like to avoid it. But I'm having trouble understanding how it would work to keep it. Trond may not represent the entire Linux community but I don't see how this working group can deal with the entire Linux community on an issue like this. I think we need to have something that we know will work, rather than something that might work if some set of political developments allow the Linux community to consider this issue in a different light, at some unspecified time in the future. =20 -----Original Message----- From: J. Bruce Fields [mailto:bfields@fieldses.org]=20 Sent: Friday, November 30, 2007 1:43 PM To: Noveck, Dave; Theodore Tso; email2mre-ietf@yahoo.com; nfsv4@ietf.org; Trond Myklebust Subject: Re: [nfsv4] symlinks: opaque or UTF-8 On Fri, Nov 30, 2007 at 12:38:53PM -0600, Nicolas Williams wrote: > On Fri, Nov 30, 2007 at 01:31:48PM -0500, Noveck, Dave wrote: > > > apparent unwillingness > >=20 > > How about "declared unwillingness"? =20 > >=20 > > If you can make this happen, then that would be great. You would >=20 > Hey! Back off! :) I'm not volunteering. I work on OpenSolaris stuff > and I'm busy enough as it is. I've taken a keen interest in fs I18N in > the past and I'm offering my technical advice, and beyond that my advice > not to give up on I18N (actually, my position on that is stronger, as > you've seen). But that's it. >=20 > > deserve a quite fulsome acknowledgment, but there might be difficulty in > > coming up with a generally acceptable formulation. "Got the Linux > > community to see reason" might be considered unduly provocative. I > > think we'd be able to negotiate something, though. >=20 > I'll settle for getting the same thing (codeset conversions in libc fs > syscall stubs) implemented in Solaris. We can lead by example, and > Linux can follow if the Linux community cares to. What does Solaris currently do? --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 Fri Nov 30 14:13:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBIr-0008Cd-CA; Fri, 30 Nov 2007 14:13:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBIq-0008AT-DN for nfsv4@ietf.org; Fri, 30 Nov 2007 14:13:32 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyBIq-0002Wb-3V for nfsv4@ietf.org; Fri, 30 Nov 2007 14:13:32 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IyBIl-0007fx-R7; Fri, 30 Nov 2007 14:13:27 -0500 Date: Fri, 30 Nov 2007 14:13:27 -0500 To: "Noveck, Dave" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130191327.GD24887@fieldses.org> References: <20071130184324.GB24887@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.2 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: email2mre-ietf@yahoo.com, Theodore Tso , 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 Fri, Nov 30, 2007 at 02:10:36PM -0500, Noveck, Dave wrote: > > > I'll settle for getting the same thing (codeset conversions in libc > fs > > > syscall stubs) implemented in Solaris. We can lead by example, and > > > Linux can follow if the Linux community cares to. > > > What does Solaris currently do? > > I thought he just told you. > > It converts to UTF8 (presumably based on current locale) in libc fs > syscall stubs. This given the client per se nothing much to do to > conform to the RFC. OK. I guess I was confused by his use of the future tense ("I'll"): > On Fri, Nov 30, 2007 at 12:38:53PM -0600, Nicolas Williams wrote: > > I'll settle for getting the same thing (codeset conversions in libc fs > > syscall stubs) implemented in Solaris. We can lead by example, and > > Linux can follow if the Linux community cares to. --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 15:12: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 1IyCDZ-0007My-Vu; Fri, 30 Nov 2007 15:12:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCDY-0007Fl-PY for nfsv4@ietf.org; Fri, 30 Nov 2007 15:12:08 -0500 Received: from web38107.mail.mud.yahoo.com ([209.191.124.134]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IyCDY-0004t8-C7 for nfsv4@ietf.org; Fri, 30 Nov 2007 15:12:08 -0500 Received: (qmail 78913 invoked by uid 60001); 30 Nov 2007 20:12:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=EObmFgTZ6tAywfhMspJ1Au4qswrNmSsz60iXHnJMvjc/C6qIaxK8hOaz2jaYjKkPMJ7sOTw6yaKp4wzcdNMq/JseNToccrtOduiJxa59/DkTlrK2Ak2U3GK7nIA9mvmQnFvvW5ToM0KSzNbDabkToOyWhoUGF351YW7SGTjlmho=; X-YMail-OSG: gF41jhMVM1nLs_vfyKkclMXHKQts8F7QrYILN6u5XiGlktEoyp4CjDXZRgefvBxs8vzyT4URHA-- Received: from [198.95.226.230] by web38107.mail.mud.yahoo.com via HTTP; Fri, 30 Nov 2007 12:12:07 PST Date: Fri, 30 Nov 2007 12:12:07 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071130153021.GB28558@thunk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <711660.78555.qm@web38107.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Theodore Tso wrote: > On Thu, Nov 29, 2007 at 08:54:44PM -0500, Trond Myklebust wrote: > > What it won't help with is exporting those filesystems that don't > define > > a charset (ext[234], gfs2, reiserfs, ocfs2, xfs, .... a.k.a. the > > filesystems that people actually use). > > Nor is it sophisticated enough to help Dave achieve Hindu charset > > compatible nirvana. > > > > Finally, it breaks down completely in multi-user scenarios. > > If it is at all helpful, at least for ext[234], when this topic came > up last time, the answer was that in multi-user scenario, the only > sane answer was UTF-8. If a user wants to use some other charset in > the privacy of their own system, that was fine with us, but ext[234] > was *not* going to put charset conversion into the kernel. That way > lies complete and utter madness, and any OS engineer who needs to do > that in the kernel has my sympathies. Trond points out I didn't read this closely. It doesn't help fix the problem (in that respect it is useless). It does however reinforce the intransigence among the Linux community. As for complete and utter madness to put charset conversion in the kernel, Alan Yoder pointed out that EMC and NetApp do just on the server, and apparently smbfs does that in the client's kernel. I don't know about smbfs, but if EMC and NetApp are mad, it is more like being crazy like foxes, if one believes IDC's figures on the combined share of the NAS server business both companies have. "Running code" _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 15:20: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 1IyCLq-00013u-2g; Fri, 30 Nov 2007 15:20:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCLo-00013V-7V for nfsv4@ietf.org; Fri, 30 Nov 2007 15:20:40 -0500 Received: from web38109.mail.mud.yahoo.com ([209.191.124.136]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyCLn-0000Ns-Tn for nfsv4@ietf.org; Fri, 30 Nov 2007 15:20:40 -0500 Received: (qmail 1157 invoked by uid 60001); 30 Nov 2007 20:20:39 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=MT1/tnYFfW8UvaywuMwL5ctgIXAnRE6GNxtLauDn3kE3zelsG3kJIUCZjWXktwqJc49a5k3h0MCmwGYzJRWs8P487niCnodwMvI1/wTQThBQeBrk+RPW3CbTnAxDT96KhYY9ElHd8zS2S3JARIxa5tzOj2R78MX7WeRoeEyKH98=; X-YMail-OSG: WI6gZWMVM1kynQFaTJ5.rvypn3q2Tqf8NAclQ8XsXyqUHeJE7HOYwv.lJXxplampBg-- Received: from [198.95.226.230] by web38109.mail.mud.yahoo.com via HTTP; Fri, 30 Nov 2007 12:20:39 PST Date: Fri, 30 Nov 2007 12:20:39 -0800 (PST) From: Mike Eisler Subject: RE: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <433341.99623.qm@web38109.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "Noveck, Dave" wrote: > With regards to Nico's claim that I am desperately trying to drop > I18N > from NFSv4, I have not suggested that. It may be necessary but I Thus far I am the only one advocating that, and I've read nothing today that changes that proposal. A statement from senior engineers at RedHat, SUSE, and Ubuntu that they will implement Nico's proposal would be the only thing that might make me consider withdrawing my proposal. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 15:44: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 1IyCiv-0006q6-R2; Fri, 30 Nov 2007 15:44:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCiv-0006pb-51 for nfsv4@ietf.org; Fri, 30 Nov 2007 15:44:33 -0500 Received: from web38107.mail.mud.yahoo.com ([209.191.124.134]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyCiu-00066Z-Ow for nfsv4@ietf.org; Fri, 30 Nov 2007 15:44:33 -0500 Received: (qmail 90946 invoked by uid 60001); 30 Nov 2007 20:44:32 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ZgaSZJrTm6BTOcxcPcyuygmupgF620wmAXgwOOtI355YCX6F5i/UMy4SIU0reFdjo8CUWVHdWxoqCf6Ku/LbQ3xaVhp0JMS0UXOIO8Bw5zBuarPBRuylY0SHlUvaLh2U0yYdoZ6fe5tufF41F1zbX1kgFubWQ0JAzeVr7wSfz7o=; X-YMail-OSG: A6iIXI8VM1kWzb7O1Y71Kzkp3MVUa2RkuxfWnRCihQznZwj24j0oGh6l5E1DZvu9LQ-- Received: from [198.95.226.230] by web38107.mail.mud.yahoo.com via HTTP; Fri, 30 Nov 2007 12:44:32 PST Date: Fri, 30 Nov 2007 12:44:32 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <1196448348.8031.96.camel@heimdal.trondhjem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <311661.90789.qm@web38107.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com 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 Fri, 2007-11-30 at 12:38 -0600, Nicolas Williams wrote: > > I'll settle for getting the same thing (codeset conversions in libc > fs > > syscall stubs) implemented in Solaris. We can lead by example, and > > Linux can follow if the Linux community cares to. > > So can I take it that from the above comment this isn't "just another > Linux issue", and that the current Solaris client implementation does > not perform UTF-8 encoding of filenames? 1. Irrelevant. With apologies to my friends at Sun, unfortunately, the Solaris NFS client is not the gorilla any more. Years ago, Linux could get away with saying that since Solaris does it one way, it is ok for Linux to. Now it is the other way around. 2. Solaris is a whole product: it combines the kernel, libraries, and commands. So even if #1 wasn't an issue, and even if Solaris did not have its i18n crap together, at least it could. The mantra in Linux land is that it is not a whole product; it is just the kernel, and making it a whole product is the problem of someone else. So it can't have its i18n crap together until the major distributors of the Linux kernel and compatible commands and libraries take ownership. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 15:45:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCjY-0007DB-7u; Fri, 30 Nov 2007 15:45:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCjX-0007Cz-D1 for nfsv4@ietf.org; Fri, 30 Nov 2007 15:45:11 -0500 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyCjW-00043L-JO for nfsv4@ietf.org; Fri, 30 Nov 2007 15:45:11 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUKj9Ke017253 for ; Fri, 30 Nov 2007 20:45:09 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUKj8YE028549 for ; Fri, 30 Nov 2007 13:45:09 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUKj4AA004079; Fri, 30 Nov 2007 14:45:04 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUKj4NN004078; Fri, 30 Nov 2007 14:45:04 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 14:45:04 -0600 From: Nicolas Williams To: "J. Bruce Fields" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130204503.GN2540@Sun.COM> Mail-Followup-To: "J. Bruce Fields" , "Noveck, Dave" , Theodore Tso , email2mre-ietf@yahoo.com, nfsv4@ietf.org, Trond Myklebust References: <20071130182001.GH2540@Sun.COM> <20071130183853.GJ2540@Sun.COM> <20071130184324.GB24887@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071130184324.GB24887@fieldses.org> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: email2mre-ietf@yahoo.com, Trond Myklebust , Theodore Tso , "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 Fri, Nov 30, 2007 at 01:43:24PM -0500, J. Bruce Fields wrote: > What does Solaris currently do? Sadly, the Solaris NFSv4 client does nothing special beyond preferring UTF-8 locales. If you use UTF-8 locales (the default) then no problem. In OpenSolaris the SMB server does perform normalization-insensitive LOOKUPs and is normalization-preserving, it also knows how to do Unicode case-insensitive LOOKUPs and how to preserve case (if enabled on a filesystem). I don't know if the OpenSolaris NFSv4 server does the same thing, but it'd be a really small SMOP to make it do the same. I'm not sure if the OpenSolaris NFSv4 server rejects non-UTF-8 octet sequences either, but again, it'd be a small SMOP to make it do so if it doesn't already. But ideally we should have an option to dispense with I18N for specific filesystems where legacy requires it. I'm wondering if Mike meant to propose removing I18N altogether or simply utf8string. XDR doesn't have a native UTF-8 string type, but if it did then it would arguably be quite wrong to a) use that type in NFSv4.x, b) allow non-UTF-8 therein for legacy filesystems. So if Mike meant dispensing with the utf8string type, then I could get behind that, provided we still had required-to-implement I18N at the end of the day. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 15:46: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 1IyCkm-0008WD-Hw; Fri, 30 Nov 2007 15:46:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCkl-0008Vm-2K for nfsv4@ietf.org; Fri, 30 Nov 2007 15:46:27 -0500 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyCkj-0006Zb-KR for nfsv4@ietf.org; Fri, 30 Nov 2007 15:46:27 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUKkOYh017577 for ; Fri, 30 Nov 2007 20:46:25 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUKkORp029258 for ; Fri, 30 Nov 2007 13:46:24 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUKkNIP004087; Fri, 30 Nov 2007 14:46:23 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUKkNlK004086; Fri, 30 Nov 2007 14:46:23 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 14:46:23 -0600 From: Nicolas Williams To: "J. Bruce Fields" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130204623.GO2540@Sun.COM> Mail-Followup-To: "J. Bruce Fields" , "Noveck, Dave" , email2mre-ietf@yahoo.com, Theodore Tso , nfsv4@ietf.org, Trond Myklebust References: <20071130184324.GB24887@fieldses.org> <20071130191327.GD24887@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071130191327.GD24887@fieldses.org> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: email2mre-ietf@yahoo.com, Trond Myklebust , Theodore Tso , "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 Fri, Nov 30, 2007 at 02:13:27PM -0500, J. Bruce Fields wrote: > On Fri, Nov 30, 2007 at 02:10:36PM -0500, Noveck, Dave wrote: > > > > I'll settle for getting the same thing (codeset conversions in libc > > fs > > > > syscall stubs) implemented in Solaris. We can lead by example, and > > > > Linux can follow if the Linux community cares to. > > > > > What does Solaris currently do? > > > > I thought he just told you. > > > > It converts to UTF8 (presumably based on current locale) in libc fs > > syscall stubs. This given the client per se nothing much to do to > > conform to the RFC. > > OK. I guess I was confused by his use of the future tense ("I'll"): No, you weren't. Our client does not do this yet. I'd like to see it do that though. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 15:55: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 1IyCtH-0001Gg-FR; Fri, 30 Nov 2007 15:55:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCtG-00015C-BS for nfsv4@ietf.org; Fri, 30 Nov 2007 15:55:14 -0500 Received: from web38103.mail.mud.yahoo.com ([209.191.124.130]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IyCtF-0006Lu-Th for nfsv4@ietf.org; Fri, 30 Nov 2007 15:55:14 -0500 Received: (qmail 86957 invoked by uid 60001); 30 Nov 2007 20:55:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=6L5CADX0mr9VVaAQ43POs9lWuZ0oCw5Af8bEK14yfOz9niKSlmgTmnWo332Vs9MUKxtoAHxaZSLfE6rPCiRWdskmbiraIcsN1eZeFcQjs6U6rZSkZ8wFTbsABgm0E9VaXFnkUxd+TFG9haK6SNbFkdyWonVMnvofVdCYzKc1+jU=; X-YMail-OSG: 5_hvwCEVM1mgWNW.aHHrQ2qs6BBGEG1UD8V2e.8UYCQgYxzRyKAubb0S_wVNNsjvFhsTXgTWRw-- Received: from [198.95.226.230] by web38103.mail.mud.yahoo.com via HTTP; Fri, 30 Nov 2007 12:55:12 PST Date: Fri, 30 Nov 2007 12:55:12 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071130204503.GN2540@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <11814.86422.qm@web38103.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Nicolas Williams wrote: > On Fri, Nov 30, 2007 at 01:43:24PM -0500, J. Bruce Fields wrote: > > What does Solaris currently do? > > Sadly, the Solaris NFSv4 client does nothing special beyond > preferring > UTF-8 locales. If you use UTF-8 locales (the default) then no > problem. So it will send garbage too. Nice. > > In OpenSolaris the SMB server does perform normalization-insensitive > LOOKUPs and is normalization-preserving, it also knows how to do > Unicode > case-insensitive LOOKUPs and how to preserve case (if enabled on a > filesystem). I don't know if the OpenSolaris NFSv4 server does the > same > thing, but it'd be a really small SMOP to make it do the same. I'm Gee, isn't psarc supposed to prevent these inconsistencies ? :-) > not > sure if the OpenSolaris NFSv4 server rejects non-UTF-8 octet > sequences > either, but again, it'd be a small SMOP to make it do so if it > doesn't > already. > > But ideally we should have an option to dispense with I18N for > specific > filesystems where legacy requires it. > > I'm wondering if Mike meant to propose removing I18N altogether or > simply utf8string. XDR doesn't have a native UTF-8 string type, but > if > it did then it would arguably be quite wrong to a) use that type in > NFSv4.x, b) allow non-UTF-8 therein for legacy filesystems. So if > Mike > meant dispensing with the utf8string type, then I could get behind > that, > provided we still had required-to-implement I18N at the end of the > day. I want to remove the requirement that UTF-8 be sent by the client, so that my server can then legally accept the garbage and return the garbage. Believe it or not, there are customers that demand compliance with a standards-rack specification(unless they are running an open/free source operating system, then they've no one to make demands to). I want to comply. I cannot comply if I want to capture market share. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 15:56: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 1IyCub-0005qD-PR; Fri, 30 Nov 2007 15:56:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCua-0005pm-2E for nfsv4@ietf.org; Fri, 30 Nov 2007 15:56:36 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyCuZ-0006dw-LB for nfsv4@ietf.org; Fri, 30 Nov 2007 15:56:35 -0500 Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUKuYb0015401 for ; Fri, 30 Nov 2007 20:56:34 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSC002016SQOV00@mail-amer.sun.com> (original mail from Spencer.Shepler@Sun.COM) for nfsv4@ietf.org; Fri, 30 Nov 2007 13:56:34 -0700 (MST) Received: from [192.168.0.2] ([129.150.33.90]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSC0031L7HN4G00@mail-amer.sun.com>; Fri, 30 Nov 2007 13:56:12 -0700 (MST) Date: Fri, 30 Nov 2007 14:56:16 -0600 From: Spencer Shepler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 In-reply-to: <20071130204623.GO2540@Sun.COM> To: Nicolas Williams Message-id: <29AA9CD6-F184-46CF-AC8B-5B31A4B72837@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: <20071130184324.GB24887@fieldses.org> <20071130191327.GD24887@fieldses.org> <20071130204623.GO2540@Sun.COM> X-Spam-Score: 0.2 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: email2mre-ietf@yahoo.com, Theodore Tso , nfsv4@ietf.org, Trond Myklebust , "J. Bruce Fields" , "Noveck, Dave" 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 Nov 30, 2007, at 2:46 PM, Nicolas Williams wrote: > On Fri, Nov 30, 2007 at 02:13:27PM -0500, J. Bruce Fields wrote: >> On Fri, Nov 30, 2007 at 02:10:36PM -0500, Noveck, Dave wrote: >>>>> I'll settle for getting the same thing (codeset conversions in >>>>> libc >>> fs >>>>> syscall stubs) implemented in Solaris. We can lead by example, >>>>> and >>>>> Linux can follow if the Linux community cares to. >>> >>>> What does Solaris currently do? >>> >>> I thought he just told you. >>> >>> It converts to UTF8 (presumably based on current locale) in libc fs >>> syscall stubs. This given the client per se nothing much to do to >>> conform to the RFC. >> >> OK. I guess I was confused by his use of the future tense ("I'll"): > > No, you weren't. Our client does not do this yet. I'd like to see it > do that though. > And so would I so we have at least the intent. Spencer _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 16:11:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyD8f-00022U-MS; Fri, 30 Nov 2007 16:11:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyD8f-0001x3-0Q for nfsv4@ietf.org; Fri, 30 Nov 2007 16:11:09 -0500 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyD8e-0001LL-LC for nfsv4@ietf.org; Fri, 30 Nov 2007 16:11:08 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAULB7qF019219 for ; Fri, 30 Nov 2007 21:11:07 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAULB6JI045415 for ; Fri, 30 Nov 2007 14:11:07 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAULB6cA004107; Fri, 30 Nov 2007 15:11:06 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAULB6dG004106; Fri, 30 Nov 2007 15:11:06 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 15:11:06 -0600 From: Nicolas Williams To: Spencer Shepler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130211105.GP2540@Sun.COM> Mail-Followup-To: Spencer Shepler , "J. Bruce Fields" , email2mre-ietf@yahoo.com, Trond Myklebust , Theodore Tso , "Noveck, Dave" , nfsv4@ietf.org References: <20071130184324.GB24887@fieldses.org> <20071130191327.GD24887@fieldses.org> <20071130204623.GO2540@Sun.COM> <29AA9CD6-F184-46CF-AC8B-5B31A4B72837@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29AA9CD6-F184-46CF-AC8B-5B31A4B72837@sun.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: email2mre-ietf@yahoo.com, Theodore Tso , nfsv4@ietf.org, Trond Myklebust , "J. Bruce Fields" , "Noveck, Dave" 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 Fri, Nov 30, 2007 at 02:56:16PM -0600, Spencer Shepler wrote: > >>OK. I guess I was confused by his use of the future tense ("I'll"): > > > >No, you weren't. Our client does not do this yet. I'd like to see it > >do that though. > > And so would I so we have at least the intent. We also now have all the infrastructure pieces. Intent + infrastructure -> this won't take years. FS I18N is not just a requirement, it's around the corner. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 16:17: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 1IyDF3-0002GU-7q; Fri, 30 Nov 2007 16:17:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDEn-0001ye-4r for nfsv4@ietf.org; Fri, 30 Nov 2007 16:17:29 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyDAS-00041W-Om for nfsv4@ietf.org; Fri, 30 Nov 2007 16:13:02 -0500 Received: from mail-mx4.uio.no ([129.240.10.45]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IyDAS-0002dC-0S; Fri, 30 Nov 2007 22:13:00 +0100 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 1IyDAR-0002Eh-ME; Fri, 30 Nov 2007 22:12:59 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IyDAR-0002EW-A6; Fri, 30 Nov 2007 22:12:59 +0100 Subject: Re: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: email2mre-ietf@yahoo.com In-Reply-To: <11814.86422.qm@web38103.mail.mud.yahoo.com> References: <11814.86422.qm@web38103.mail.mud.yahoo.com> Content-Type: text/plain Date: Fri, 30 Nov 2007 16:12:57 -0500 Message-Id: <1196457177.9414.9.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.3, required=12.0, autolearn=disabled, AWL=-0.333) X-UiO-Scanned: FE51F138B2E66DE76AC4553059ADF4805AC62688 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -2 maxlevel 200 minaction 2 bait 0 mail/h: 86 total 5491697 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) 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 Fri, 2007-11-30 at 12:55 -0800, Mike Eisler wrote: > I want to remove the requirement that UTF-8 be sent by the client, so > that my server can then legally accept the garbage and return the > garbage. Believe it or not, there are customers that demand compliance > with a standards-rack specification(unless they are running > an open/free source operating system, then they've no one to > make demands to). I want to comply. I cannot comply if I > want to capture market share. The problem then becomes how to deal with case-insensitive filesystems. For better or for worse, NFSv4 decided to support those, and I can't see how you can do that without also defining a charset. In fact, I don't really see how you can support case-insensitivity without defining a full locale since the capitalised form of letters is locale-dependent (in some countries, certain capitals lose their accents, for instance). If you want a lecture on how complicated that stuff can be, talk to the Samba folks... Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 16:22: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 1IyDJn-0006i1-FE; Fri, 30 Nov 2007 16:22:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDJl-0006hN-N2 for nfsv4@ietf.org; Fri, 30 Nov 2007 16:22:37 -0500 Received: from web38107.mail.mud.yahoo.com ([209.191.124.134]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IyDJl-0004C3-Al for nfsv4@ietf.org; Fri, 30 Nov 2007 16:22:37 -0500 Received: (qmail 5837 invoked by uid 60001); 30 Nov 2007 21:22:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=6InX0lg75QREKmU0d300IOgIik4ti+FBHLQWHtLgd9h5BUz/ZlGLJ3uyz55RQ0Dt+wjOd0sKdYLmff4wlIUToyfjXaoHM2rYMLE9/UMMwym3eBFMFiyPA9jK/o3vp6kMy0ZlDrALAuJzF2nEumZxa0mbQN72IyjEH/MXhfNMBFM=; X-YMail-OSG: O5gjq7cVM1n1v4_bTLW67FdfK3MAeGcOX.rQYoe_w0A4qEDAA19ZTKOagjenduiOaZTvwfen4g-- Received: from [198.95.226.230] by web38107.mail.mud.yahoo.com via HTTP; Fri, 30 Nov 2007 13:22:33 PST Date: Fri, 30 Nov 2007 13:22:33 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <1196457177.9414.9.camel@heimdal.trondhjem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <712433.5442.qm@web38107.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com 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 Fri, 2007-11-30 at 12:55 -0800, Mike Eisler wrote: > > I want to remove the requirement that UTF-8 be sent by the client, > so > > that my server can then legally accept the garbage and return the > > garbage. Believe it or not, there are customers that demand > compliance > > with a standards-rack specification(unless they are running > > an open/free source operating system, then they've no one to > > make demands to). I want to comply. I cannot comply if I > > want to capture market share. > > The problem then becomes how to deal with case-insensitive > filesystems. > For better or for worse, NFSv4 decided to support those, and I can't An OPTIONAL feature of NFSv4. > see > how you can do that without also defining a charset. In fact, I don't > really see how you can support case-insensitivity without defining a > full locale since the capitalised form of letters is locale-dependent > (in some countries, certain capitals lose their accents, for > instance). > > If you want a lecture on how complicated that stuff can be, talk to > the > Samba folks... The point is they apparently managed to do something. And even if it was impossible, I'm OK with sacrificing an OPTIONAL feature. If NFSv4.1 ever goes to DRAFT standard, if no one has done it, then it goes away anyway. You are the one saying you will never commit to a character set. If you don't like the consequences then make a different commitment. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 16:23: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 1IyDKJ-0007NA-Sm; Fri, 30 Nov 2007 16:23:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDKI-0007Mj-UD for nfsv4@ietf.org; Fri, 30 Nov 2007 16:23:10 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyDKI-0004MA-IQ for nfsv4@ietf.org; Fri, 30 Nov 2007 16:23:10 -0500 X-IronPort-AV: E=Sophos;i="4.23,236,1194249600"; d="scan'208";a="127751090" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Nov 2007 13:23:09 -0800 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 lAULN9V2024315; Fri, 30 Nov 2007 13:23:09 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 13:23:09 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 13:23:09 -0800 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] symlinks: opaque or UTF-8 Date: Fri, 30 Nov 2007 16:23:07 -0500 Message-ID: In-Reply-To: <1196457177.9414.9.camel@heimdal.trondhjem.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: Acgzlougg0+7iQY/T46y4KzqjJfizAAAGzSg From: "Noveck, Dave" To: "Trond Myklebust" , X-OriginalArrivalTime: 30 Nov 2007 21:23:09.0105 (UTC) FILETIME=[3453E210:01C83397] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 think case-insensitive filesystems have to be defined as UTF-8-only. As Trond points out, there is no way to make them work otehrwise. -----Original Message----- From: Trond Myklebust [mailto:trond.myklebust@fys.uio.no]=20 Sent: Friday, November 30, 2007 4:13 PM To: email2mre-ietf@yahoo.com Cc: nfsv4@ietf.org Subject: Re: [nfsv4] symlinks: opaque or UTF-8 On Fri, 2007-11-30 at 12:55 -0800, Mike Eisler wrote: > I want to remove the requirement that UTF-8 be sent by the client, so > that my server can then legally accept the garbage and return the=20 > garbage. Believe it or not, there are customers that demand compliance > with a standards-rack specification(unless they are running=20 > an open/free source operating system, then they've no one to=20 > make demands to). I want to comply. I cannot comply if I=20 > want to capture market share. The problem then becomes how to deal with case-insensitive filesystems. For better or for worse, NFSv4 decided to support those, and I can't see how you can do that without also defining a charset. In fact, I don't really see how you can support case-insensitivity without defining a full locale since the capitalised form of letters is locale-dependent (in some countries, certain capitals lose their accents, for instance). If you want a lecture on how complicated that stuff can be, talk to the Samba folks... 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 Fri Nov 30 16:25: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 1IyDMq-0004XZ-97; Fri, 30 Nov 2007 16:25:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDMp-0004XO-AN for nfsv4@ietf.org; Fri, 30 Nov 2007 16:25:47 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyDMo-0007Ey-Rf for nfsv4@ietf.org; Fri, 30 Nov 2007 16:25:47 -0500 Received: from mail-mx5.uio.no ([129.240.10.46]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IyDMg-0007iX-4R; Fri, 30 Nov 2007 22:25:38 +0100 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 1IyDMf-0006p4-F6; Fri, 30 Nov 2007 22:25:37 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IyDMe-0006op-VU; Fri, 30 Nov 2007 22:25:37 +0100 Subject: Re: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: Nicolas Williams In-Reply-To: <20071130211105.GP2540@Sun.COM> References: <20071130184324.GB24887@fieldses.org> <20071130191327.GD24887@fieldses.org> <20071130204623.GO2540@Sun.COM> <29AA9CD6-F184-46CF-AC8B-5B31A4B72837@sun.com> <20071130211105.GP2540@Sun.COM> Content-Type: text/plain Date: Fri, 30 Nov 2007 16:25:33 -0500 Message-Id: <1196457934.9414.15.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.2, required=12.0, autolearn=disabled, AWL=-0.165) X-UiO-Scanned: DC4C91DEEFC4CBB3CAEB75C29ADEAB986047E13F X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -1 maxlevel 200 minaction 2 bait 0 mail/h: 170 total 5491781 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: email2mre-ietf@yahoo.com, Theodore Tso , nfsv4@ietf.org, "J. Bruce Fields" , "Noveck, Dave" , Spencer Shepler 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 Fri, 2007-11-30 at 15:11 -0600, Nicolas Williams wrote: > On Fri, Nov 30, 2007 at 02:56:16PM -0600, Spencer Shepler wrote: > > >>OK. I guess I was confused by his use of the future tense ("I'll"): > > > > > >No, you weren't. Our client does not do this yet. I'd like to see it > > >do that though. > > > > And so would I so we have at least the intent. > > We also now have all the infrastructure pieces. Intent + infrastructure > -> this won't take years. FS I18N is not just a requirement, it's > around the corner. I'm still not convinced this solves the problem of a mandatory UTF-8 requirement in the RFC, though. If it is true that Solaris currently doesn't enforce UTF-8, then you will be in the exact same position as Linux is w.r.t. the existence of filesystems that are currently in other locales, or even ones that mix locales. Mandating UTF-8 even at the libc level is likely to cause problems for systems with such a legacy setup, and so you will get people who will continue to turn that functionality off. Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 16:26: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 1IyDNP-0004n8-Oc; Fri, 30 Nov 2007 16:26:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDNO-0004mb-NN for nfsv4@ietf.org; Fri, 30 Nov 2007 16:26:22 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyDNO-0007P1-4T for nfsv4@ietf.org; Fri, 30 Nov 2007 16:26:22 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAULQLWw009843 for ; Fri, 30 Nov 2007 21:26:21 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAULQLb7054354 for ; Fri, 30 Nov 2007 14:26:21 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAULQLIL004152; Fri, 30 Nov 2007 15:26:21 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAULQK3r004151; Fri, 30 Nov 2007 15:26:20 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 15:26:20 -0600 From: Nicolas Williams To: Trond Myklebust Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130212620.GR2540@Sun.COM> Mail-Followup-To: Trond Myklebust , email2mre-ietf@yahoo.com, nfsv4@ietf.org References: <11814.86422.qm@web38103.mail.mud.yahoo.com> <1196457177.9414.9.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196457177.9414.9.camel@heimdal.trondhjem.org> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Fri, Nov 30, 2007 at 04:12:57PM -0500, Trond Myklebust wrote: > The problem then becomes how to deal with case-insensitive filesystems. > For better or for worse, NFSv4 decided to support those, and I can't see > how you can do that without also defining a charset. In fact, I don't Oh yeah, if you're just-use-8 then you can't be case-insensitive. So what? I don't think we'll see an IETF-sanctioned version of NFSv4 (or v5, or whatever) without I18N. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 16:30: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 1IyDRk-0007Mq-TW; Fri, 30 Nov 2007 16:30:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDRj-0007MN-FX for nfsv4@ietf.org; Fri, 30 Nov 2007 16:30:51 -0500 Received: from mx2.netapp.com ([216.240.18.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyDRj-0006M0-3l for nfsv4@ietf.org; Fri, 30 Nov 2007 16:30:51 -0500 X-IronPort-AV: E=Sophos;i="4.23,236,1194249600"; d="scan'208";a="127753117" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 30 Nov 2007 13:30:49 -0800 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 lAULUm64026430; Fri, 30 Nov 2007 13:30:48 -0800 (PST) Received: from exsvlrb01.hq.netapp.com ([10.56.8.62]) by svlexrs01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 13:30:48 -0800 Received: from exnane01.hq.netapp.com ([10.97.0.61]) by exsvlrb01.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 13:30:47 -0800 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] symlinks: opaque or UTF-8 Date: Fri, 30 Nov 2007 16:30:46 -0500 Message-ID: In-Reply-To: <20071130211105.GP2540@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nfsv4] symlinks: opaque or UTF-8 Thread-Index: AcgzlaDvkI68StzBQpO3PTapz/4GCQAAfawg From: "Noveck, Dave" To: "Nicolas Williams" , "Spencer Shepler" X-OriginalArrivalTime: 30 Nov 2007 21:30:47.0718 (UTC) FILETIME=[45AEAC60:01C83398] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "J. Bruce Fields" , email2mre-ietf@yahoo.com, Theodore Tso , 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 OK, do we have any clients that make effective provisions to send UTF-8 component names? Given that lots don't, it wouldn't matter from a practical point of view, but it would somehow make me feel better having spent all this time on this, including coding the appropriate translation on the fs side. Come on, is there even one client out there, who does this? -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@sun.com]=20 Sent: Friday, November 30, 2007 4:11 PM To: Spencer Shepler Cc: J. Bruce Fields; email2mre-ietf@yahoo.com; Trond Myklebust; Theodore Tso; Noveck, Dave; nfsv4@ietf.org Subject: Re: [nfsv4] symlinks: opaque or UTF-8 On Fri, Nov 30, 2007 at 02:56:16PM -0600, Spencer Shepler wrote: > >>OK. I guess I was confused by his use of the future tense ("I'll"): > > > >No, you weren't. Our client does not do this yet. I'd like to see it > >do that though. >=20 > And so would I so we have at least the intent. We also now have all the infrastructure pieces. Intent + infrastructure -> this won't take years. FS I18N is not just a requirement, it's around the corner. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 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 1IyDa9-0006oP-QQ; Fri, 30 Nov 2007 16:39:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDa8-0006nm-2u for nfsv4@ietf.org; Fri, 30 Nov 2007 16:39:32 -0500 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyDa7-00006O-KD for nfsv4@ietf.org; Fri, 30 Nov 2007 16:39:32 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAULdUIY026536 for ; Fri, 30 Nov 2007 21:39:30 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAULdUQ0000410 for ; Fri, 30 Nov 2007 14:39:30 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAULdQuQ004161; Fri, 30 Nov 2007 15:39:27 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAULdQU0004160; Fri, 30 Nov 2007 15:39:26 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 15:39:26 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130213926.GS2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <433341.99623.qm@web38109.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433341.99623.qm@web38109.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Fri, Nov 30, 2007 at 12:20:39PM -0800, Mike Eisler wrote: > --- "Noveck, Dave" wrote: > > With regards to Nico's claim that I am desperately trying to drop I'd said you and/or Mike :) > > I18N > > from NFSv4, I have not suggested that. It may be necessary but I > > Thus far I am the only one advocating that, and I've read nothing today > > that changes that proposal. > > A statement from senior engineers at RedHat, SUSE, and Ubuntu that > they will implement Nico's proposal would be the only thing that might > make me consider withdrawing my proposal. It's not as though your proposing it by itself creates any kind consensus. The rest of us don't need everyone else to agree to *implementing* I18N in their clients in order to support retaining I18N in the spec. We need only consensus to keep I18N in the spec. Actually, we don't even need WG consensus to keep I18N in the spec because it's already there and to remove I18N we'd need much more than WG consensus. We'd need IESG support and IETF consensus -- that's NOT likely to happen. Taking the NFSv4 ball home and playing elsewhere would only need agreement amongs the top players, but somehow I don't see that as a likely nor practical option. It is NOT the case that the IETF needs any "statement from senior engineers at ... that they will implement ..." in order to require a major feature, like I18N (or secure protocols, for that matter). This may sound harsh, but I think I'm describing the reality on the ground as it is. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 16:41: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 1IyDbc-0007aZ-BW; Fri, 30 Nov 2007 16:41:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDba-0007a7-UV for nfsv4@ietf.org; Fri, 30 Nov 2007 16:41:02 -0500 Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyDba-0000Uu-0z for nfsv4@ietf.org; Fri, 30 Nov 2007 16:41:02 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAULf1YC002637 for ; Fri, 30 Nov 2007 21:41:01 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAULf0pd002011 for ; Fri, 30 Nov 2007 14:41:01 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAULf0wt004170; Fri, 30 Nov 2007 15:41:00 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAULexY9004169; Fri, 30 Nov 2007 15:40:59 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 15:40:59 -0600 From: Nicolas Williams To: Trond Myklebust Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130214059.GT2540@Sun.COM> Mail-Followup-To: Trond Myklebust , Spencer Shepler , "J. Bruce Fields" , email2mre-ietf@yahoo.com, Theodore Tso , "Noveck, Dave" , nfsv4@ietf.org References: <20071130184324.GB24887@fieldses.org> <20071130191327.GD24887@fieldses.org> <20071130204623.GO2540@Sun.COM> <29AA9CD6-F184-46CF-AC8B-5B31A4B72837@sun.com> <20071130211105.GP2540@Sun.COM> <1196457934.9414.15.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196457934.9414.15.camel@heimdal.trondhjem.org> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: email2mre-ietf@yahoo.com, Theodore Tso , nfsv4@ietf.org, "J. Bruce Fields" , "Noveck, Dave" , Spencer Shepler 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 Fri, Nov 30, 2007 at 04:25:33PM -0500, Trond Myklebust wrote: > > On Fri, 2007-11-30 at 15:11 -0600, Nicolas Williams wrote: > > On Fri, Nov 30, 2007 at 02:56:16PM -0600, Spencer Shepler wrote: > > > >>OK. I guess I was confused by his use of the future tense ("I'll"): > > > > > > > >No, you weren't. Our client does not do this yet. I'd like to see it > > > >do that though. > > > > > > And so would I so we have at least the intent. > > > > We also now have all the infrastructure pieces. Intent + infrastructure > > -> this won't take years. FS I18N is not just a requirement, it's > > around the corner. > > I'm still not convinced this solves the problem of a mandatory UTF-8 > requirement in the RFC, though. If it is true that Solaris currently Lets be careful with terminology. We have an IETF requirement for support for I18N in the protocol. I do not believe that means that we have a requirement to NOT have non-I18N optional modes. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 16: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 1IyDcd-0008BB-3F; Fri, 30 Nov 2007 16:42:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDcb-0008Ae-MQ for nfsv4@ietf.org; Fri, 30 Nov 2007 16:42:05 -0500 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyDca-0000nP-VO for nfsv4@ietf.org; Fri, 30 Nov 2007 16:42:05 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAULg4Sq027137 for ; Fri, 30 Nov 2007 21:42:04 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAULg3pA002526 for ; Fri, 30 Nov 2007 14:42:04 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAULg3dQ004177; Fri, 30 Nov 2007 15:42:03 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAULg3Y2004176; Fri, 30 Nov 2007 15:42:03 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 15:42:03 -0600 From: Nicolas Williams To: "Noveck, Dave" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130214202.GU2540@Sun.COM> Mail-Followup-To: "Noveck, Dave" , Spencer Shepler , "J. Bruce Fields" , email2mre-ietf@yahoo.com, Trond Myklebust , Theodore Tso , nfsv4@ietf.org References: <20071130211105.GP2540@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: email2mre-ietf@yahoo.com, Theodore Tso , nfsv4@ietf.org, Trond Myklebust , "J. Bruce Fields" , Spencer Shepler 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 Fri, Nov 30, 2007 at 04:30:46PM -0500, Noveck, Dave wrote: > OK, do we have any clients that make effective provisions to send UTF-8 > component names? Given that lots don't, it wouldn't matter from a I expect that Windows-based ones do. And soon enough Solaris will too. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 16:43: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 1IyDdi-0000OG-P1; Fri, 30 Nov 2007 16:43:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDdh-0000Ns-2W for nfsv4@ietf.org; Fri, 30 Nov 2007 16:43:13 -0500 Received: from pat.uio.no ([129.240.10.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyDde-0003H9-SD for nfsv4@ietf.org; Fri, 30 Nov 2007 16:43:13 -0500 Received: from mail-mx8.uio.no ([129.240.10.38]) by pat.uio.no with esmtp (Exim 4.67) (envelope-from ) id 1IyDdS-0006vV-65; Fri, 30 Nov 2007 22:42:59 +0100 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 1IyDdR-0003i3-K6; Fri, 30 Nov 2007 22:42:57 +0100 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:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1IyDdR-0003ha-2X; Fri, 30 Nov 2007 22:42:57 +0100 Subject: RE: [nfsv4] symlinks: opaque or UTF-8 From: Trond Myklebust To: "Noveck, Dave" In-Reply-To: References: Content-Type: text/plain Date: Fri, 30 Nov 2007 16:42:54 -0500 Message-Id: <1196458974.9414.24.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 Content-Transfer-Encoding: 7bit X-UiO-Resend: resent X-UiO-ClamAV-Virus: No X-UiO-Spam-info: not spam, SpamAssassin (score=-0.4, required=12.0, autolearn=disabled, AWL=-0.353) X-UiO-Scanned: 705167E33A96CBA064EBD7E6117209CA5848F650 X-UiO-SPAM-Test: remote_host: 129.240.10.9 spam_score: -3 maxlevel 200 minaction 2 bait 0 mail/h: 296 total 5491907 max/h 8345 blacklist 0 greylist 0 ratelimit 0 X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: email2mre-ietf@yahoo.com, Theodore Tso , Nicolas Williams , nfsv4@ietf.org, "J. Bruce Fields" , Spencer Shepler 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 Fri, 2007-11-30 at 16:30 -0500, Noveck, Dave wrote: > OK, do we have any clients that make effective provisions to send UTF-8 > component names? Given that lots don't, it wouldn't matter from a > practical point of view, but it would somehow make me feel better having > spent all this time on this, including coding the appropriate > translation on the fs side. > > Come on, is there even one client out there, who does this? I seem to remember the AIX guys asking questions about stringprepping a year or two ago. Does anybody have a copy of their Red Book to check? Cheers Trond _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 16:57:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDrx-0003Xc-PX; Fri, 30 Nov 2007 16:57:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDrw-0003PE-Cn for nfsv4@ietf.org; Fri, 30 Nov 2007 16:57:56 -0500 Received: from web38113.mail.mud.yahoo.com ([209.191.124.140]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IyDrw-0004ez-00 for nfsv4@ietf.org; Fri, 30 Nov 2007 16:57:56 -0500 Received: (qmail 14984 invoked by uid 60001); 30 Nov 2007 21:57:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=lYSSJ1evInr6BTK4H5VS98n6ot7D9nzAW7RHOf5PGgIng1OlA02XPDD47LTdF8e98JEt6FlM4+/UwK8sFfEBop9xIHthL2T2Y1scMqcZgJPnq+jyphKXNqG37DKHtRrTtfa8mahV5wGUifQgSMmtWuMlCMOmKgurVhSA/F9ljPM=; X-YMail-OSG: sxPayyAVM1mCTZ7AbO1AsLB3XWL8rBwQxNXYu2Jb6nK28ZR.aNOMdJdCmGKtCf22vhkMQEXbfw-- Received: from [198.95.226.230] by web38113.mail.mud.yahoo.com via HTTP; Fri, 30 Nov 2007 13:57:55 PST Date: Fri, 30 Nov 2007 13:57:55 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071130213926.GS2540@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <387500.14233.qm@web38113.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Nicolas Williams wrote: > It's not as though your proposing it by itself creates any kind > consensus. The rest of us don't need everyone else to agree to Of course. > Actually, we don't even need WG consensus to keep I18N in the spec > because it's already there and to remove I18N we'd need much more Agreed. > than > WG consensus. We'd need IESG support and IETF consensus -- that's > NOT > likely to happen. I don't know. I'd like to try. > [...] Taking the NFSv4 ball home and playing elsewhere I have no idea what that metaphor means, and won't speculate. For my part I want be able to comply with a standard issued by a real open standards body and not violate it. I've never written or said otherwise from the time Sun and ISOC signed the agreement. > would only need agreement amongs the top players, but somehow I don't > see that as a likely nor practical option. > > It is NOT the case that the IETF needs any "statement from senior > engineers at ... that they will implement ..." in order to require a > major feature, like I18N (or secure protocols, for that matter). Of course IETF can just mandate specfications that no one will comply with or implement or use. That's what IETF does. Look at IPv6 for example. DNSSEC. shttp. SPKM. Etc. > This may sound harsh, but I think I'm describing the reality on the > ground as it is. Your reality is not on ground at all. It is in luxury hotel conference room where IETF meets that is far outside the reality on ground. If i18n stays in as is, then everyone (not just the clients, who never said a peep in 10 years that they would fail to comply) will not comply. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From GeorgepassaicMiller@socialinvest.org Fri Nov 30 17:01:15 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDv9-0007Zb-4U; Fri, 30 Nov 2007 17:01:15 -0500 Received: from 220-132-155-95.hinet-ip.hinet.net ([220.132.155.95] helo=wxpjosephvaz.dedaphm.com) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IyDv8-0005NS-Mo; Fri, 30 Nov 2007 17:01:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by host70810729.socialinvest.org (8.13.1/8.13.1) with SMTP id 37LSmWZy37.917133.M6t.tGl.8808864663791 for ; Sat, 1 Dec 2007 06:00:27 -0800 Message-ID: <10adff01c8339c$759394a0$2a01a8c0@wxpjosephvaz> From: "Robert Anderson" To: Subject: Approval process Date: Sat, 1 Dec 2007 06:00:27 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_10ADFB_01C8339C.759394A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 This is a multi-part message in MIME format. ------=_NextPart_000_10ADFB_01C8339C.759394A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Even if you have no erection problems Cialis Soft Tabs would help you to = make better sex more often and to bring unimaginable plesure to her. = Just disolve half a pill under your tongue and get ready for action in = 30 minutes. The tests showed that the majority of men after taking this = medication were able to have perfect erection during 24 hours! Package Quantity Price in your local drugstore* Our price LearnMoreNow 10 tabs 20 doses $99.95 $34.49 30 tabs 60 doses $299.95 $88.50 60 tabs 120 doses $449.95 $141.02 90 tabs 180 doses $769.95 $176.40 180 tabs 360 doses $1299.95 $298.46 When you are young and stressed up… When you are aged and never give up… Cialis Soft Tabs gives you confidence in any chance, every time. ------=_NextPart_000_10ADFB_01C8339C.759394A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20

Even if you have no erection problems = Cialis Soft=20 Tabs would help you to make better sex more often and to bring=20 unimaginable plesure to her. Just disolve half a pill under your tongue = and get=20 ready for action in 30 minutes. The tests showed that the majority of = men after=20 taking this medication were able to have perfect erection during = 24=20 hours!

Package Quantity Price in your = local drugstore* Our = price

Learn
More
Now
10 tabs 20 doses $99.95 $34.49
30 tabs 60 doses $299.95 $88.50
60 tabs 120 doses $449.95 $141.02
90 tabs 180 doses $769.95 $176.40
180 tabs 360 doses $1299.95 $298.46

When you are young and stressed = up…
When you are aged and never give up…
Cialis Soft Tabs gives you confidence in any chance, every time.

------=_NextPart_000_10ADFB_01C8339C.759394A0-- From nfsv4-bounces@ietf.org Fri Nov 30 17:12: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 1IyE5b-0000R2-SP; Fri, 30 Nov 2007 17:12:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyE5a-0000Qj-Q1 for nfsv4@ietf.org; Fri, 30 Nov 2007 17:12:02 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyE5Z-0003L1-Cj for nfsv4@ietf.org; Fri, 30 Nov 2007 17:12:02 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUMC0CO013243 for ; Fri, 30 Nov 2007 22:12:00 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUMC0c5020562 for ; Fri, 30 Nov 2007 15:12:00 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUMC0iP004240; Fri, 30 Nov 2007 16:12:00 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUMBxD1004239; Fri, 30 Nov 2007 16:11:59 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 16:11:59 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130221159.GA2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <20071130204503.GN2540@Sun.COM> <11814.86422.qm@web38103.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11814.86422.qm@web38103.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Fri, Nov 30, 2007 at 12:55:12PM -0800, Mike Eisler wrote: > --- Nicolas Williams wrote: > > In OpenSolaris the SMB server does perform normalization-insensitive > > LOOKUPs and is normalization-preserving, it also knows how to do > > Unicode > > case-insensitive LOOKUPs and how to preserve case (if enabled on a > > filesystem). I don't know if the OpenSolaris NFSv4 server does the > > same > > thing, but it'd be a really small SMOP to make it do the same. I'm > > Gee, isn't psarc supposed to prevent these inconsistencies ? :-) You'd think, but I'm not a member ;) > I want to remove the requirement that UTF-8 be sent by the client, so > that my server can then legally accept the garbage and return the > garbage. Believe it or not, there are customers that demand compliance > with a standards-rack specification(unless they are running > an open/free source operating system, then they've no one to > make demands to). I want to comply. I cannot comply if I > want to capture market share. As a server vendor you can comply if we simply add a per-fsid option to just-use-8. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 17:12:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyE5u-0000fb-3b; Fri, 30 Nov 2007 17:12:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyE5t-0000fH-5t for nfsv4@ietf.org; Fri, 30 Nov 2007 17:12:21 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyE5q-0003Ta-Vs for nfsv4@ietf.org; Fri, 30 Nov 2007 17:12:21 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IyE5q-0002rn-1R; Fri, 30 Nov 2007 17:12:18 -0500 Date: Fri, 30 Nov 2007 17:12:17 -0500 To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130221217.GK24887@fieldses.org> References: <20071130213926.GS2540@Sun.COM> <387500.14233.qm@web38113.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <387500.14233.qm@web38113.mail.mud.yahoo.com> User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Fri, Nov 30, 2007 at 01:57:55PM -0800, Mike Eisler wrote: > If i18n stays in as is, then everyone (not just the clients, > who never said a peep in 10 years that they would fail to comply) Not completely true: http://playground.sun.com/pub/nfsv4/webpage/nfsv4-wg-archive-feb-03-feb-05/1176.html "Linux does no normalization or checking whatsoever at the VFS level in order to enforce UTF-8" Admittedly that may still have been too late (2004), and not clear enough. (Though I'll admit I have not yet had the pleasure of re-reading that thread in its entireity, so I may have missed some more relevant quote.) --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 17:16: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 1IyE9v-0002vo-BF; Fri, 30 Nov 2007 17:16:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyE9u-0002va-9y for nfsv4@ietf.org; Fri, 30 Nov 2007 17:16:30 -0500 Received: from sca-ea-mail-1.sun.com ([192.18.43.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyE9t-0003hJ-UV for nfsv4@ietf.org; Fri, 30 Nov 2007 17:16:30 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lAUMGSV2007863 for ; Fri, 30 Nov 2007 22:16:28 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUMGSiM023336 for ; Fri, 30 Nov 2007 15:16:28 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUMGS2E004248; Fri, 30 Nov 2007 16:16:28 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUMGScN004247; Fri, 30 Nov 2007 16:16:28 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 16:16:28 -0600 From: Nicolas Williams To: Mike Eisler , nfsv4@ietf.org Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130221627.GB2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <20071130204503.GN2540@Sun.COM> <11814.86422.qm@web38103.mail.mud.yahoo.com> <20071130221159.GA2540@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071130221159.GA2540@Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.2 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db 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 On Fri, Nov 30, 2007 at 04:11:59PM -0600, Nicolas Williams wrote: > As a server vendor you can comply if we simply add a per-fsid option to > just-use-8. I.e., no need to throw out the baby with the bathwater. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 17:25: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 1IyEI7-0007Kz-BZ; Fri, 30 Nov 2007 17:24:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyEI6-0007Ks-VU for nfsv4@ietf.org; Fri, 30 Nov 2007 17:24:59 -0500 Received: from web38115.mail.mud.yahoo.com ([209.191.124.142]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IyEI6-0008LU-JY for nfsv4@ietf.org; Fri, 30 Nov 2007 17:24:58 -0500 Received: (qmail 63453 invoked by uid 60001); 30 Nov 2007 22:24:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=TeSnTqa/Ld7e+WHsBlEgblZZEdw0Ruk/Grxi7hvQ6L0Lo8typdoc+59/+QZo09rbzLBDKEGQh09xKa80ieYBBdtHAi0oqVXIHt8ejKDXRV/tozpFQVYgNOkVbH1j8EpBga3M/CtCtTC3ZDbawhcGC3a747YQxAZbPtWmLR40lV4=; X-YMail-OSG: sgrSW5sVM1ly6QCBmpunW4K7brzhlz4usQqapQnlWfPmyvVeZe5kDk.5J8ndI..SHW6aR7PzmB3QpWkCt4lwHenxMdfu5Zc9rdAgez5rcfP1MAFyPbycspJBUYtI.g-- Received: from [198.95.226.230] by web38115.mail.mud.yahoo.com via HTTP; Fri, 30 Nov 2007 14:24:57 PST Date: Fri, 30 Nov 2007 14:24:57 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071130221217.GK24887@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <943760.63299.qm@web38115.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- "J. Bruce Fields" wrote: > On Fri, Nov 30, 2007 at 01:57:55PM -0800, Mike Eisler wrote: > > If i18n stays in as is, then everyone (not just the clients, > > who never said a peep in 10 years that they would fail to comply) > > Not completely true: > > > http://playground.sun.com/pub/nfsv4/webpage/nfsv4-wg-archive-feb-03-feb-05/1176.html > > "Linux does no normalization or checking whatsoever at the VFS > level in order to enforce UTF-8" > Which is not semnantically the same as saying the Linux client did not and will never comply. Indeed Trond's complete statement was: ``This is the whole reason why Linux does no normalization or checking whatsoever at the VFS level in order to enforce UTF-8 (despite Linus' official position that only UTF-8 is guaranteed to be supported by the filesystems).'' One could infer many things but not that the Linux NFSv4 client not do checking. > Admittedly that may still have been too late (2004), and not clear > enough. (Though I'll admit I have not yet had the pleasure of > re-reading that thread in its entireity, so I may have missed some > more > relevant quote.) Too late for NFSv4.0, not too late for NFSv4.1 (around the same time, pnfs drafts were flying by). You Linux guys exercise your power to embrace and extend, so tell the rest of us what you are doing. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 17:29: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 1IyEMm-0000tl-GP; Fri, 30 Nov 2007 17:29:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyEMl-0000tc-8H for nfsv4@ietf.org; Fri, 30 Nov 2007 17:29:47 -0500 Received: from web38108.mail.mud.yahoo.com ([209.191.124.135]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyEMk-0005tl-TZ for nfsv4@ietf.org; Fri, 30 Nov 2007 17:29:47 -0500 Received: (qmail 34244 invoked by uid 60001); 30 Nov 2007 22:29:46 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=x7X3b4YCKpkGwP7O06x5Hgv/rOXWqKs31gOop3rHU0PlXYE/4iq52xGDAGRZ7I5w3XH7bO3PvYpu8S4coikWh1OoBBw/uLUFO2SEp7qO7Uh393kOTqv/Df7UwZ231VWI/1m8CMENpNbnNxV5+k0A8UWAloZ9f4jkH3+kx9KdIcY=; X-YMail-OSG: Cr.MKNQVM1meZ4FHIVvIBhouqS33i1V6uJxcW3TyQc4Vc15YHoXFx46XOEdLUuZAMfwbIWE8gw-- Received: from [198.95.226.230] by web38108.mail.mud.yahoo.com via HTTP; Fri, 30 Nov 2007 14:29:46 PST Date: Fri, 30 Nov 2007 14:29:46 -0800 (PST) From: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 To: nfsv4@ietf.org In-Reply-To: <20071130221627.GB2540@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <402388.34113.qm@web38108.mail.mud.yahoo.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: nfsv4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: email2mre-ietf@yahoo.com List-Id: NFSv4 Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nfsv4-bounces@ietf.org --- Nicolas Williams wrote: > On Fri, Nov 30, 2007 at 04:11:59PM -0600, Nicolas Williams wrote: > > As a server vendor you can comply if we simply add a per-fsid > option to > > just-use-8. > > I.e., no need to throw out the baby with the bathwater. Right instead just let the baby die of heat stroke in the sun. If an attribute, per fsid or per system (I'd recommend implementing it per system regardless) would allow us to reach consensus on changing i18n, I'd live with it. Indeed, it would give Dave others time to undo the beautiful UTF-8 translation code they wrote. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 17:35: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 1IyERr-0003I1-Fb; Fri, 30 Nov 2007 17:35:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyERp-0003EN-Kj for nfsv4@ietf.org; Fri, 30 Nov 2007 17:35:01 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyERo-0000i5-7V for nfsv4@ietf.org; Fri, 30 Nov 2007 17:35:01 -0500 Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUMYxUD007445 for ; Fri, 30 Nov 2007 22:34:59 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUMYxG9033395 for ; Fri, 30 Nov 2007 15:34:59 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUMYxbT004275; Fri, 30 Nov 2007 16:34:59 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUMYxdi004274; Fri, 30 Nov 2007 16:34:59 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 16:34:58 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130223458.GC2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <1196457177.9414.9.camel@heimdal.trondhjem.org> <712433.5442.qm@web38107.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <712433.5442.qm@web38107.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) 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 Fri, Nov 30, 2007 at 01:22:33PM -0800, Mike Eisler wrote: > The point is they apparently managed to do something. And even > if it was impossible, I'm OK with sacrificing an OPTIONAL feature. > If NFSv4.1 ever goes to DRAFT standard, if no one has done it, > then it goes away anyway. Or if it's something that the IETF feels strongly about then it doesn't go to Draft Standard. But we're likely to have at least two client and two server implementations that get I18N right. On the client side those would be: OpenSolaris (soon) and any Windows-based client. On the server side those would be MacOS X and OpenSolaris. By "soon" I mean" before any attempt to take NFSv4.1 to Draft Standard. > You are the one saying you will never commit to a character > set. If you don't like the consequences then make a different > commitment. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 17:50: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 1IyEgP-0003P8-BG; Fri, 30 Nov 2007 17:50:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyEgO-0003GM-11 for nfsv4@ietf.org; Fri, 30 Nov 2007 17:50:04 -0500 Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyEgN-0008WI-Dz for nfsv4@ietf.org; Fri, 30 Nov 2007 17:50:04 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUMo2qr013694 for ; Fri, 30 Nov 2007 22:50:02 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUMo1EP042804 for ; Fri, 30 Nov 2007 15:50:01 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUMo1iX004303; Fri, 30 Nov 2007 16:50:01 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUMnvDw004302; Fri, 30 Nov 2007 16:49:57 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 16:49:57 -0600 From: Nicolas Williams To: "Noveck, Dave" Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130224957.GE2540@Sun.COM> Mail-Followup-To: "Noveck, Dave" , Spencer Shepler , "J. Bruce Fields" , email2mre-ietf@yahoo.com, Theodore Tso , nfsv4@ietf.org, Trond Myklebust References: <20071130211105.GP2540@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: email2mre-ietf@yahoo.com, Theodore Tso , nfsv4@ietf.org, Trond Myklebust , "J. Bruce Fields" , Spencer Shepler 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 Fri, Nov 30, 2007 at 04:30:46PM -0500, Noveck, Dave wrote: > OK, do we have any clients that make effective provisions to send UTF-8 > component names? Given that lots don't, it wouldn't matter from a > practical point of view, but it would somehow make me feel better having > spent all this time on this, including coding the appropriate > translation on the fs side. > > Come on, is there even one client out there, who does this? Any that are running in UTF-8 locales, yes. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 18:57: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 1IyFjs-000779-8v; Fri, 30 Nov 2007 18:57:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyFjq-00076b-CI for nfsv4@ietf.org; Fri, 30 Nov 2007 18:57:42 -0500 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyFjo-0004Cy-TA for nfsv4@ietf.org; Fri, 30 Nov 2007 18:57:42 -0500 Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lAUNvdPt005854 for ; Fri, 30 Nov 2007 23:57:39 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id lAUNvdkH014087 for ; Fri, 30 Nov 2007 16:57:39 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id lAUNvdOt004373; Fri, 30 Nov 2007 17:57:39 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id lAUNvdOF004372; Fri, 30 Nov 2007 17:57:39 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 30 Nov 2007 17:57:39 -0600 From: Nicolas Williams To: Mike Eisler Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071130235738.GL2540@Sun.COM> Mail-Followup-To: Mike Eisler , nfsv4@ietf.org References: <20071130221627.GB2540@Sun.COM> <402388.34113.qm@web38108.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <402388.34113.qm@web38108.mail.mud.yahoo.com> User-Agent: Mutt/1.5.7i X-Spam-Score: -0.8 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Fri, Nov 30, 2007 at 02:29:46PM -0800, Mike Eisler wrote: > --- Nicolas Williams wrote: > > On Fri, Nov 30, 2007 at 04:11:59PM -0600, Nicolas Williams wrote: > > > As a server vendor you can comply if we simply add a per-fsid > > option to > > > just-use-8. > > > > I.e., no need to throw out the baby with the bathwater. > > Right instead just let the baby die of heat stroke in the sun. I think it's time to declare that sub-thread dead. You and I disagree about the likelyhood of having two client and server implementations that get I18N right. No need to pursue that. > If an attribute, per fsid or per system (I'd recommend implementing > it per system regardless) would allow us to reach consensus on > changing i18n, I'd live with it. Indeed, it would give Dave others > time to undo the beautiful UTF-8 translation code they wrote. I agree that having a per-fsid UTF-8/non-UTF-8 knob is desirable and would settle the issue (NOT per-system -- we need to support migration on a per-dataset basis). The only other protocol-level issue is whether the protocol should use an XDR type that might denote, to an XDR tool chain, that values of that type can only contain valid UTF-8 sequences -- but I think this is a non-issue today, and a warning in the text of the RFC would suffice to avoid it being an issue in the future. Nico -- _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4 From nfsv4-bounces@ietf.org Fri Nov 30 19:45: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 1IyGU9-000608-2o; Fri, 30 Nov 2007 19:45:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyGU7-0005zk-GG for nfsv4@ietf.org; Fri, 30 Nov 2007 19:45:31 -0500 Received: from mail.fieldses.org ([66.93.2.214] helo=fieldses.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyGU7-00036B-2p for nfsv4@ietf.org; Fri, 30 Nov 2007 19:45:31 -0500 Received: from bfields by fieldses.org with local (Exim 4.68) (envelope-from ) id 1IyGTq-0005tk-1i; Fri, 30 Nov 2007 19:45:14 -0500 Date: Fri, 30 Nov 2007 19:45:13 -0500 To: Trond Myklebust Subject: Re: [nfsv4] symlinks: opaque or UTF-8 Message-ID: <20071201004513.GB20587@fieldses.org> References: <1196458974.9414.24.camel@heimdal.trondhjem.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1196458974.9414.24.camel@heimdal.trondhjem.org> User-Agent: Mutt/1.5.17 (2007-11-01) From: "J. Bruce Fields" X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: email2mre-ietf@yahoo.com, Theodore Tso , Nicolas Williams , nfsv4@ietf.org, "Noveck, Dave" , Spencer Shepler 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 Fri, Nov 30, 2007 at 04:42:54PM -0500, Trond Myklebust wrote: > > On Fri, 2007-11-30 at 16:30 -0500, Noveck, Dave wrote: > > OK, do we have any clients that make effective provisions to send UTF-8 > > component names? Given that lots don't, it wouldn't matter from a > > practical point of view, but it would somehow make me feel better having > > spent all this time on this, including coding the appropriate > > translation on the fs side. > > > > Come on, is there even one client out there, who does this? > > I seem to remember the AIX guys asking questions about stringprepping a > year or two ago. Does anybody have a copy of their Red Book to check? http://www.redbooks.ibm.com/abstracts/sg246657.html A search for the text "utf-8" has two real hits: The mandatory features of the NFSv4 protocol as described in RFC 3530 are supported with the following exceptions: - The UTF8 requirements are not fully supported. - The LIPKEY and SPKM-3 security mechanisms are not supported with RPCSEC_GSS authentication. and NFSv4 introduces the following new tunable parameters: utf8 This option allows NFSv4 to perform UTF-8 checking. A value of 1 turns on UTF-8 checking of file names. A value of 0 turns it off. utf8_validation Enables checking of file names for the NFSv4 client and server to ensure that they conform to the UTF-8 specification. (How are they different? Who knows.) The wording definitely makes them sound like they just turn on some checks, rather than locale-dependent translations. Elsewhere it does say the both default to 1: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.cmds/doc/aixcmds4/nfso.htm --b. _______________________________________________ nfsv4 mailing list nfsv4@ietf.org https://www1.ietf.org/mailman/listinfo/nfsv4