Network File System Version 4 (nfsv4)

headers Marc Eshel | 1 Sep 2007 23:45

It looks like layoutreturn4 is missing from draft 13
Marc.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Noveck, Dave wrote:
>> I still feel uncomfortable with letting the server reassign client 
>> resources without fencing off clients 
> 
> As I understand it, your discomfort is due to the fact that you have no assurance that this approach can be
made to work reliably.  And that means not that you have individual working implementations, but that you
believe that you can define a protocol, which when correctly implemented, will prevent the corruption
you are worried about from ever happening.
> 
> On the other hand, we know the fencing approach would work and that is in line with all of the other pnfs
variants. 
> 
>> but I believe Dave B. that we're not making the current implementation any worse. 
> 
> I do also but I don't think that is the question.  Not requiring fencing seems that it would make the protocol
being specified worse (i.e. less reliable), compared to one that does require fencing.  If there is a
consensus that that gap can be closed so that we believe this change would not create a hole, then that would
be fine.
> 
> I'm not naïve.  I know that despite our best efforts including formal review, we may define things that
have holes in them.  We are doing our best to avoid them, mainly because dealing with holes found after the
fact is a real drag.  But we should not close our eyes to a hole that exists in a standards track protocol or
knowingly create one.
> 
> Here's where I think we should be.  In this I'm going to use SHOULD and MUST but since these statements are
about what the layout-specific protocols should or must do rather than implementations directly, I'm
not sure what verbiage is appropriate, but I hope I'm being clear in any case:
> 
> The protocol MUST ensure that when resources are transferred to another client, they are not used by the
client originally owning them and this must be ensured against any possible combination of partitions

Spencer,

I noticed that the link to "NFSv4.1 Draft-12" on
http://nfsv4-editor.org/drafts/drafts.html is wrong.
It points to draft-11 by mistake.

Benny

--

-- 
Benny Halevy
Software Architect
Tel/Fax: +972-3-647-8340
Mobile: +972-54-802-8340
US:      +1-412-203-3187
bhalevy <at> panasas.com

Panasas, Inc.
Leader in Parallel Storage
www.panasas.com

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Thanks. Will get it corrected in draft 14.  It is in the .x btw if
anyone needs the definition.

On Sep 1, 2007, at 4:45 PM, Marc Eshel wrote:

> It looks like layoutreturn4 is missing from draft 13
> Marc.
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4 <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Do you have a date for draft 14? We where wondering if to base the next 
bakeathon on draft 13 or 14 if it will be ready.
Marc.

Spencer Shepler <Spencer.Shepler <at> Sun.COM> wrote on 09/02/2007 08:22:55 AM:

> 
> Thanks. Will get it corrected in draft 14.  It is in the .x btw if
> anyone needs the definition.
> 
> On Sep 1, 2007, at 4:45 PM, Marc Eshel wrote:
> 
> > It looks like layoutreturn4 is missing from draft 13
> > Marc.
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4 <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/nfsv4
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4 <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

We are thinking that the majority of folks will be testing draft-13;

Is this true ?

Robert. 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Yes, the Liunx implementation will be at draft 13.
Marc.

Robert Gordon <Robert.Gordon <at> Sun.COM> 
09/04/2007 10:16 AM

To
NFSv4 <nfsv4 <at> ietf.org>
cc

Subject
[nfsv4] Umich Bake-off.

We are thinking that the majority of folks will be testing draft-13;

Is this true ?

Robert. 

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Will there be anyone there testing SSV?

Karen Rochford

Marc Eshel wrote:
> Yes, the Liunx implementation will be at draft 13.
> Marc.
>
>
>
>
> Robert Gordon <Robert.Gordon <at> Sun.COM> 
> 09/04/2007 10:16 AM
>
> To
> NFSv4 <nfsv4 <at> ietf.org>
> cc
>
> Subject
> [nfsv4] Umich Bake-off.
>
>
>
>
>
>
>
> We are thinking that the majority of folks will be testing draft-13;
>
> Is this true ?

Will there be anyone there testing SSV?

Karen Rochford

Marc Eshel wrote:
> Yes, the Liunx implementation will be at draft 13.
> Marc.
>
>
>
>
> Robert Gordon <Robert.Gordon <at> Sun.COM> 
> 09/04/2007 10:16 AM
>
> To
> NFSv4 <nfsv4 <at> ietf.org>
> cc
>
> Subject
> [nfsv4] Umich Bake-off.
>
>
>
>
>
>
>
> We are thinking that the majority of folks will be testing draft-13;
>
> Is this true ?

Benny has pointed out that the definition of deviceid4 changed between
drafts 12 and 13 from uint64_t to uint32_t.  This appears to be a  
clerical
error and it will be changed back to uint64_t in draft 14.

Spencer

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Mon	Tue	Wed	Thu	Fri	Sat	Sun

					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30

23	June 2013
208	May 2013
81	April 2013
31	March 2013
24	February 2013
40	January 2013
16	December 2012
72	November 2012
174	October 2012
56	September 2012
57	August 2012
47	July 2012
99	June 2012
174	May 2012
50	April 2012
85	March 2012
130	February 2012
75	January 2012
43	December 2011
40	November 2011
121	October 2011
197	September 2011
139	August 2011
143	July 2011
146	June 2011
169	May 2011
264	April 2011
197	March 2011
63	February 2011
37	January 2011
45	December 2010
125	November 2010
273	October 2010
128	September 2010
53	August 2010
97	July 2010
118	June 2010
42	May 2010
77	April 2010
144	March 2010
14	February 2010
60	January 2010
89	December 2009
28	November 2009
108	October 2009
157	September 2009
123	August 2009
53	July 2009
46	June 2009
67	May 2009
309	April 2009
101	March 2009
45	February 2009
41	January 2009
88	December 2008
63	November 2008
66	October 2008
14	September 2008
60	August 2008
8	July 2008
65	June 2008
143	May 2008
97	April 2008
195	March 2008
148	February 2008
136	January 2008
192	December 2007
355	November 2007
77	October 2007
83	September 2007
47	August 2007
116	July 2007
97	June 2007
38	May 2007
99	April 2007
47	March 2007
65	February 2007
87	January 2007
76	December 2006
48	November 2006
46	October 2006
106	September 2006
282	August 2006
287	July 2006
196	June 2006
91	May 2006
86	April 2006
220	March 2006
136	February 2006
95	January 2006
47	December 2005
135	November 2005
103	October 2005
97	September 2005
185	August 2005
111	July 2005
40	June 2005
39	May 2005
69	April 2005
81	March 2005
55	February 2005
19	January 2005
106	December 2004
104	November 2004
30	October 2004
53	September 2004
55	August 2004
66	July 2004
94	June 2004
59	May 2004
59	April 2004
28	March 2004
52	February 2004
120	January 2004
110	December 2003
26	November 2003
82	October 2003
105	September 2003
52	August 2003
25	July 2003
54	June 2003
106	May 2003
15	April 2003
68	March 2003
74	February 2003
69	January 2003
166	December 2002
83	November 2002
40	October 2002
55	September 2002
147	August 2002
144	July 2002
72	June 2002
59	May 2002
62	April 2002

draft 13 layoutreturn4

Re: RE: Client fencing

nfsv4-editor drafts page

Re: draft 13 layoutreturn4

Re: draft 13 layoutreturn4

Umich Bake-off.

Re: Umich Bake-off.

Re: Umich Bake-off.

Re: Umich Bake-off.

deviceid4 (uint64_t -> uint32_t -> uint64_t)