Subject: RE: [nfsv4] location_info

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

I think the intention of putting it in location_info is 
allowing the client to select among multiple alternative
replicas, the one that meets his transport needs.  I
think the environment envisaged here is one in which,
at least in most cases, mounts occur as part descending a
large multi-fs multi-server namespace (often called a global
namespace but it isn't required that it actually be all-
encompassing).  If we are talking about a small number of
fs's mounted manually by an administrator, then the
tranditional ways of doing things you mention is quite
satisfactory.  If there are numerous replicas and they
may be going in and out of service and changing their 
capabilties, then the idea of making this available in a
standard way so that automated selection can occur becomes
important.  The big design issue then becomes to what 
degree the client and server each control this.  There are
two extreme models:  the client tells the server everything 
about what it needs and the server says use this, or the
server tells the client everything about the various replicas
and the client picks one.  I haven't embraced either of
those which just shows my wimpiness and lack of consistency,
or my moderation and good sense, according to how you choose 
to view it.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Tuesday, August 30, 2005 12:56 PM
To: [email-masked]
Subject: Re: [nfsv4] location_info

On Tue, Noveck, Dave wrote:
> 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.

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

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

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

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 30 Aug 2005 16:47:05 -0700

I think that the issue of providing transport information is more or
less unavoidable if you want to have automatic referring of a client
from one server to another. Unless you want to have the administrator
set up rules for each referral on each client (in which case, why bother
with the automatic referrals in the first place?) or have each client go
through extensive probing routines.

A few issues that spring to mind as being troublesome in the case of
automated referral by the server:

Firstly, some servers may have a preferred transport mechanism for a
particular client. For instance, some particular IPv4 subnet may be
known to be more secure/faster/less loaded/not firewalled off to outside
access/... 

Secondly, there is the whole issue of whether or not clients should be
relying on DNS

        Not all transport mechanisms may be advertised via DNS
        (RDMA/iWARP). (There is also the ubiquitous issue of whether or
        not we trust DNS in a secure context.)
        
        If anything, reverse DNS is worse: recognising when two
        different network addresses represent two different servers, and
        when they represent multiple paths to the same server is useful,
        but problematic. In the case where you have multiple paths to
        the same server, there are optimisation opportunities. For
        instance, the client may recognise the filesystem as one that is
        already mounted elsewhere, and/or it may wish to increase the
        available bandwidth by means of trunking.

Cheers,
  Trond