Subject: [nfsv4] what does NFSv4.x look like and how is it managed...

From: Spencer <[email-masked]>
Date: Tue, 23 Mar 2010 17:58:15 -0500

With Dave Noveck's presentation today:

http://www.ietf.org/proceedings/10mar/slides/nfsv4-9.pdf

The discussion of what/how/when of NFSv4.x has again arisen.

The content of NFSv4.x has been captured with Mike's efforts here:

http://www.ietf.org/id/draft-eisler-nfsv4-minorversion-2-requirements-02.txt

In brief, our current charter includes:
	maintenance of NFSv4.0, NFSv4.1, RPC/XDR
	FedFS

To move forward with a charter update, some discussion of
the contents of NFSv4.2 requirements needs to occur.  Affirmation is
considered to be discussion.

In combination with the discussion, Brian and I will be working
on charter language and update process.

Dave's presentation has a lot of good ideas.  Please take some time
and review and comment.  We need to have discussion there as well
so we know how best to manage the content as we move forward.

Spencer

---

From: sfaibish <[email-masked]>
Date: Wed, 24 Mar 2010 13:00:41 -0400

Per our discussion during my Permission Access presentation to nfs4 WG I  
want
to ask the WG to review the draft and come back with comments:
http://www.ietf.org/id/draft-faibish-nfsv4-pnfs-access-permissions-check-02.txt

I would like also to ask to schedule some time to duiscuss this draft in
the NFSv4 in one of the Thursday FedFS calls.

Thank you

/Sorin

On Tue, 23 Mar 2010 18:58:15 -0400, Spencer <[email-masked]>  
wrote:

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

-- 
Best Regards

Sorin Faibish
Corporate Distinguished Engineer
Network Storage Group

         EMC²
where information lives

Phone: 508-435-1000 x 48545
Cellphone: 617-510-0422
Email : [email-masked]

---

From: Brian Wong <[email-masked]>
Date: Thu, 25 Mar 2010 10:22:35 -0400

sfaibish wrote:
> Per our discussion during my Permission Access presentation to nfs4 WG 
> I want
I am sympathetic to the fundamental idea that there has to be some 
greater client/mds/ds communication in the event of errors. I realize 
that the mds-to-ds communication is deliberately not specified, but I 
think we need to be a bit more proactive than that. In a system as 
complex as pNFS, at least some of the error handling really needs to 
include all of the interested parties. I'm happy to help draft something 
in this space, whether that's an amendment to this proposal or something 
new.

However, I am uncomfortable with the focus on permissions in this 
specific draft. Permissions are certainly an issue, and especially since 
some of the problematic things are sometimes well outside of the span of 
control of the likely administrator of a pNFS name space. (ie, FC 
switches are often administered by the networking organization, while 
the arrays typically are under the authority of the storage 
administrators; this division is even more prevalent if the storage 
protocol is iSCSI.)

However, there are many other errors that are architecturally similar, 
for example network partitions, where client-DS or MDS-DS is interrupted 
but the other path remains.  Or a node may have shut down due to thermal 
overload (or a crash). These errors must be handled too, and I suspect 
that there is an entire class of problems that is begging to be handled 
here.

Hopefully this isn't opening up Pandora's box. I'm not yet concerned 
about the protocol being too chatty as (a) I would expect the chatting 
to occur only upon error and (b) we should see what it looks like before 
we decide that it's too chatty.

On the draft itself, how do we propose to handle transitory errors? It 
is clear how permissions would be withdrawn, but I don't see how the 
situation would be reversed. Let's say that an array administrator 
erroneously sets a LUN mask to exclude all. It's clear that layouts will 
be recalled. Once the administrator corrects the problem, does the 
client have to re-issue the open? Suppose the problem is - effectively - 
permissions - but in the form of a zoning error in the switch? (This one 
might be as transitory as a reboot of an unfortunately located switch.) 
This will have some significant interaction with the notion of removing 
an "offending" device from the list of valid devices.

In section 3.3.3, what happens if the CB_LAYOUTACCESSCHECK returns 
inconsistent information? For example, if client A has a LUN mask to the 
SD, but client B does not?

Presumably in section 4.2 "client ... cannot write to the storage 
devices" really should be "access the storage devices" or is it a syntax 
error to have read-only access? I would have thought that a read-only 
open would not be at odds with lacking write access to the device.

blw

---

From: <[email-masked]>
Date: Thu, 25 Mar 2010 13:54:44 -0400

> I realize that the mds-to-ds communication is deliberately 
> not specified, but I think we need to be a bit more proactive 
> than that. 

The details of how the communications is done is not specified but the
requirements of what needs to be communicated can and should be
specified.  And further, the implementer is free to communicate more
information to make the system serviceable than the spec requires and I
expect typical implementations to do so.

The client-ds and client-mds communication is specified (and thus may be
unduly limited) and here we may need an expansion of what is
communicated to make the system more usable in the face of various
failures and misconfigurations.

I take your point that this should not be limited to permission issues.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian Wong
Sent: Thursday, March 25, 2010 10:23 AM
To: faibish, sorin
Cc: nfsv4 nfsv4
Subject: Re: [nfsv4] what does NFSv4.x look like and how is it
managed...

> to ask the WG to review the draft and come back with comments:
http://www.ietf.org/id/draft-faibish-nfsv4-pnfs-access-permissions-check
-02.txt 

new.

blw