Proposal to address issue 95

Noveck, Dave <Dave. Noveck <at> netapp.com>
2007-02-02 23:00:01 GMT

The description for GETATTR has a bunch of samll issues in addition
to the contradiction cited in issue 95.  We need to fix them.  Here
is the current text with some commentary, followed by a proposed
replacement. 
<t>
The GETATTR operation will obtain attributes for the file system
object specified by the current filehandle.  The client sets a bit
in
the bitmap argument for each attribute value that it would like
the
server to return.  The server returns an attribute bitmap that
indicates the attribute values for which it was able to return,
That seems to imply, especially the reference to "was able to return"
that the sets can be different, that GETATTR be asked for an attribute
and not be able to provide it, and not return an error. 
followed by the attribute values ordered lowest attribute number
first. 
</t>
<t>
The server must return a value for each attribute that the client
requests if the attribute is supported by the server. 
That suggests that the only reason the bit is not on is that the
attribute
is not supported by the server, which is consistent with the paragraph
above but in a confusing way, because the fact that the only bits which
may

Create Session for pNFS DS

Marc Eshel <eshel <at> almaden.ibm.com>
2007-02-04 20:39:59 GMT

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
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: Create Session for pNFS DS

Mike Eisler <email2mre-ietf <at> yahoo.com>
2007-02-05 13:15:28 GMT

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 ...
--- Marc Eshel <eshel <at> almaden.ibm.com> wrote:
> 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. 
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
> the

Re: Create Session for pNFS DS

Marc Eshel <eshel <at> almaden.ibm.com>
2007-02-05 17:34:00 GMT

Mike Eisler <email2mre-ietf <at> yahoo.com> wrote on 02/05/2007 05:15:28 AM:
> 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 ...
>
> --- Marc Eshel <eshel <at> almaden.ibm.com> wrote:
>
> > 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. 
>
> 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? 
Yes. 
> Are the device ids for multipled file systems to a particular
> DS shared, or is there a specific device-list for each

Re: Create Session for pNFS DS

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:
> Mike Eisler <email2mre-ietf <at> yahoo.com> wrote on 02/05/2007 05:15:28
> AM:
>
>> 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 ...
>>
>> --- Marc Eshel <eshel <at> almaden.ibm.com> wrote:
>>
>>> 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

Re: Create Session for pNFS DS

J. Bruce Fields <bfields <at> fieldses.org>
2007-02-05 20:13:28 GMT

On Mon, Feb 05, 2007 at 01:14:33PM -0600, Spencer Shepler wrote:
> 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? 
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. 
_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

Re: Create Session for pNFS DS

On Feb 5, 2007, at 2:13 PM, J. Bruce Fields wrote:
> On Mon, Feb 05, 2007 at 01:14:33PM -0600, Spencer Shepler wrote:
>> 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? 
>
> 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. 
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. 

Re: Create Session for pNFS DS

Marc Eshel <eshel <at> almaden.ibm.com>
2007-02-05 21:52:01 GMT

Spencer Shepler <Spencer. Shepler <at> Sun. COM> wrote on 02/05/2007 12:22:01 PM:
>
> On Feb 5, 2007, at 2:13 PM, J. Bruce Fields wrote:
>
> > On Mon, Feb 05, 2007 at 01:14:33PM -0600, Spencer Shepler wrote:
> >> 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? 
> >
> > 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. 
>
> 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

RE: Create Session for pNFS DS

Noveck, Dave <Dave. Noveck <at> netapp.com>
2007-02-05 22:53:59 GMT

Correct me if I'm wrong but it sure sounds to me like
your answer to Spencer's question about why metadata can
handle any number of fs's in a session (directing to
the appropriate implementation) while you require separate
sessions for eahc fs the data server is simply that that
is the way you have chosen to implement things. 
Is there some other reason that makes it particularly
desirable to have the protocol have sessions tied to
particular fs's?  I'm looking for something more general
than simply allowing you to maintain an implementation
choice you have made.  Offhand, it seems to me that sessions
are very near to the communication layer and I don't see
any obvious reason to tie them to file systems.  What am I
mssing? 
-----Original Message-----
From: Marc Eshel [mailto:eshel <at> almaden.ibm.com]
Sent: Monday, February 05, 2007 4:52 PM
To: Spencer Shepler
Cc: J. Bruce Fields; email2mre-ietf <at> yahoo.com; nfsv4 <at> ietf.org
Subject: Re: [nfsv4] Create Session for pNFS DS
Spencer Shepler <Spencer. Shepler <at> Sun. COM> wrote on 02/05/2007 12:22:01
PM:
>
> On Feb 5, 2007, at 2:13 PM, J. Bruce Fields wrote:
>
> > On Mon, Feb 05, 2007 at 01:14:33PM -0600, Spencer Shepler wrote:

Re: Create Session for pNFS DS

On Feb 5, 2007, at 4:53 PM, Noveck, Dave wrote:
> Correct me if I'm wrong but it sure sounds to me like
> your answer to Spencer's question about why metadata can
> handle any number of fs's in a session (directing to
> the appropriate implementation) while you require separate
> sessions for eahc fs the data server is simply that that
> is the way you have chosen to implement things. 
>
> Is there some other reason that makes it particularly
> desirable to have the protocol have sessions tied to
> particular fs's?  I'm looking for something more general
> than simply allowing you to maintain an implementation
> choice you have made.  Offhand, it seems to me that sessions
> are very near to the communication layer and I don't see
> any obvious reason to tie them to file systems.  What am I
> mssing? 
I agree in that the intent of sessions is to deal with
communication issues specific to NFS' use of an underlying
transport (multiple TCP connections over the lifetime of the
client/server interaction) and hence the need for the EOS. 
I can understand the requirement to deal with a system acting
as MDS and DS(es) and the need to effectively differentiate
and possibly linking the differentiation to the deviceid. 
Creating a relationship with individual filesystems seems
like a crossing of an architectural boundary that will eventually