From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Ian Kent <raven@themaw.net>
Cc: nfs@lists.sourceforge.net,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
autofs mailing list <autofs@linux.kernel.org>
Subject: Re: [NFS] Re: [RFC] Multiple server selection and replicated mount failover
Date: Wed, 24 May 2006 12:29:16 -0400 [thread overview]
Message-ID: <1148488156.5872.42.camel@lade.trondhjem.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0605241240200.3730@raven.themaw.net>
On Wed, 2006-05-24 at 13:05 +0800, Ian Kent wrote:
> It seems to me that there are two similar ways to do this:
>
> 1) Pass a list of address and path entries to NFS at mount time and
> intercept errors, identify if the host is down and if it is select and
> mount another server.
>
> 2) Mount each member of the list with the best one on top and intercept
> errors, identify if the host is down and if it is select another from the
> list of mounts and put it atop the mounts. Maintaining the ordering with
> this approach could be difficult.
Solaris has implemented option (1). To me, that is the approach that
makes the most sense: why add the overhead of maintaining all these
redundant mounts?
> With either of these approaches handling open files and held locks appears
> to be the the difficult part.
Always has been, and always will. We're working on this problem, but
progress is slow. In any case, we'll be concentrating on solving it for
NFSv4 first (since that has native support for migrated/replicated
volumes).
> Anyone have anything to contribute on how I could handle this or problems
> that I will encounter?
>
>
> snip ..
>
> >
> > 3) Is there any existing work available that anyone is aware
> > of that could be used as a reference.
>
> Still wondering about this.
>
> >
> > 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?
NFSv4 has full support for migration/replication in the protocol. If a
filesystem fails on a given server, then the server itself will tell the
client where it can find the replicas. There should be no need to
provide that information at mount time.
Cheers,
Trond
next prev parent reply other threads:[~2006-05-24 16:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-02 5:56 [RFC] Multiple server selection and replicated mount failover Ian Kent
2006-05-24 5:05 ` Ian Kent
2006-05-24 13:02 ` [NFS] " Peter Staubach
2006-05-24 13:45 ` Ian Kent
2006-05-24 14:04 ` Peter Staubach
2006-05-24 14:31 ` Ian Kent
2006-05-24 20:45 ` [NFS] " John T. Kohl
2006-05-24 20:52 ` Dan Stromberg
2006-05-29 7:31 ` [autofs] " Ian Kent
2006-05-30 12:02 ` Jeff Moyer
2006-05-24 16:29 ` Trond Myklebust [this message]
2006-05-24 17:58 ` Jeff Moyer
2006-05-24 18:31 ` Trond Myklebust
2006-05-24 19:17 ` Peter Staubach
2006-05-24 19:45 ` Trond Myklebust
2006-05-25 3:56 ` Ian Kent
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1148488156.5872.42.camel@lade.trondhjem.org \
--to=trond.myklebust@fys.uio.no \
--cc=autofs@linux.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=nfs@lists.sourceforge.net \
--cc=raven@themaw.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).