Subject: RE: [nfsv4] location_info

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 30 Aug 2005 09:40:55 -0400

So I'd like to categorize such features in two ways.  One is the
distinction between the server being able to advertise to those
who ask it, the relevant information, and then further the
provision of that information via location_info to others so
that clients don't even have to bother asking the server.

The second distinction is between things which are per-server
such as I would assume that transport mechanism stuff would
be and stuff which is per-filesystem.  The pnfs stuff would
fit in that category since the client doesn't care so much
that the server supports pnfs in general but is more interested
in whether it provides it for the filesystem in which it is
going to access.

Now we can add a third dimention of depth.  For a lot of this 
information, the fact that we have support is just the beginning
of the client enquiries.  It has to be the sort of support he is
compatible with.  For RDMA, we have IB vs. iWARP and also there
will be issues about speed.  There will be a time when 4x IB
is ho-hum and there are clients who will say "12x or forget
about it".  For pNFS you have the issues of compatibility of the
data storage protocols and the degree of paralellism.

So I think the best way to address this is in stages.  The first
stage would be for the server to provide a per-fs transport_info 
attribute.  Given ongoing requirement this should be defined in
an extensible fashion.  Once that exists, I think it would be
quite reasonable to extend location_info to contain, as a 
convenience, the tarnsport_info for each of the replicas.  Given
that in many cases large numbers of servers will have the same
transport_info, I would have the location4_info contain a 
variable-length array of transport_info structures with each
location4_server containing an index that identifies which 
transport_info element applies to that replica.

An alternate way to address some of this would be to have the
client inform the server of his capabilities (at session create
time?) as to RDMA and pNFS capabilities.  Then the location_info
returned by the server would have its rank and order influenced
by the fact that having a RDMA-capable client access an RDMA-
capable server provides benefits whereas having only one side 
being capable of RDMA is of no value.  Similarly for pNFS of a 
particular style.

-----Original Message-----
From: Trond Myklebust [mailto:[email-masked]]
Sent: Friday, August 26, 2005 5:20 PM
To: Noveck, Dave
Cc: [email-masked]
Subject: Re: [nfsv4] location_info

fr den 26.08.2005 Klokka 16:30 (-0400) skreiv Noveck, Dave:

>      o    The server string.  For the case of the replica currently
>           being accessed (via GETATTR), a null string may be used to
>           indicate the current address.

One of the things I've wanted to see is for the server to be able to
advertise that it supports access via different transport mechanisms,
and to be able to list those transports to any given client.

IOW: As a client, I'd like to be able to figure out not only on which
server the replicas are hosted, but also whether or not I can use a
faster transport mechanism, such as RDMA, say, in order to access the
data. I would also be interested in figuring out whether or not a
particular replica might support a feature like parallel read/write
access via pNFS.

Do you have any thoughts about how to do this?

Cheers,
  Trond

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

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 30 Aug 2005 11:56:28 -0500

> transport_info element applies to that replica.

I would like to see a discussion of what problems we can solve
by providing transport information from the NFS server.

Traditionally, the transport has been chosen by the client by
an administrator via the mount.  Is the intention of server
provided transport info so the client can negotiate?  So the
general question is how will the client use transport information
and merge that with its own connectivity and priority of use or
policy.

Spencer

---

From: Jon Haswell <[email-masked]>
Date: Tue, 30 Aug 2005 13:04:19 -0700

[email-masked] wrote on 08/30/2005 06:40:55 AM:

<snip>

> being capable of RDMA is of no value.  Similarly for pNFS of a

I would like to put in my vote for this alternate option. In general as we
move forward and try and simplify systems and reduce the cost of
administering them I would like/expect to see more of the configuration and
setup and logic for system optimization to be done once at the server as
opposed to multiple times at each client (assuming we have more clients
than servers in the average organization). Hence in general I am in favour
of using the server to more firmly guide the clients as to what they should
access and how, as opposed to sending the clients all the possible options
which they then have to sort through, and potentially make random choices
from.

In general I think there is goodness in a client declaring it's
capabilities to a server which can then make decisions based on a central
policy database, current load conditions etc, as to how this client can be
serviced, or not serviced, or redirected etc. And while we could use this
central policy type control to simply restrict the options that the server
declares as being supported to a particular client it would seem better to
simplify modify and rank and order to directly point the client where we
want to go as opposed assuming the client will make the correct assumptions
from the other parameters returned.

Jon Haswell
IBM Research
Tel 408 927 2074 Tie 457 2074
Fax 408 927 3030 Tie 457 3030