Subject: [nfsv4] 4.1 Exclisuve Create and pNFS support clarification

From: "Erasani, Pranoop" <[email-masked]>
Date: Wed, 20 Aug 2008 14:06:13 -0700

Hi Guys,
 
I'm a bit confused by the wording in the specification. Primarily around
the server support for pNFS or persistent sessions and when it should
support 4.1 exclusive create.
 
What does the second column below mean? Does is mean that v4.1 server
has pNFS support?
 
So effectively, if there is no persistent reply cache support on a pNFS
server, the only exclusive create the client is supposed to support is
EXCLUSIVE4_1.
 
The reason I'm asking is a client I'm looking at does not support it.
Just need some clarification around this.
 
Thanks,
- Pranoop

18.16.  Operation 18: OPEN - Open a Regular File

.......

With the addition of persistent sessions and pNFS, under some conditions
EXCLUSIVE4 MUST NOT be used by the client or supported by the server.
The following table summarizes the appropriate and mandated exclusive
create methods for implementations of NFSv4.1: 

________________________________

Required methods for exclusive create 

Persistent Reply Cache	 pNFS server	 Server REQUIRED	 Client
Allowed	
no	 no	 EXCLUSIVE4_1 and EXCLUSIVE4	 EXCLUSIVE4_1 (SHOULD)
or EXCLUSIVE4 (SHOULD NOT)	
no	 yes	 EXCLUSIVE4_1	 EXCLUSIVE4_1	
yes	 no	 GUARDED4	 GUARDED4	
yes	 yes	 GUARDED4	 GUARDED4	
 Table 18 
	
________________________________

   If CREATE_SESSION4_FLAG_PERSIST is set in the results of
CREATE_SESSION the reply cache is persistent (see Section 18.36
<http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-23#section-18
.36> ).  If   the EXCHGID4_FLAG_USE_PNFS_MDS flag is set in the results
from  EXCHANGE_ID, the server is a pNFS server (see Section 18.35
<http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-23#section-18
.35> ).  If the
   client attempts to use EXCLUSIVE4 on a persistent session, or a
session derived from a EXCHGID4_FLAG_USE_PNFS_MDS client ID, the
server MUST return NFS4ERR_INVAL.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Lisa Week <[email-masked]>
Date: Wed, 20 Aug 2008 16:26:40 -0600

Hi Pranoop,

Erasani, Pranoop wrote:
> Hi Guys,
>  
> I'm a bit confused by the wording in the specification. Primarily 
> around the server support for pNFS or persistent sessions and when it 
> should support 4.1 exclusive create.
>  

Yes, that is how I interpret it.  The second column is asking whether or 
not the NFSv4.1 server supports pNFS.

In other words, when you look at the values in that column, they can be 
thought of as answering the question: "Does the NFSv4.1 server support 
pNFS?". 

> So effectively, if there is no persistent reply cache support on a 
> pNFS server, the only exclusive create the client is supposed to 
> support is EXCLUSIVE4_1.

Yes, EXCLUSIVE4_1 is the only exclusive create the client can send in 
that case.
> Just need some clarification around this.
Hope that helps,
Lisa

>
> *18.16**.  Operation 18: OPEN - Open a Regular File*
> .......
>
> With the addition of persistent sessions and pNFS, under some 
> conditions EXCLUSIVE4 MUST NOT be used by the client or supported by 
> the server. The following table summarizes the appropriate and 
> mandated exclusive create methods for implementations of NFSv4.1:
>
> ------------------------------------------------------------------------
>
> Persistent Reply Cache 	pNFS server 	Server REQUIRED 	Client Allowed
> no 	no 	EXCLUSIVE4_1 and EXCLUSIVE4 	EXCLUSIVE4_1 (SHOULD) or 
> EXCLUSIVE4 (SHOULD NOT)
> * Table 18 *
> ------------------------------------------------------------------------
>  
> <http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-23#section-18.36>).  
> If   the EXCHGID4_FLAG_USE_PNFS_MDS flag is set in the results from  
> EXCHANGE_ID, the server is a pNFS server (see Section 18.35 
> <http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-23#section-18.35>).  
> If the
>    client attempts to use EXCLUSIVE4 on a persistent session, or 
> a session derived from a EXCHGID4_FLAG_USE_PNFS_MDS client ID, the   
> ------------------------------------------------------------------------
>

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 20 Aug 2008 16:30:28 -0700 (PDT)

Suggest new wording. Very soon.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: Lisa Week <[email-masked]>
Date: Wed, 20 Aug 2008 21:04:00 -0600

Hi,

I think the current wording is pretty clear, but something like this  
may remove any doubt.

For Table 10, Column 2: "Server supports pNFS"

Thanks,
Lisa

On Aug 20, 2008, at 5:30 PM, Mike Eisler wrote:

>>> <http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-23#section-18.36 
>>> >).
>>> <http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion1-23#section-18.35 
>>> >).
>>> If the

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Thu, 21 Aug 2008 01:38:26 -0700

Yes, if the second column is named "Server supports pNFS" and first column named "NFSv4.1 server supports persistent reply cache", that would be good.
 
Moreover, my original source of confusion was:
 
>>> the server.
 
I blanked just by reading this phrase in isolation:
 
With the addition of persistent sessions and pNFS

>>> mandated exclusive create methods for implementations of NFSv4.1:
 
<suggest>
 
NFSv4.1 client and server implementations MUST NOT use or support EXCLUSIVE4 exclusive create method, when the NFSv4.1 server supports persistent reply cache or pNFS. The following table summarizes the approriate combinations of exclusive create methods that need to be supported for various types of NFSv4.1 feature support.
 
</suggest>
 
I feel the word implementations does not reflect different sub-features of NFSv4.1.
 
Hope that was clear.
 
- Pranoop

From: Lisa Week [mailto:[email-masked]]
Sent: Wed 8/20/2008 8:04 PM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] 4.1 Exclisuve Create and pNFS support clarification

Hi,

Thanks,
Lisa

---

From: "Sergey Klyushin" <[email-masked]>
Date: Thu, 21 Aug 2008 08:32:59 -0400

Please ignore