From: "J. Bruce Fields" <bfields@fieldses.org>
To: 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: Tue, 14 Jun 2016 10:57:20 -0400 [thread overview]
Message-ID: <20160614145720.GC25973@fieldses.org> (raw)
In-Reply-To: <20160614001055.GB2634@us.ibm.com>
On Mon, Jun 13, 2016 at 07:10:56PM -0500, Malahal Naineni wrote:
> 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.
Oh, thanks for the reminder.
I wonder if the client's closer to ready for failover support now. I
don't remember what the issues were.
--b.
next prev parent reply other threads:[~2016-06-14 14:57 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
2016-06-14 14:57 ` J. Bruce Fields [this message]
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=20160614145720.GC25973@fieldses.org \
--to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.