Another (stupid) question: autofs vs nfs for automounting purposes

Another (stupid) question: autofs vs nfs for automounting purposes

[Dimitry V. Ketov]

- Which reasons (besides simplicity) led developers to the autofs
solution?
- What's wrong with nfs for the same things?

Thanks in advance,
Dimitry.

Re: Another (stupid) question: autofs vs nfs for automounting purposes

[Ryan Go]

I think something is missing ...

NFS doesn't do automounting. Autofs does automounting. It's an apple and
orange comparison.

	<< ryan

On Fri, 11 Jun 2004, Dimitry V. Ketov wrote:

> - Which reasons (besides simplicity) led developers to the autofs
> solution?
> - What's wrong with nfs for the same things?
>
> Thanks in advance,
> Dimitry.
>
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs
>

Re: Another (stupid) question: autofs vs nfs for automounting purposes

[raven]

On Fri, 11 Jun 2004, Dimitry V. Ketov wrote:

> - Which reasons (besides simplicity) led developers to the autofs
> solution?
> - What's wrong with nfs for the same things?

I don't understand your question.

What has NFS to do with automounting?

Ian

Re: Another (stupid) question: autofs vs nfs for automounting purposes

[Jim Carter]

On Fri, 11 Jun 2004, Dimitry V. Ketov wrote:

> - Which reasons (besides simplicity) led developers to the autofs
> solution?
> - What's wrong with nfs for the same things?

autofs mounts any available filesystem on demand.  It is most widely used 
for NFS filesystems, but the distributed /etc/auto.misc  file shows a 
number of examples of non-NFS mounts: the version I have has examples for a 
zip drive, a CD and a floppy, as well as NFS to a foreign site.  Samba 
mounts can also be done.  (I think.)

All the quirks and foibles of NFS that you have to deal with when mounting 
manually or via fstab, equally have to be dealt with when you use autofs.  
Often it is hard to figure out whether NFS or the automounter is 
responsible for a particular unexpected behavior.  

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc@math.ucla.edu  http://www.math.ucla.edu/~jimc (q.v. for PGP key)

RE: Another (stupid) question: autofs vs nfs for automounting purposes

[Dimitry V. Ketov]

> -----Original Message-----
> From: raven@themaw.net [mailto:raven@themaw.net] 
> 
> On Fri, 11 Jun 2004, Dimitry V. Ketov wrote:
> 
> > - Which reasons (besides simplicity) led developers to the autofs 
> > solution?
> > - What's wrong with nfs for the same things?
> 
> I don't understand your question.
> 
> What has NFS to do with automounting?
Sorry, if I'm unclear.
I really meant communication protocol between kernel and the userspace
for automounting purposes.
As I know, early automounting solutions was (and current am-utils is)
based on userspace nfs server daemon that mount itself on the autmomount
points and then listen for filesystem traverses that trigger mounting.
I understand that nfs was designed for different purposes, but anyway
what reason to design new communication protocol and to complicate
kernel instead using already in-kernel nfs code?

Dimitry.

RE: Another (stupid) question: autofs vs nfs for automounting purposes

[raven]

On Mon, 14 Jun 2004, Dimitry V. Ketov wrote:

> > -----Original Message-----
> > From: raven@themaw.net [mailto:raven@themaw.net] 
> > 
> > On Fri, 11 Jun 2004, Dimitry V. Ketov wrote:
> > 
> > > - Which reasons (besides simplicity) led developers to the autofs 
> > > solution?
> > > - What's wrong with nfs for the same things?
> > 
> > I don't understand your question.
> > 
> > What has NFS to do with automounting?
> Sorry, if I'm unclear.
> I really meant communication protocol between kernel and the userspace
> for automounting purposes.
> As I know, early automounting solutions was (and current am-utils is)
> based on userspace nfs server daemon that mount itself on the autmomount
> points and then listen for filesystem traverses that trigger mounting.
> I understand that nfs was designed for different purposes, but anyway
> what reason to design new communication protocol and to complicate
> kernel instead using already in-kernel nfs code?

I'm not really familiar with amd so I can't comment on that.

Historically there are two ways to implement automount one being 
userspace, RPC based and the other being kernel based. autofs uses the 
kernel based method. It doesn't seem to me using the in kernel NFS would 
be sensible but someone would need to enlighten me on that.

In any case this implementation is a kernel based automounter. If you 
would like to use the other implementation then I believe amd is quite a 
capable product.

Ian

RE: Another (stupid) question: autofs vs nfs for automounting purposes

[Dimitry V. Ketov]

> -----Original Message-----
> From: raven@themaw.net [mailto:raven@themaw.net] 

> > communication protocol and to complicate kernel instead 
> using already 
> > in-kernel nfs code?
> 
> I'm not really familiar with amd so I can't comment on that.
> 
> Historically there are two ways to implement automount one being 
> userspace, RPC based and the other being kernel based. autofs 
> uses the 
> kernel based method. It doesn't seem to me using the in 
> kernel NFS would 
> be sensible but someone would need to enlighten me on that.
> 
> In any case this implementation is a kernel based automounter. If you 
> would like to use the other implementation then I believe amd 
> is quite a 
> capable product.
:) Nope. Just trying to figure out why two different implementations is
still exists.
Anyway thanks,


Dimitry.

Re: Another (stupid) question: autofs vs nfs for automounting purposes

[Greg Banks]

On Mon, Jun 14, 2004 at 06:10:34PM +0800, raven@themaw.net wrote:
> On Mon, 14 Jun 2004, Dimitry V. Ketov wrote:
> 
> > > What has NFS to do with automounting?
> > Sorry, if I'm unclear.
> > I really meant communication protocol between kernel and the userspace
> > for automounting purposes.
> > As I know, early automounting solutions was (and current am-utils is)
> > based on userspace nfs server daemon that mount itself on the autmomount
> > points and then listen for filesystem traverses that trigger mounting.
> > I understand that nfs was designed for different purposes, but anyway
> > what reason to design new communication protocol and to complicate
> > kernel instead using already in-kernel nfs code?
> 
> I'm not really familiar with amd so I can't comment on that.
> 
> Historically there are two ways to implement automount one being 
> userspace, RPC based and the other being kernel based. autofs uses the 
> kernel based method. It doesn't seem to me using the in kernel NFS would 
> be sensible but someone would need to enlighten me on that.

One of the problems of the userspace-nfs-daemon approach to
autofs trigger nodes is that a necessary side effect of the
design is that the NFS mount points need to be somewhere
else in the filesystem with fake symlinks to them from the
trigger nodes.  This then shows up in /bin/pwd output and
applications get mightily confused.

For example, let's say we have an autofs node /hosts/foobar.

With the userspace-nfs-daemon approach, after the first
traversal /hosts/foobar is a symlink to /.automount/foobar/root/
which is the actual NFS mountpoint.  If an application does
a getcwd() call or runs /bin/pwd, the returned path will
start at /.automount/foobar/root/.  The typical failure mode
you see with this is that an application will save pathnames
like that in some persistent state (e.g. a compiler saving
the path to the .c file in the generated binary) and then after
the mount goes idle and is unmounted the pathname cannot be
reached (e.g. you start the debugger on the binary twenty
minutes later).

Years ago, I had no end of problems using with the SunOS 4
automounter, which behaved this way.

With the kernel approach, after the first traversal /hosts/foobar
is itself the NFS mountpoint, and applications doing a getcwd()
see paths starting with /hosts/foobar, which will still work
after the mount goes idle and is unmounted.

The price you pay is that bugs are harder to find and fix.

There are other problems with using NFS to talk to autofsd.
For one thing it means that you have an NFS mount all the time,
even when you're not mounting other machines, which means you're
running lockd all the time and can't shut it down, which on an
NFS server makes it really hard to failover NFS service to
another server.

Greg.
-- 
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.