Subject: [nfsv4] Create Session for pNFS DS

From: Marc Eshel <[email-masked]>
Date: Sun, 4 Feb 2007 12:39:59 -0800

I wanted to share some suggestion that Andy made to solve a problem that 
we have with create session on the DS. We would like to associate the 
session with a particular file system. The Linux NFS server implementation 
is using a single front end for multiple backend file system so we need 
some way to associate the sessions with a particular backend file system. 
The suggestion is to return a file handle with get-device-list from the 
server (at this point a specific fs is providing the device list) and than 
the NFS client should present that file handle to the DS at create 
session. The client must anyhow have the device list before it can create 
sessions with the DSs. This will help us validate the create session with 
the DS, since the backend communication is the through the file system, 
and also create different session for different file systems. Any 
implementation that does not need it can just pass an empty file handle. 
Please give it some though and we can discuss it further at the 
connectathon this week.
Marc. 

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

---

From: Mike Eisler <[email-masked]>
Date: Mon, 5 Feb 2007 05:15:28 -0800 (PST)

Mark,

I'm scheduled to be at Connectathon later today and will be happy to
discuss this and any other session issues in the spec.

Some comments below ...

> some way to associate the sessions with a particular backend file

Is the idea that over a common server network address, the Linux
server implementation would prefer to bind a file system to
a particular session?

Are the device ids for multipled file systems to a particular
DS shared, or is there a specific device-list for each
file system? Also do the device-lists have a non-empty intersection?

> The suggestion is to return a file handle with get-device-list from

Since file handles are opaque, I wonder if you meant fsid
and not file handle?

---

From: Marc Eshel <[email-masked]>
Date: Mon, 5 Feb 2007 09:34:00 -0800

> server implementation would prefer to bind a file system to

Yes.
 
> file system? Also do the device-lists have a non-empty intersection?

There is a device-list for each fs each with its own device ids but they 
might use the same DSs. 

> Since file handles are opaque, I wonder if you meant fsid

No, I meant file handle. We already use this technic of returning special 
fh from the MDS in the layout with information that the DS can use to 
validate the file state for IO requests. The client doesn't need to 
interpret the fh just keep it with the device list and pass it to the DS 
on session create.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 05 Feb 2007 13:14:33 -0600

Marc,

Can you explain further as to why there must be multiple sessions
at the DS when that is unnecessary at the MDS even though both
may be servicing different filesystems?

Is there a session construct that you see bound to the underlying  
filesystem?

Spencer

On Feb 5, 2007, at 11:34 AM, Marc Eshel wrote:

>>> server (at this point a specific fs is providing the device list)  
>>> and
>>> than

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 5 Feb 2007 15:13:28 -0500

> may be servicing different filesystems?

It's possible that a single host could have multiple roles--as a
metadata server, or as a data server to any of several possible metadata
servers.  The host needs to know which role it's playing before it can
respond to a given request.  So the metadata server needs to insert this
role information into something that the client will pass to the data
server.

Prototypes have been using the filehandle for this.  Maybe the clientid
could be used instead?  But the clientid is smaller and already subject
to a number of other requirements (to identify stale clientid's, etc.),
so that carving up the clientid space between metadata servers may
require more complicated coordination.

--b.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 05 Feb 2007 14:22:01 -0600

> require more complicated coordination.

Ah, okay, this is what I was looking for...  It isn't tied to the
underlying filesystem but the potential dual-role that a server may
be playing.

This issue has arisen recently and a couple of us, including Mike, have
been thinking about how to differentiate for this reason but for
others as well (to correctly set up the initial sequencing of the
session with the data-server as well).

So, the requirement is the ability of differentiating the multiple
roles a server may be playing and ensuring that we have a method
of allowing the server to communicate that view to itself through
the normal client interaction of the pNFS behavior?

Spencer

---

From: Marc Eshel <[email-masked]>
Date: Mon, 5 Feb 2007 13:52:01 -0800

> underlying filesystem but the potential dual-role that a server may

This for both the dual-role and the need to associate create session with 
an underlying file system so we can know which one to use to validate the 
session on the DS. In the Linux server implementation all the 
communication among the machines are through the backend file system.
Marc.