Subject: RE: [nfsv4] pNFS issues/changes (draft-welch-pnfs-ops-02.txt)

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 22 Jun 2005 06:55:08 -0400

> > You say "you should follow the layout instruction" and I'm torn
> > between saying "you SHOULD follow the layout instruction" and
> > "you MUST follow the layout instruction".
> > 
> > You say "[should] get an error if you don't" and I say "the server
> > SHOULD give you an error if you don't".
> 

> I say should follow and not MUST follow because I am trying to avoid the 
> complication to the server if it MUST enforce this rule which might not be 
> a problem for the server in the first place. 

Hold on.  I never suggested "MUST" for the server's obligation to check.
It seems that the server checking is where you see difficulties/inconvenience.

I did suggest "MUST" as a possiblility for the clients' obligation to 
conform.  These two do *not* have to go in tandem.  While it wouldn't make
any sense to have the client not have to conform while the server is giving
him an error if he doesn't, it is perfectly reasonable for the spec to
strongly state the rule for the client but not to insist that the server
check for compliance if it has great difficulties doing so.

> For example, I might want to 
> allow the read of the same large file(no caching) from one set of data 
> server for client A and a different set of data server for client B. Now 
> to enforce the above rule the server need to some how encode into the file 
> handle information about which client can read what from which data 
> server? 

I may not be uderstanding your example correctly but it sounds like the
case you are worried about is not really at issue here.

I prefer not have this added extra work on the server and just say 
that the client should follow the rule to guaranty successful operation. 

-----Original Message-----
From: Marc Eshel [mailto:[email-masked]]
Sent: Tuesday, June 21, 2005 6:27 PM
To: Noveck, Dave
Cc: Dean Hildebrand; Goodson, Garth; [email-masked];
[email-masked]
Subject: RE: [nfsv4] pNFS issues/changes (draft-welch-pnfs-ops-02.txt)

"Noveck, Dave" <[email-masked]> wrote on 06/21/2005 01:51:07 PM:

> > With fs-locations we give the client a list of metadata server 
> > that can act as the server for given filesystem and the client 
> > can choose which one to use and switch among them at will or 
> > because of some failure. 
> 
> The problem is that in v4.0 as it stands there is an enormous
> range of ways that a client can interpret the fs_locations list:
> 
> "Here is a list of servers and you can switch when there is failure,
> after refetching your change attibutes (because change attribute
> is within the purview of a particular server)."  (and that is not the
> most extreme case of discontinuity -- some people are thinking that 
> filehandles and fileids will just change or that you may wind up
> with a slighly out-of-data version of the data).
> 
> "Here is a list of servers and you can switch when there is a 
> failure with no discontinuity of access (changes in fh's, stateid's,
> fileids, change attributes), although changing is a big deal
> and you shouldn't do it without good cause."
> 
> "Here is a list of servers and you can switch when there is a
> failure with no discontinuity of access or even at will since
> there is no big cost to switch."
> 
> "Here is a list of servers and you can access any of these 
> servers as you will at the same time (multi-pathing or a 
> cluster fs) since they are all effectively the same thing".
> 
> The problem is that the client only knows about the list and
> has no way of knowing which of the statements above is associated
> with the list of servers he is getting.  I have been thinking
> about a locations_info attribute for 4.1 that would allow the
> server to tell the client which of those he meant and also 
> give preference information (local vs. remote copies, absolutely
> up-to-data vs. slightly out-of-data copies).
> 
> > is solely within the purview of a particular server
> 
> > I agree that once you got a layout for a file you should follow 
> > the layout instruction and read/write only from the specified 
> > nodes and get an error if you don't. 
> 
> Then it sounds like we are in violent agreement, except maybe for
> choice of modal auxiliaries or capitalization.
> 
> You say "you should follow the layout instruction" and I'm torn
> between saying "you SHOULD follow the layout instruction" and
> "you MUST follow the layout instruction".
> 
> You say "[should] get an error if you don't" and I say "the server
> SHOULD give you an error if you don't".
> 

I say should follow and not MUST follow because I am trying to avoid the 
complication to the server if it MUST enforce this rule which might not be 
a problem for the server in the first place. For example, I might want to 
allow the read of the same large file(no caching) from one set of data 
server for client A and a different set of data server for client B. Now 
to enforce the above rule the server need to some how encode into the file 
handle information about which client can read what from which data 
server? I prefer not have this added extra work on the server and just say 
that the client should follow the rule to guaranty successful operation. 
Marc. 

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

---

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 22 Jun 2005 06:57:19 -0400

Best to ignore the following for the moment.  Send hit inadvertantly.
Updated, more coherent message will be sent soon.

-----Original Message-----
From: Noveck, Dave 
Sent: Wednesday, June 22, 2005 6:55 AM
To: 'Marc Eshel'
Cc: Dean Hildebrand; Goodson, Garth; [email-masked];
[email-masked]

-----Original Message-----
From: Marc Eshel [mailto:[email-masked]]
Sent: Tuesday, June 21, 2005 6:27 PM
To: Noveck, Dave
Cc: Dean Hildebrand; Goodson, Garth; [email-masked];
[email-masked]