Linux NFS development
 help / color / mirror / Atom feed
From: Malahal Naineni <malahal@us.ibm.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: sebastien cabaniols <sebastien.cabaniols@gmail.com>,
	linux-nfs@vger.kernel.org
Subject: Re: does the linux NFS client support for failover to a replica share (read-only share)
Date: Mon, 13 Jun 2016 19:10:56 -0500	[thread overview]
Message-ID: <20160614001055.GB2634@us.ibm.com> (raw)
In-Reply-To: <20160613155237.GC17866@fieldses.org>

J. Bruce Fields [bfields@fieldses.org] wrote:
> On Tue, Jun 07, 2016 at 10:02:19PM +0200, sebastien cabaniols wrote:
> > Hello linux-nfs mailing list.
> > 
> > I would like to know if the linux nfs client included in current
> > versions of the kernel supports fail-over to a replica on another nfs
> > server, I am using (manually) synchronized read-only shares...
> > 
> > I found very few information on Google about this topic and I suspect
> > this is not implemented.
> 
> That's correct (unless I've missed something!).
> 
> > I actually tried to setup this using SLES12SP1 (3.12.49 kernel) but I
> > failed so far. I am not attached to this distribution/version in
> > particular, just trying to see it working for real.
> > 
> > ( I did some "rpcdebug -m nfs" session and it seems the fs_locations
> > is not getting properly populated on my setup )
> > 
> > Any confirmation this should work or not would actually help me.
> > 
> > THX.
> > 
> > 
> > note from the exports man page:
> > 
> >        replicas=path@host[+host][:path@host[+host]]
> >               If  the  client  asks for alternative locations for the
> > export point, it will be given this list of alternatives.
> >               (Note that actual replication of the filesystem must be
> > handled elsewhere.)
> 
> Yes, the server side (assuming you've got the backend replication
> working) is pretty easy, and should work (though I don't know if it's
> gotten any testing).

Bruce, we did test the server side couple years ago. I don't remember
any issues on the server side. We did some rudimentary support on the
client side (we were using rsync for replication and our exports were
read-only!). I remember "find" having an issue with inode number change
while it was running, but don't remember any other issues. The client
patches never made it to mainline though.

Regards, Malahal.


  reply	other threads:[~2016-06-14  0:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-07 20:02 does the linux NFS client support for failover to a replica share (read-only share) sebastien cabaniols
2016-06-13 15:52 ` J. Bruce Fields
2016-06-14  0:10   ` Malahal Naineni [this message]
2016-06-14 14:57     ` J. Bruce Fields
2016-06-14 16:56       ` sebastien cabaniols

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=20160614001055.GB2634@us.ibm.com \
    --to=malahal@us.ibm.com \
    --cc=bfields@fieldses.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=sebastien.cabaniols@gmail.com \
    /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