From: Vincent McIntyre <vincent.mcintyre@csiro.au>
To: Ian Kent <raven@themaw.net>
Cc: autofs@vger.kernel.org
Subject: Re: expected behaviour for replicated servers
Date: Fri, 16 Jun 2017 08:25:14 +1000 [thread overview]
Message-ID: <20170615222513.GA18515@mayhem.atnf.CSIRO.AU> (raw)
In-Reply-To: <1497523500.2650.3.camel@themaw.net>
Thanks for your reply
On Thu, Jun 15, 2017 at 06:45:00PM +0800, Ian Kent wrote:
> On Thu, 2017-06-15 at 17:52 +0800, Ian Kent wrote:
> > On Thu, 2017-06-15 at 12:19 +1000, Vincent McIntyre wrote:
> > > Hello
> > >
> > > I can't see this in the manpages or README.replicated-server,
> > > perhaps I can provide a patch...
> > >
> > > I have this setup:
> > >
> > > $ grep autofs /etc/nsswitch.conf
> > > autofs: files nis
> > >
> > > $ cat /etc/auto.master
> > > /nfs auto.nfs -rw,hard,intr,vers=3
> > > $ ypcat -k auto.nfs
> > > foo -ro,hard boxa,boxb:/export/foo
> > >
> > >
> > > Question:
> > >
> > > If boxa has the NFS server running (so autofs ping works)
> > > but does not export /export/foo,
> > > what is the expected behaviour?
> >
> > I haven't looked, so just I'll say what I think should happen.
> >
> > >
> > > boxa and boxb are in different subnets, the client is in
> > > the same subnet as boxa.
> >
> > If the network proximity code is working properly boxb probably
> > won't make it to the list of servers to try because it should
> > look like it's further away.
That makes some kind of sense, but see below.
> >
> > >
> > > What I am seeing is that the automount fails completely
> > > upon trying boxa. boxb is never tried (no request logged on boxb).
> > > Looking at the autofs debug log, I can see
> > > get_nfs_info called for boxa, twice in fact.
> > > For boxb, only get_supported_ver_and_cost is called,
> > > after which the daemon tries to mount the share from boxa.
> >
> > That's likely expected as I'm pretty sure I construct the list
> > of servers that have the selected characteristics including
> > proximity.
> >
> > For proximity it will check network address against local
> > interfaces to work that out so you probably shouldn't see an NFS
> > ping at all as that's used to establish best response amongst
> > the list of selected servers.
> >
> > I'd need to have a look at the code.
> >
> > >
> > >
> > > What I was hoping to see is that the client also tries boxb
> > > before giving up.
> > >
> > > I tried fiddling with:
> > > the order (boxb,boxa:/export/foo)
> > > weights (boxb(3),boxa:/export/foo),
> > > but none of this made any difference.
> >
> > If I'm right then boxb won't get onto the list of servers to try
> > so there's probably not much you can do about it, (again if I am
> > right) possibly it should change to include the further away
> > servers .... that might not be a straight forward change ...
>
> Actually it looks more like boxb should be added to the end of the
> list of servers to try.
>
> I see a bug in there but I don't think it's triggering. It's more
> likely there's been a problem connecting to boxb for some reason.
>
> The debug log might be useful but I'd probably still need to add
> some more debug log messages to work out what's going on.
>
Connection to boxb was working fine, I did a manual mount to check.
I was able to get the behaviour I wanted by adding --use-weight-only
(ie -w in auto.master) and not specifying any weights in auto.nfs.
Is it correct to say that --use-weight-only turns off all the
proximity heuristics ? I think not because autofs.master says
...If no server weights are given then each available server
will be tried in the order listed, within proximity.
But that manpage never mentions proximity anywhere else, so perhaps
it would be helpful to refer the reader to "the package's README files" ?
Going back over README.replicated-servers, it does not say anything
that suggests hosts are _left out_ of the priority-ordered list. So
perhaps there is a little buglet in there somewhere.
Vince
--
To unsubscribe from this list: send the line "unsubscribe autofs" in
prev parent reply other threads:[~2017-06-15 22:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-15 2:19 expected behaviour for replicated servers Vincent McIntyre
2017-06-15 9:52 ` Ian Kent
2017-06-15 10:45 ` Ian Kent
2017-06-15 22:25 ` Vincent McIntyre [this message]
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=20170615222513.GA18515@mayhem.atnf.CSIRO.AU \
--to=vincent.mcintyre@csiro.au \
--cc=autofs@vger.kernel.org \
--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 read-only IMAP folder(s) and NNTP newsgroup(s).