Subject: [nfsv4] Potential NFS4.2 item: Operation/Attribute to get list of servers that form trunked relationship

From: "Erasani, Pranoop" <[email-masked]>
Date: Wed, 19 Aug 2009 21:35:22 -0700

Hello,
 
Something that popped in my head while I was reading the pNFS
multipathing section today. Since we are thinking about nfsv4.2, I think
it would be nice to consider this as a candidate.
 
I was looking at the session/client trunking aspects of nfsv4.1 and I
see that client can take advantage of the trunking (and thus servers
could be happy about trunking is being used) only when the client
mounted all the server IP addresses. Basically, That involves some
explicit setup on the client.
 
To eliminate the setup, the protocol could provide operation/attribute
that client could query in nfsv4.x that would enable server to send list
of server ip addresses that would form a clientid/session trunking
relationship. This information could be used by the client to start
initiating sessions towards those servers at the initial mount time
itself.
 
Let me know, if that makes sense. Let me know, if it does not make sense
too.

- Pranoop

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 20 Aug 2009 08:46:11 -0400

Just to make sure I'm clear about this.  
 
As I see it, there is sufficient information to get the trunking
information once you get the layout.  
 
There may be situations in which one MDS corresponds to a very large set
of DS's such that it doesn't make sense to connect to them until you get
a particular layout since you may not reference many of the DS's.
However, in most cases it would be establish the sessions as early as
you can, and not have to wait until you actually opened a file to do
that.
 
If that's the issue, my suggestion would be to do this via an extension
to the fs_locations_info attribute.  If we defined MDS and DS flag bits
for the fs_locations_server structure, the client could fetch this
attribute and establish the sessions at mount time.

________________________________

From: Erasani, Pranoop 
Sent: Thursday, August 20, 2009 12:35 AM
To: [email-masked]
Subject: [nfsv4] Potential NFS4.2 item: Operation/Attribute to get list
ofservers that form trunked relationship

Hello,

 

- Pranoop

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Thu, 20 Aug 2009 09:16:39 -0700

From: Noveck, Dave 
	Sent: Thursday, August 20, 2009 5:46 AM
	To: Erasani, Pranoop; [email-masked]
	Subject: RE: [nfsv4] Potential NFS4.2 item: Operation/Attribute
to get list ofservers that form trunked relationship

	 
	Yes, Like I mentioned in offline thread, pNFS multipathing
device addresses is one way to look at this. But, it does't solve the
problem for non-pnfs deployments. 
	 
	There may be situations in which one MDS corresponds to a very
large set of DS's such that it doesn't make sense to connect to them
until you get a particular layout since you may not reference many of
the DS's.  However, in most cases it would be establish the sessions as
early as you can, and not have to wait until you actually opened a file
to do that.
	 
	If that's the issue, my suggestion would be to do this via an
extension to the fs_locations_info attribute.  If we defined MDS and DS
flag bits for the fs_locations_server structure, the client could fetch
this attribute and establish the sessions at mount time.
	 
	I believe that we should not explicitly tie this upto MDS and
DS. I think the problem is trunking will be done independent of pNFS and
for that reason we are better off, defining a new attribute.
	 
	- Pranoop

	From: Erasani, Pranoop 
	Sent: Thursday, August 20, 2009 12:35 AM
	To: [email-masked]
	Subject: [nfsv4] Potential NFS4.2 item: Operation/Attribute to
get list ofservers that form trunked relationship

	Hello,

	I was looking at the session/client trunking aspects of nfsv4.1
and I see that client can take advantage of the trunking (and thus
servers could be happy about trunking is being used) only when the
client mounted all the server IP addresses. Basically, That involves
some explicit setup on the client.
	 
	To eliminate the setup, the protocol could provide
operation/attribute that client could query in nfsv4.x that would enable
server to send list of server ip addresses that would form a
clientid/session trunking relationship. This information could be used
by the client to start initiating sessions towards those servers at the
initial mount time itself.
	 
	Let me know, if that makes sense. Let me know, if it does not
make sense too.
	
	- Pranoop

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 20 Aug 2009 12:56:16 -0400

> I think the problem is trunking will be done independent of pNFS 
 
Agreed.
 
> and for that reason we are better off, defining a new attribute.
 
and that's exactly the reason that I don't think we should have a
separate attribute.
 
fs_locations_info is the way provided currently to find about all paths
to get to a partticular set of data and their priorities, ability to be
used concurrently (most often in the form of trunking). , etc.The fact
that it doesn't cover DS's is just an oversight that reflects the fact
that pnfs was not so far along at the time that chapter was written.
 
Thinking about the issue of whether we write a single spec or multiple
ones, you could argue this both ways.  You could say that because they
were treated as separate items, the need to update this for pnfs was
forgotten about and that making them separate documents would make that
even worse.  The alternative argument wold be that the fact that they
were separate documents would essentially force you to make an important
part of the review program considering such interactions.  The latter is
probably true until N*(N-1)/2 gets above 10, i.e. N <= 5.  Anyway, this
is speculation.

From: Erasani, Pranoop 
Sent: Thursday, August 20, 2009 12:17 PM
To: Noveck, Dave; [email-masked]'
Subject: RE: [nfsv4] Potential NFS4.2 item: Operation/Attribute to get
list ofservers that form trunked relationship

	From: Noveck, Dave 

	 

	 
	 
	- Pranoop

	From: Erasani, Pranoop 

	Hello,

	 

	- Pranoop

---

From: "Erasani, Pranoop" <[email-masked]>
Date: Thu, 20 Aug 2009 09:59:48 -0700

From: Noveck, Dave 
	Sent: Thursday, August 20, 2009 9:56 AM
	To: Erasani, Pranoop; [email-masked]'
	Subject: RE: [nfsv4] Potential NFS4.2 item: Operation/Attribute
to get list ofservers that form trunked relationship

	Agreed.
	 
	> and for that reason we are better off, defining a new
attribute.
	 
	and that's exactly the reason that I don't think we should have
a separate attribute.
	 
	fs_locations_info is the way provided currently to find about
all paths to get to a partticular set of data and their priorities,
ability to be used concurrently (most often in the form of trunking). ,
etc.The fact that it doesn't cover DS's is just an oversight that
reflects the fact that pnfs was not so far along at the time that
chapter was written. 
	 
	Now, I see what you mean. Fine with me, if you think this is the
better way to address this.
	 
	- Pranoop 
	 
	Thinking about the issue of whether we write a single spec or
multiple ones, you could argue this both ways.  You could say that
because they were treated as separate items, the need to update this for
pnfs was forgotten about and that making them separate documents would
make that even worse.  The alternative argument wold be that the fact
that they were separate documents would essentially force you to make an
important part of the review program considering such interactions.  The
latter is probably true until N*(N-1)/2 gets above 10, i.e. N <= 5.
Anyway, this is speculation.

	From: Erasani, Pranoop 

		From: Noveck, Dave 
		Sent: Thursday, August 20, 2009 5:46 AM
		To: Erasani, Pranoop; [email-masked]
		Subject: RE: [nfsv4] Potential NFS4.2 item:
Operation/Attribute to get list ofservers that form trunked relationship

		As I see it, there is sufficient information to get the
trunking information once you get the layout.  
		 
		Yes, Like I mentioned in offline thread, pNFS
multipathing device addresses is one way to look at this. But, it does't
solve the problem for non-pnfs deployments. 
		 
		There may be situations in which one MDS corresponds to
a very large set of DS's such that it doesn't make sense to connect to
them until you get a particular layout since you may not reference many
of the DS's.  However, in most cases it would be establish the sessions
as early as you can, and not have to wait until you actually opened a
file to do that.
		 
		If that's the issue, my suggestion would be to do this
via an extension to the fs_locations_info attribute.  If we defined MDS
and DS flag bits for the fs_locations_server structure, the client could
fetch this attribute and establish the sessions at mount time.
		 
		I believe that we should not explicitly tie this upto
MDS and DS. I think the problem is trunking will be done independent of
pNFS and for that reason we are better off, defining a new attribute.
		 
		- Pranoop

		From: Erasani, Pranoop 
		Sent: Thursday, August 20, 2009 12:35 AM
		To: [email-masked]
		Subject: [nfsv4] Potential NFS4.2 item:
Operation/Attribute to get list ofservers that form trunked relationship

		Hello,
		 
		Something that popped in my head while I was reading the
pNFS multipathing section today. Since we are thinking about nfsv4.2, I
think it would be nice to consider this as a candidate.
		 
		I was looking at the session/client trunking aspects of
nfsv4.1 and I see that client can take advantage of the trunking (and
thus servers could be happy about trunking is being used) only when the
client mounted all the server IP addresses. Basically, That involves
some explicit setup on the client.

		Let me know, if that makes sense. Let me know, if it
does not make sense too.
		
		- Pranoop