On Wed, 2006-05-24 at 14:31 -0400, Trond Myklebust wrote: > On Wed, 2006-05-24 at 13:58 -0400, Jeff Moyer wrote: > > ==> Regarding [autofs] Re: [NFS] Re: [RFC] Multiple server selection and replicated mount failover; Trond Myklebust <trond.myklebust@xxxxxxxxxx> adds: > > > > trond.myklebust> On Wed, 2006-05-24 at 13:05 +0800, Ian Kent wrote: > > >> > 4) How does NFS v4 fit into this picture as I believe that some > > >> > of this functionality is included within the protocol. > > >> > > >> And this. > > >> > > >> NFS v4 appears quite different so should I be considering this for v2 and > > >> v3 only? > > > > trond.myklebust> NFSv4 has full support for migration/replication in the > > trond.myklebust> protocol. If a filesystem fails on a given server, then > > trond.myklebust> the server itself will tell the client where it can find > > trond.myklebust> the replicas. There should be no need to provide that > > trond.myklebust> information at mount time. > > > > And what happens when the server disappears? > > There are 2 strategies for dealing with that: > > Firstly, we can maintain a cache of the list of replica volumes (we can > request the list of replicas when we mount the original volume). > > Secondly, there are plans to add a backup list of failover servers in a > specialised DNS record. This strategy could be made to work for NFSv2/v3 > too. > I see. That would work fine. Personally, I'm not keen on using DNS for this as it adds another source, separate from the original source, that needs to be kept up to date. Unfortunately, in many environments it's not possible to deploy new services, often for several years after they become available. So there is a need to do this for v2 and v3 in the absence of v4. We at least need to support the mount syntax used in other industry OSs to round out the v2 and v3 implementation, so using mount seems the logical thing to do. I think this would also fit in well with v4 in that, as you mention above, the replica information needs to be gathered at mount time. I have the opportunity to spend some time on this now. Ideally I would like to fit in with the work that is being done for v4 as much as possible. For example I noticed references to a struct nfs_fs_locations in you patch set which may be useful for the information I need. However, I haven't spotted anything that relates to fail detection and fail over itself (ok I know you said your working on it) so perhaps I can contribute to this in a way that could help your v4 work. So what's you plan for this? Ian - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
