headers
Noveck, Dave | 3 Feb 2007 00:00
Picon

Proposal to address issue 95

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Eshel | 4 Feb 2007 21:39
Picon
Favicon

Create Session for pNFS DS

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
Permalink | Reply | 6 comments |
headers
Mike Eisler | 5 Feb 2007 14:15
Picon
Favicon

Re: Create Session for pNFS DS

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
(Continue reading)

Permalink | Reply | 5 comments |
headers
Marc Eshel | 5 Feb 2007 18:34
Picon
Favicon

Re: Create Session for pNFS DS

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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Spencer Shepler | 5 Feb 2007 20:14
Picon

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
(Continue reading)

Permalink | Reply | 3 comments |
headers
J. Bruce Fields | 5 Feb 2007 21:13

Re: Create Session for pNFS DS

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
Permalink | Reply | 2 comments |
headers
Spencer Shepler | 5 Feb 2007 21:22
Picon

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.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marc Eshel | 5 Feb 2007 22:52
Picon
Favicon

Re: 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:
> >> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Noveck, Dave | 5 Feb 2007 23:53
Picon

RE: Create Session for pNFS DS

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:
(Continue reading)

Permalink | Reply | 5 comments |
headers
Spencer Shepler | 6 Feb 2007 00:16
Picon

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
(Continue reading)

Permalink | Reply | 4 comments |

Gmane