/net support

/net support

[David Meleedy]

Are there any plans to implement this correctly?  We are seeing
problems with the auto.net script that just loads up every
directory provided by the machine.  For example some of our
fileservers have a lot of mounts, and this can really start
filling up the mount table.  Also, some fileservers let certain
clients mount some of the directories provided but not others.
The error messages are confusing our user's because they are
trying to cd to:

/net/<machine_name>/foo
and they see an error message about not being able to mount
/net/<machine_name>/goo

It would be a lot cleaner if only the directory you are cd'ing
to got mounted instead of every directory.


Thanks,

-Dave

________________________________________________________________________
David Meleedy				Analog Devices, Inc.
David.Meleedy@analog.com		Three Technology Way
Phone: 781 461 3494			Norwood, MA  02062-9106  USA

Re: /net support

[Jeff Moyer]

==> Regarding [autofs] /net support; David Meleedy <david.meleedy@analog.com> adds:

david.meleedy> Are there any plans to implement this correctly?  We are
david.meleedy> seeing problems with the auto.net script that just loads up
david.meleedy> every directory provided by the machine.  For example some
david.meleedy> of our fileservers have a lot of mounts, and this can really
david.meleedy> start filling up the mount table.  Also, some fileservers
david.meleedy> let certain clients mount some of the directories provided
david.meleedy> but not others.  The error messages are confusing our user's
david.meleedy> because they are trying to cd to:

david.meleedy> /net/<machine_name>/foo and they see an error message about
david.meleedy> not being able to mount /net/<machine_name>/goo

david.meleedy> It would be a lot cleaner if only the directory you are
david.meleedy> cd'ing to got mounted instead of every directory.

Autofs version 5 gets this right.

-Jeff

Re: /net support

[Ian Kent]

On Fri, 2006-10-27 at 16:22 -0400, David Meleedy wrote:
> Are there any plans to implement this correctly?  We are seeing
> problems with the auto.net script that just loads up every
> directory provided by the machine.  For example some of our
> fileservers have a lot of mounts, and this can really start
> filling up the mount table.  Also, some fileservers let certain
> clients mount some of the directories provided but not others.
> The error messages are confusing our user's because they are
> trying to cd to:
> 
> /net/<machine_name>/foo
> and they see an error message about not being able to mount
> /net/<machine_name>/goo
> 
> It would be a lot cleaner if only the directory you are cd'ing
> to got mounted instead of every directory.

As Jeff says, autofs version 5 works in a similar way to other
automounters now, by mounting (and expiring) the exported shares as you
go.

There is also a built in "-hosts" map now.

However, I've recently discovered that I haven't covered some of the
export access control syntax used by Solaris servers so you may still
need to use the auto.net script.

This issue will never be fixed in version 4 because version 4 cannot
handle the nesting of mounts found in server export lists.

Ian

Re: /net support

[David Meleedy]

> As Jeff says, autofs version 5 works in a similar way to other
> automounters now, by mounting (and expiring) the exported shares as you
> go.
> 
> There is also a built in "-hosts" map now.
> 
> However, I've recently discovered that I haven't covered some of the
> export access control syntax used by Solaris servers so you may still
> need to use the auto.net script.
> 
> This issue will never be fixed in version 4 because version 4 cannot
> handle the nesting of mounts found in server export lists.

One other thing I am wondering about regarding this issue.  I had
discovered that at our site, we had to modify the /etc/auto.net script
to return different -fstype options depending on whether or not the
machine was on the LAN vs. on the WAN.  It turns out we needed to
turn on tcp version 3 for our WAN mounts because udp mounts would hang
once you tried to access the filesystem at all with "ls" or whatever.

So for example, here is what we are doing for LAN vs. WAN:

(here you can see "jetcar" a LAN mount vs. "siren" a WAN mount)

codered-302: cd /etc
codered-303: auto.net jetcar
-fstype=nfs,hard,intr,nodev,nosuid \
        /export/jetcar1 jetcar:/export/jetcar1 \
        /export/jetcar2 jetcar:/export/jetcar2
codered-304: auto.net siren
-fstype=nfs,hard,intr,nodev,nosuid,bg,tcp,vers=3 \
        /vol/vol0 siren:/vol/vol0 \
        /vol/vol0/backups siren:/vol/vol0/backups \
        /vol/vol0/proj siren:/vol/vol0/proj \
        /vol/vol1 siren:/vol/vol1 \
        /vol/vol1/proj siren:/vol/vol1/proj


I am wondering if we switch to using "-hosts" which I would really
prefer to do given that I wouldn't want a client to mount everything
provided by a server.  Is there a way to have different fstype options
happen on a per machine basis? (I am assuming you don't do that right now,
but I thought I would submit this concept to see if you have any ideas
on how to do this).

Thanks,

-Dave


________________________________________________________________________
David Meleedy				Analog Devices, Inc.
David.Meleedy@analog.com		Three Technology Way
Phone: 781 461 3494			Norwood, MA  02062-9106  USA

Re: /net support

[Jeff Moyer]

==> Regarding Re: [autofs] /net support; David Meleedy <david.meleedy@analog.com> adds:

>> As Jeff says, autofs version 5 works in a similar way to other
>> automounters now, by mounting (and expiring) the exported shares as you
>> go.
>> 
>> There is also a built in "-hosts" map now.
>> 
>> However, I've recently discovered that I haven't covered some of the
>> export access control syntax used by Solaris servers so you may still
>> need to use the auto.net script.
>> 
>> This issue will never be fixed in version 4 because version 4 cannot
>> handle the nesting of mounts found in server export lists.

david.meleedy> One other thing I am wondering about regarding this issue.
david.meleedy> I had discovered that at our site, we had to modify the
david.meleedy> /etc/auto.net script to return different -fstype options
david.meleedy> depending on whether or not the machine was on the LAN
david.meleedy> vs. on the WAN.  It turns out we needed to turn on tcp
david.meleedy> version 3 for our WAN mounts because udp mounts would hang
david.meleedy> once you tried to access the filesystem at all with "ls" or
david.meleedy> whatever.

david.meleedy> So for example, here is what we are doing for LAN vs. WAN:

david.meleedy> (here you can see "jetcar" a LAN mount vs. "siren" a WAN mount)

david.meleedy> codered-302: cd /etc
david.meleedy> codered-303: auto.net jetcar
david.meleedy> -fstype=nfs,hard,intr,nodev,nosuid \
david.meleedy>         /export/jetcar1 jetcar:/export/jetcar1 \
david.meleedy>         /export/jetcar2 jetcar:/export/jetcar2
david.meleedy> codered-304: auto.net siren
david.meleedy> -fstype=nfs,hard,intr,nodev,nosuid,bg,tcp,vers=3 \
david.meleedy>         /vol/vol0 siren:/vol/vol0 \
david.meleedy>         /vol/vol0/backups siren:/vol/vol0/backups \
david.meleedy>         /vol/vol0/proj siren:/vol/vol0/proj \
david.meleedy>         /vol/vol1 siren:/vol/vol1 \
david.meleedy>         /vol/vol1/proj siren:/vol/vol1/proj


david.meleedy> I am wondering if we switch to using "-hosts" which I would
david.meleedy> really prefer to do given that I wouldn't want a client to
david.meleedy> mount everything provided by a server.  Is there a way to
david.meleedy> have different fstype options happen on a per machine basis? 
david.meleedy> (I am assuming you don't do that right now, but I thought I
david.meleedy> would submit this concept to see if you have any ideas on
david.meleedy> how to do this).

My system defaults to tcp nfs v3 if no options are specified.  Given that
autofs now supports lazy mounts and unmounts, Is there a compelling reason
not to use TCP and/or version 3 mounts for the LAN?

To answer your question directly, no, there isn't a way to specify mount
options per server.

-Jeff

Re: /net support

[David Meleedy]

> My system defaults to tcp nfs v3 if no options are specified.  Given that
> autofs now supports lazy mounts and unmounts, Is there a compelling reason
> not to use TCP and/or version 3 mounts for the LAN?


Well, my understanding of TCP is that it uses a sliding window/packet
acknowledgment system to transfer data.  I would imagine that this
would incur a bandwidth overhead vs. UDP.  So, given that it's more
efficient to use UDP on the LAN, that is the behavior I had wanted to
set up.

> To answer your question directly, no, there isn't a way to specify mount
> options per server.

I didn't think there would be at the moment.  Perhaps there would
be a way to set this up with automounter variables, or some other
mechanism.  I guess what I had been hoping for is that automounter
could somehow detect how long it takes to contact a given server,
and then depending on the lag, it would set the mount to be UDP
for a short lag, or TCP version 3 for a long one.

-Dave

________________________________________________________________________
David Meleedy				Analog Devices, Inc.
David.Meleedy@analog.com		Three Technology Way
Phone: 781 461 3494			Norwood, MA  02062-9106  USA

Re: /net support

[Ian Kent]

On Mon, 2006-10-30 at 19:14 -0500, David Meleedy wrote:
> 
> > My system defaults to tcp nfs v3 if no options are specified.  Given that
> > autofs now supports lazy mounts and unmounts, Is there a compelling reason
> > not to use TCP and/or version 3 mounts for the LAN?
> 
> 
> Well, my understanding of TCP is that it uses a sliding window/packet
> acknowledgment system to transfer data.  I would imagine that this
> would incur a bandwidth overhead vs. UDP.  So, given that it's more
> efficient to use UDP on the LAN, that is the behavior I had wanted to
> set up.

That very much depends on usage.

If you have a bunch of clients that typically open and load files of
potentially several hundred megabytes then UDP retransmits can become a
problem.

But then if traffic is light there's not much to be gained and if there
are traffic spikes possibly something to be lost.

> 
> > To answer your question directly, no, there isn't a way to specify mount
> > options per server.
> 
> I didn't think there would be at the moment.  Perhaps there would
> be a way to set this up with automounter variables, or some other
> mechanism.  I guess what I had been hoping for is that automounter
> could somehow detect how long it takes to contact a given server,
> and then depending on the lag, it would set the mount to be UDP
> for a short lag, or TCP version 3 for a long one.

This is actually fairly hard to do as ping responses can be so variable
for all sorts reasons. Not sure how to go about this one.

Ian

Re: /net support

[Jeff Moyer]

==> Regarding Re: [autofs] /net support; Ian Kent <raven@themaw.net> adds:

raven> On Mon, 2006-10-30 at 19:14 -0500, David Meleedy wrote:
>> 
>> > My system defaults to tcp nfs v3 if no options are specified.  Given that
>> > autofs now supports lazy mounts and unmounts, Is there a compelling reason
>> > not to use TCP and/or version 3 mounts for the LAN?
>> 
>> 
>> Well, my understanding of TCP is that it uses a sliding window/packet
>> acknowledgment system to transfer data.  I would imagine that this
>> would incur a bandwidth overhead vs. UDP.  So, given that it's more
>> efficient to use UDP on the LAN, that is the behavior I had wanted to
>> set up.

raven> That very much depends on usage.

raven> If you have a bunch of clients that typically open and load files of
raven> potentially several hundred megabytes then UDP retransmits can become a
raven> problem.

raven> But then if traffic is light there's not much to be gained and if there
raven> are traffic spikes possibly something to be lost.

>> 
>> > To answer your question directly, no, there isn't a way to specify mount
>> > options per server.
>> 
>> I didn't think there would be at the moment.  Perhaps there would
>> be a way to set this up with automounter variables, or some other
>> mechanism.  I guess what I had been hoping for is that automounter
>> could somehow detect how long it takes to contact a given server,
>> and then depending on the lag, it would set the mount to be UDP
>> for a short lag, or TCP version 3 for a long one.

raven> This is actually fairly hard to do as ping responses can be so variable
raven> for all sorts reasons. Not sure how to go about this one.

Well, perhaps if the WAN is a different subnet we could reuse some of the
code from the replicated server support.  But you are right, ping times
are highly unreliable for making such decisions.

-Jeff

Re: /net support

[David Meleedy]

> That very much depends on usage.
> 
> If you have a bunch of clients that typically open and load files of
> potentially several hundred megabytes then UDP retransmits can become a
> problem.
> 
> But then if traffic is light there's not much to be gained and if there
> are traffic spikes possibly something to be lost.

Well, our CAD software can generate files varying from several hundred
megabytes up to 1-3 gigabytes.  So yes, we actually do have
large files being transmitted, which is why I had been looking at not
using tcp on the LAN.  But tcp is the only reliable WAN method I've
found.  I think what I'm going to have to do is generate local NIS
maps for every client and use a "program" script to read them.  That
way I can insert the appropriate flags in there, depending on whether
or not a machine is on the LAN vs. WAN.  I had just noticed that on
Solaris, the behavior seems to work much better than on linux, so I was
kind of wondering how they had solved it.

Anyway, I appreciate your consideration on this matter.

Thanks,

-Dave


________________________________________________________________________
David Meleedy				Analog Devices, Inc.
David.Meleedy@analog.com		Three Technology Way
Phone: 781 461 3494			Norwood, MA  02062-9106  USA

Re: /net support

[Joseph V Moss]

> 
> > That very much depends on usage.
> > 
> > If you have a bunch of clients that typically open and load files of
> > potentially several hundred megabytes then UDP retransmits can become a
> > problem.
> > 
> > But then if traffic is light there's not much to be gained and if there
> > are traffic spikes possibly something to be lost.
> 
> Well, our CAD software can generate files varying from several hundred
> megabytes up to 1-3 gigabytes.  So yes, we actually do have
> large files being transmitted, which is why I had been looking at not
> using tcp on the LAN.  But tcp is the only reliable WAN method I've
> found.  I think what I'm going to have to do is generate local NIS
> maps for every client and use a "program" script to read them.  That
> way I can insert the appropriate flags in there, depending on whether
> or not a machine is on the LAN vs. WAN.  I had just noticed that on
> Solaris, the behavior seems to work much better than on linux, so I was
> kind of wondering how they had solved it.

If you're going to be dealing with files that large, then you're probably
better off switching to all TCP, since you can also switch to larger
block sizes.  Try comparing the performance of copying files with
'tcp,rsize=32768,wsize=32768' to your current settings.

Re: /net support

[David Meleedy]

> From jmoss@ichips.intel.com  Tue Oct 31 16:01:38 2006
> If you're going to be dealing with files that large, then you're probably
> better off switching to all TCP, since you can also switch to larger
> block sizes.  Try comparing the performance of copying files with
> 'tcp,rsize=32768,wsize=32768' to your current settings.

Although, this sounds like a good idea, in addition to having some
files that are huge, we have thousands of small 1k->4k files that
are accessed as well.  It's just a huge mix.  I'm not sure that
increasing tcp packet sizes would be a good thing given the huge
quantity of small files.  But maybe... 

Thanks,

-Dave

________________________________________________________________________
David Meleedy				Analog Devices, Inc.
David.Meleedy@analog.com		Three Technology Way
Phone: 781 461 3494			Norwood, MA  02062-9106  USA

Re: /net support

[Ian Kent]

On Tue, 2006-10-31 at 15:42 -0500, David Meleedy wrote:
> > That very much depends on usage.
> > 
> > If you have a bunch of clients that typically open and load files of
> > potentially several hundred megabytes then UDP retransmits can become a
> > problem.
> > 
> > But then if traffic is light there's not much to be gained and if there
> > are traffic spikes possibly something to be lost.
> 
> Well, our CAD software can generate files varying from several hundred
> megabytes up to 1-3 gigabytes.  So yes, we actually do have
> large files being transmitted, which is why I had been looking at not
> using tcp on the LAN.  But tcp is the only reliable WAN method I've
> found.  I think what I'm going to have to do is generate local NIS
> maps for every client and use a "program" script to read them.  That
> way I can insert the appropriate flags in there, depending on whether
> or not a machine is on the LAN vs. WAN.  I had just noticed that on
> Solaris, the behavior seems to work much better than on linux, so I was
> kind of wondering how they had solved it.

That's a good point actually.

Solaris uses a proximity metric which I've attempted to put into v5.

In particular it discriminates between local network, local subnet and
other network. This happens before ping tests are done. So we do know if
we are requesting a mount on a network not directly accessible though a
local interface. Of course that network may not actually be over a WAN
such as for sites with many local subnets.

I'm not sure yet about the implications or how much effort it would be
needed to insist that the TCP protocol always and only be used for mount
requests whose proximity is other network. The proximity check is
granular in that it is written to be passed the protocols to be checked.
At the moment it always checks both. I expect I would need to also grab
the routing information and examine the hop count for this to work in a
reasonable way.

I'll have a poke around and see what's involved.

Ian

Re: /net support

[David Meleedy]

> That's a good point actually.
> 
> Solaris uses a proximity metric which I've attempted to put into v5.
> 
> In particular it discriminates between local network, local subnet and
> other network. This happens before ping tests are done. So we do know if
> we are requesting a mount on a network not directly accessible though a
> local interface. Of course that network may not actually be over a WAN
> such as for sites with many local subnets.

Yeah, just FYI at our large site, we have about 7 different subnets
that are all on our LAN.  In order to get my scripts to figure out
which subnets are related I had to create netgroups that the scripts
could use to determine the relationships of the subnets to each other.
(At one point we were converting 137.71.x.x to 10.64.x.x so we had
vastly different network numbers that were still on the same LAN).

At our smaller sites, they usually have 2 subnets on the 10. net.

> I'm not sure yet about the implications or how much effort it would be
> needed to insist that the TCP protocol always and only be used for mount
> requests whose proximity is other network. The proximity check is
> granular in that it is written to be passed the protocols to be checked.
> At the moment it always checks both. I expect I would need to also grab
> the routing information and examine the hop count for this to work in a
> reasonable way.

Well, I think that you'd want some configuration options for the automounter
daemon regarding how to treat proximities (stuff you could put into the
/etc/sysconfig/autofs - on RHE).   You could provide some defaults that
make sense, but it would then allow people to fine tune the settings.  You
could have two proximity settings, one set for "LAN or local" another set
for "WAN or remote".  That way any decisions you make could be modified.


> I'll have a poke around and see what's involved.
> 
> Ian
> 


________________________________________________________________________
David Meleedy				Analog Devices, Inc.
David.Meleedy@analog.com		Three Technology Way
Phone: 781 461 3494			Norwood, MA  02062-9106  USA