expected behaviour for replicated servers

expected behaviour for replicated servers

[Vincent McIntyre]

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?

boxa and boxb are in different subnets, the client is in
the same subnet as boxa.

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.


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.

This happens to be  5.0.8-2+deb8u1 but that's probably irrelevant.

Kind regards
Vince
--
To unsubscribe from this list: send the line "unsubscribe autofs" in

Re: expected behaviour for replicated servers

[Ian Kent]

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.

> 
> 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 ...

Ian
--
To unsubscribe from this list: send the line "unsubscribe autofs" in

Re: expected behaviour for replicated servers

[Ian Kent]

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.
> 
> > 
> > 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.

Ian
--
To unsubscribe from this list: send the line "unsubscribe autofs" in

Re: expected behaviour for replicated servers

[Vincent McIntyre]

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