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

[<[e-mail]>]

> 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: [e-mail] [mailto:[e-mail]] 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...

sfaibish wrote:
> 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 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
>
> I would like also to ask to schedule some time to duiscuss this draft
in
> the NFSv4 in one of the Thursday FedFS calls. 

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