'browse mode' issue

'browse mode' issue

[Guillaume Rousse]

Hello list. I've several questions about browse mode option.

First, I have opposite reports about the effects of 'browse mode' option 
in automount configuration. Some times ago, a user reported than setting 
it to 'no' was CPU-unfriendly, so we turned it to 'yes' by default in 
mandriva package:
https://qa.mandriva.com/show_bug.cgi?id=31901

However, I now have another report than allowing browse was harmful on 
large networks, causing lots of IP collisions.

So, I'm curious at what should be a good default value for this option.

Second, having a look at the code, it seems 'yes' is the default in the 
binary, but, but default configuration file set it to 'no', which is 
quite disturbing. If there is a good default value for this option (and 
even if there was not), I'd rather have consistent default values in 
both places.

Last issue, I can't find a correct description on what this option does 
exactly anywhere :)
-- 
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62

Re: 'browse mode' issue

[Jeff Moyer]

Guillaume Rousse <Guillaume.Rousse@inria.fr> writes:

> Hello list. I've several questions about browse mode option.
>
> First, I have opposite reports about the effects of 'browse mode' option 
> in automount configuration. Some times ago, a user reported than setting 
> it to 'no' was CPU-unfriendly, so we turned it to 'yes' by default in 

That's the first time I've ever heard that!  What data did your user use
to support that conclusion?

> However, I now have another report than allowing browse was harmful on 
> large networks, causing lots of IP collisions.

My knowledge in this area is dated, sadly.  I'll let Ian address the
specific implementation details.

> So, I'm curious at what should be a good default value for this option.
>
> Second, having a look at the code, it seems 'yes' is the default in the 
> binary, but, but default configuration file set it to 'no', which is 
> quite disturbing. If there is a good default value for this option (and 
> even if there was not), I'd rather have consistent default values in 
> both places.

Well, for RHEL at least, we wanted to make things continue to work as
they did before.  That means configuring autofs to default to nobrowse.
I'm not sure why the daemon defaults to browsing.

> Last issue, I can't find a correct description on what this option does 
> exactly anywhere :)

http://docs.sun.com/app/docs/doc/816-0211/6m6nc66nc?a=view

Scroll down to the section entitled, "Browsing."

Cheers,

Jeff

Re: 'browse mode' issue

[Ian Kent]

On Mon, 2008-09-22 at 17:52 +0200, Guillaume Rousse wrote:
> Hello list. I've several questions about browse mode option.
> 
> First, I have opposite reports about the effects of 'browse mode' option 
> in automount configuration. Some times ago, a user reported than setting 
> it to 'no' was CPU-unfriendly, so we turned it to 'yes' by default in 
> mandriva package:
> https://qa.mandriva.com/show_bug.cgi?id=31901

That is a bit puzzling for sure.

Debugging this will be difficult but we would need to look at the debug
log and the maps at least.

> 
> However, I now have another report than allowing browse was harmful on 
> large networks, causing lots of IP collisions.

Setting browse to "yes" shouldn't make a great deal of difference for
small configurations but for large configurations it will impact both
CPU and network traffic.

If the maps are large then autofs needs to read the entire map at
startup and again every time it thinks there has been a change. This
will significantly impact network traffic. Also, given that we have a
large map and the mount point directories all exist, when an expire is
run every directory key must be checked which will lead to increased CPU
usage, mostly within the kernel module.

The exception to this is direct maps which must always be read at start
and when a change is detected, the difference being that the CPU
overhead during expire is largely within user space.

To make matters worse there may be a bug which causes maps to be re-read
more often than they need to be but that is quite hard to pick. Maybe a
debug log will give a clue as to whether this is the case.

> 
> So, I'm curious at what should be a good default value for this option.
> 
> Second, having a look at the code, it seems 'yes' is the default in the 
> binary, but, but default configuration file set it to 'no', which is 
> quite disturbing. If there is a good default value for this option (and 
> even if there was not), I'd rather have consistent default values in 
> both places.

That's right.

First the reason for this is that for the industry standard automounter
(not mentioning it by name) the default browse option is "yes" so the
program internal default is this but the version 4 default is "no".
Given the large map issue and the v4 default, the v5 default
configuration overrides this and sets it to "no". I hope that one day we
not need to override this in the configuration but that isn't the case
now.

Also, in v4 maps were always read entirely so it didn't make a lot of
difference but large maps were a killer so in v5 this was changed so
that, when browse is set to "no", maps (other than direct maps) are
never read in full so it can make a big difference. Once again the
reason for the over-ride in the configuration.  

> 
> Last issue, I can't find a correct description on what this option does 
> exactly anywhere :)

So the recommended setting for this is "no" for large maps and either
for smallish maps. Just what constitutes a "large" map is very much site
dependent but a couple of hundred entries is usually ok but a few
thousand almost certainly won't be.

Ian

Re: 'browse mode' issue

[Ondrej Valousek]

Nice information about the CPU involvement here.
I used to use (and I am still using) the browse to "yes" and it is much
less confusing for users I must say (never mind that you do not see the
directory, just cd into it anyway...), but then I introduced the wild
cards to reduce size of my maps. And obviously, the browse mode stopped
working (as it can not cover all possibilities the wild card gives).
But there is nothing we can do with, I guess......
Ondrej

Re: 'browse mode' issue

[Ian Kent]

On Tue, 2008-09-23 at 11:51 +0200, Ondrej Valousek wrote:
> Nice information about the CPU involvement here.
> I used to use (and I am still using) the browse to "yes" and it is much
> less confusing for users I must say (never mind that you do not see the
> directory, just cd into it anyway...), but then I introduced the wild
> cards to reduce size of my maps. And obviously, the browse mode stopped
> working (as it can not cover all possibilities the wild card gives).
> But there is nothing we can do with, I guess......

Yeah, it's a tricky.

Occasionally, suggestions have been made about this might be over come
but, in reality there are to may ways that this could go badly wrong to
tackle it. Maybe one day ...

Ian