Hi,
I've been working on a fairly major overhaul of the autofs mount_nfs
code. One of the things I've recently added is making it prefer to mount
from server addresses that are on the same subnet as the client.
Unfortunately, I've found that when the mount program does a
gethostbyname() call to get the address of the host, it simply picks the
first address in the list, without regard for how "close" it is to the
client.
The upshot of this is that if even autofs picks a replicated mount entry
that is on the same subnet as the client, we may end up mounting across
a router anyway.
A simple way to correct this would be to make autofs pass the address
instead of the hostname when calling "mount". However, that will make
for an ugly /proc/mounts, especially if we have a lot of automounted NFS
mounts (it's more human-friendly to keep the hostname info when looking
at the list of mounts).
So, what I'd like to do is roll a patch for mount to change the behavior
of the 'addr=' option. Instead of ignoring it, we'd treat it as an
address hint. If one of the addresses returned by gethostbyname()
matches this address, then we'd mount using that address. Otherwise, the
existing behavior would prevail (use the first address in the list).
I'm writing this to solicit some feedback before I dive in and start
working on it. Does this sound like a reasonable idea? Is there
something I'm not considering that would prevent this from working?
Thanks,
Jeff
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
m=C3=A5 den 18.07.2005 Klokka 11:09 (-0700) skreiv Dan Stromberg:
> Another option would be to make programs that inspect the mount list
> (like the mount command :) optionally do a reverse lookup on IP
> addresses when listing mounts, or even have them do it by defauylt.
I fully agree, except on the last point: I'm not sure you want reverse
lookup to be the default behaviour. Consider, for instance, the case
where you have a multihomed server that runs different servers on
different IP addresses.
Cheers,
Trond
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Jul 18, 2005 at 02:37:50PM -0400, Trond Myklebust wrote:
> I would not at all support doing this sort of thing in autofs. If it is
> to be done, it should be done by the mount program.
That would make mount awfully slow, and we're suffering from excessive
boot times already. Besides, mount can see just the current state,
a daemon would be able to collect statistics over a period of time and
average it.
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2005-07-18 at 11:09 -0700, Dan Stromberg wrote:
> Another option would be to make programs that inspect the mount list
> (like the mount command :) optionally do a reverse lookup on IP
> addresses when listing mounts, or even have them do it by defauylt.
The issue here is that a lot of people have b0rken DNS records, where
they have a forward record, but no reverse record (or one that is
wrong).
When mounting via hostname, you won't notice this, but when you go to
look at the reverse lookup'ed version it wouldn't look right.
I think the existing behavior, while not perfect, at least gives you
some idea of what the mount command looked like, and you can still get
the actual address of the mount from the addr= option in the mount
string.
--
Jeff Layton <[email protected]>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
m=C3=A5 den 18.07.2005 Klokka 21:54 (+0200) skreiv Olaf Kirch:
> On Mon, Jul 18, 2005 at 02:37:50PM -0400, Trond Myklebust wrote:
> > I would not at all support doing this sort of thing in autofs. If it is
> > to be done, it should be done by the mount program.
>=20
> That would make mount awfully slow, and we're suffering from excessive
> boot times already. Besides, mount can see just the current state,
> a daemon would be able to collect statistics over a period of time and
> average it.
It would be slow only in the case where you have multiple ip addresses
on the server as you would probe them all instead of just probing one as
we do now.
If you really do want to collect long term statistics (and I'm not sure
I see the value of that), you can have mount save the information in a
file.
Cheers,
Trond
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 18 Jul 2005, Trond Myklebust wrote:
> su den 17.07.2005 Klokka 11:38 (-0400) skreiv Jeff Layton:
> > So, what I'd like to do is roll a patch for mount to change the behavior
> > of the 'addr=' option. Instead of ignoring it, we'd treat it as an
> > address hint. If one of the addresses returned by gethostbyname()
> > matches this address, then we'd mount using that address. Otherwise, the
> > existing behavior would prevail (use the first address in the list).
> >
> > I'm writing this to solicit some feedback before I dive in and start
> > working on it. Does this sound like a reasonable idea? Is there
> > something I'm not considering that would prevent this from working?
>
> There's nothing preventing it from working, but what is stopping you
> from developing a fully automatic version?
>
> If you see that the server has multiple addresses, you can, for
> instance, try timing an RPC ping (null rpc call) to the NFS server. In
> the version of "mount" that RedHat is using (which I still haven't
> pushed to the utils-linux maintainer) we're already doing a ping in
> order to test for service availability. It would be trivial to time
> those pings.
That patch is present on Aurora (FC2 base , where I've been testing autofs
development. It effectively prevents mounting of any more than about 80
mounts before you have to wait for the sockets to close.
Don't get me wrong I'm also guilty of probing in autofs.
Unfortunately, it really interferes with the ability to mount a healthy
number of filesystems quickly.
Perhaps we should consider you old patch to multiplex RPC TCP connections
before pushing ahead with more probing in the utilities. I also plead
guilty to not any work on this. I wish I had more time.
Ian
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 18 Jul 2005, Jeff Layton wrote:
> On Mon, 2005-07-18 at 11:36 -0400, Trond Myklebust wrote:
> > There's nothing preventing it from working, but what is stopping you
> > from developing a fully automatic version?
>
> Nothing is stopping that, but if we're going to do so much in the mount
> program, there's probably no point in doing all of this in autofs. Why
> do RPC pings at all in autofs if we're going to turn right around and do
> them again in the mount program? For mounting over a WAN (for instance)
> the ping checks could really add up to a substantial delay in mounting.
If I remember correctly, there were two reasons that this was done in
autofs, one was that mount used to hang when machines couldn't be
reached. The second was to support replicated server mount syntax. Mount
may not hang anymore with introduction of probing but it doesn't support
the replicated server syntax. The other problem with mounts' probing is
that it's quite aggressive, opening, it appears, more sockets than it
really needs to.
>
> For now, I'd like to keep my initial patch somewhat small and simple and
> simply make the addr= option be respected, but I'd certainly consider
> redoing it to add the stuff you mention above at a later time.
>
> My suggestion would be to consider this in conjunction with autofs v5
> (or a later v4 version) so we don't end up duplicating so much
> functionality.
You'll need to get in quick ito those sort of changes in v5.
As I said, to persue the probing logic we really need to add some simple,
single socket per server multiplexing at least, to thr RPC layer.
Ian
On Mon, 18 Jul 2005, Olaf Kirch wrote:
> On Mon, Jul 18, 2005 at 02:37:50PM -0400, Trond Myklebust wrote:
> > I would not at all support doing this sort of thing in autofs. If it is
> > to be done, it should be done by the mount program.
>
> That would make mount awfully slow, and we're suffering from excessive
> boot times already. Besides, mount can see just the current state,
> a daemon would be able to collect statistics over a period of time and
> average it.
That's an interesting thought.
I've already given some thought to maintaining persistent connections to
servers to help with this in autofs. Once again I haven't been able to do
anything about it yet.
Ian
On Mon, 18 Jul 2005, Trond Myklebust wrote:
> må den 18.07.2005 Klokka 21:54 (+0200) skreiv Olaf Kirch:
> > On Mon, Jul 18, 2005 at 02:37:50PM -0400, Trond Myklebust wrote:
> > > I would not at all support doing this sort of thing in autofs. If it is
> > > to be done, it should be done by the mount program.
> >
> > That would make mount awfully slow, and we're suffering from excessive
> > boot times already. Besides, mount can see just the current state,
> > a daemon would be able to collect statistics over a period of time and
> > average it.
>
> It would be slow only in the case where you have multiple ip addresses
> on the server as you would probe them all instead of just probing one as
> we do now.
Supporting replicated server mounts can certainly be slow. The problem in
deciding what timeout to use. A short timeout can yield false negatives
and a longer timeout slows the whole process heaps.
Ian
On Sun, Jul 17, 2005 at 11:38:28AM -0400, Jeff Layton wrote:
> Unfortunately, I've found that when the mount program does a
> gethostbyname() call to get the address of the host, it simply picks the
> first address in the list, without regard for how "close" it is to the
> client.
>
> The upshot of this is that if even autofs picks a replicated mount entry
> that is on the same subnet as the client, we may end up mounting across
> a router anyway.
Yes, I think this is why the am-utils automounter of old had all these
weird syntax additions to give you control over which server a client
ends up selecting.
> So, what I'd like to do is roll a patch for mount to change the behavior
> of the 'addr=' option. Instead of ignoring it, we'd treat it as an
> address hint. If one of the addresses returned by gethostbyname()
> matches this address, then we'd mount using that address. Otherwise, the
> existing behavior would prevail (use the first address in the list).
Why just use it as a hint? Why not override address resolution completely
when addr= is given?
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sun, 2005-07-17 at 18:51 +0200, Olaf Kirch wrote:
> Why just use it as a hint? Why not override address resolution completely
> when addr= is given?
I suppose that's a possibility, but it might have security implications.
My concern there would be that someone could then essentially pass an
addr= option to a mount that actually doesn't match the hostname. Then
you have a mount that appears at first glance to be from a hostname that
you believe to be valid, but is actually a different host entirely.
Then again, I suppose you can get the same effect by temporarily
spoofing hosts resolution, so perhaps just allowing addr= to override it
is the best bet.
-- Jeff
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
su den 17.07.2005 Klokka 18:51 (+0200) skreiv Olaf Kirch:
> > So, what I'd like to do is roll a patch for mount to change the behavior
> > of the 'addr=' option. Instead of ignoring it, we'd treat it as an
> > address hint. If one of the addresses returned by gethostbyname()
> > matches this address, then we'd mount using that address. Otherwise, the
> > existing behavior would prevail (use the first address in the list).
>
> Why just use it as a hint? Why not override address resolution completely
> when addr= is given?
How would this differ from just using the ip address instead of hostname
syntax?
Cheers,
Trond
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
su den 17.07.2005 Klokka 11:38 (-0400) skreiv Jeff Layton:
> So, what I'd like to do is roll a patch for mount to change the behavior
> of the 'addr=' option. Instead of ignoring it, we'd treat it as an
> address hint. If one of the addresses returned by gethostbyname()
> matches this address, then we'd mount using that address. Otherwise, the
> existing behavior would prevail (use the first address in the list).
>
> I'm writing this to solicit some feedback before I dive in and start
> working on it. Does this sound like a reasonable idea? Is there
> something I'm not considering that would prevent this from working?
There's nothing preventing it from working, but what is stopping you
from developing a fully automatic version?
If you see that the server has multiple addresses, you can, for
instance, try timing an RPC ping (null rpc call) to the NFS server. In
the version of "mount" that RedHat is using (which I still haven't
pushed to the utils-linux maintainer) we're already doing a ping in
order to test for service availability. It would be trivial to time
those pings.
Note that there are various problems that you need to consider.
There is the trivial fact that our NFS client doesn't yet work over any
other network than IPv4.
Less obvious, is the fact that the NFS server may not be willing to
grant you access on certain networks (if it is only exporting the disk
to an internal LAN for instance).
Cheers,
Trond
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2005-07-18 at 11:22 -0400, Trond Myklebust wrote:
> How would this differ from just using the ip address instead of hostname
> syntax?
It would allow you to keep a hostname in the host section of the mount
string. When looking at a large list of NFS mounts, that is much easier
to read than looking at IP addresses.
--
Jeff Layton <[email protected]>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2005-07-18 at 13:55 -0400, Jeff Layton wrote:
> On Mon, 2005-07-18 at 11:22 -0400, Trond Myklebust wrote:
> > How would this differ from just using the ip address instead of hostname
> > syntax?
>
> It would allow you to keep a hostname in the host section of the mount
> string. When looking at a large list of NFS mounts, that is much easier
> to read than looking at IP addresses.
Another option would be to make programs that inspect the mount list
(like the mount command :) optionally do a reverse lookup on IP
addresses when listing mounts, or even have them do it by defauylt.
Arguably, it'd be better to have IP addresses in the source list, to
reduce ambiguity anyway.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2005-07-18 at 11:36 -0400, Trond Myklebust wrote:
> There's nothing preventing it from working, but what is stopping you
> from developing a fully automatic version?
Nothing is stopping that, but if we're going to do so much in the mount
program, there's probably no point in doing all of this in autofs. Why
do RPC pings at all in autofs if we're going to turn right around and do
them again in the mount program? For mounting over a WAN (for instance)
the ping checks could really add up to a substantial delay in mounting.
For now, I'd like to keep my initial patch somewhat small and simple and
simply make the addr= option be respected, but I'd certainly consider
redoing it to add the stuff you mention above at a later time.
My suggestion would be to consider this in conjunction with autofs v5
(or a later v4 version) so we don't end up duplicating so much
functionality.
--
Jeff Layton <[email protected]>
m=C3=A5 den 18.07.2005 Klokka 14:24 (-0400) skreiv Jeff Layton:
> On Mon, 2005-07-18 at 11:36 -0400, Trond Myklebust wrote:
> > There's nothing preventing it from working, but what is stopping you
> > from developing a fully automatic version?
>=20
> Nothing is stopping that, but if we're going to do so much in the mount
> program, there's probably no point in doing all of this in autofs. Why
> do RPC pings at all in autofs if we're going to turn right around and do
> them again in the mount program? For mounting over a WAN (for instance)
> the ping checks could really add up to a substantial delay in mounting.
I would not at all support doing this sort of thing in autofs. If it is
to be done, it should be done by the mount program.
Cheers,
Trond
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs