All of lore.kernel.org
 help / color / mirror / Atom feed
* Issues with failed bind mounts in autofs 5.0.5
@ 2010-01-22 20:02 Paul Smith
  2010-01-23  0:27 ` Marc Weber
  0 siblings, 1 reply; 3+ messages in thread
From: Paul Smith @ 2010-01-22 20:02 UTC (permalink / raw)
  To: autofs

I couldn't find any reference to how to access autofs latest source (is
it available in git or CVS or somewhere?  It would be nice if there were
some webpage, even minimal, dedicated to autofs development that was
findable, either via Google or in the README files in the source or
whatever) so I'm not sure this hasn't been fixed.


There are a number of issues I see when I try to use autofs inside an
initrd, where the mount point is on the ramdisk.  The rootfs partition
type does not support bind mounts, so automount's attempt to use them
fails.  This prints scary messages to the syslog, which is unfortunate,
but things eventually do work.  The comments below are based on an hour
or so of investigation so if I'm wrong, mea culpa!!

The way this works is that mount_bind.c:mount_init() creates temporary
directories then invokes spawn.c:spawn_mount() with --bind option.  

The first problem is we're testing bind mounts in /tmp, which I think is
not right, because whether bind mounts are supported depends on the
filesystem where the mount will happen.  Just because mount --bind works
in /tmp does not mean it will work for the actual mount point in
question.  Conversely, if bind mounts don't work in /tmp that doesn't
mean they wouldn't work in the real filesystem.

The second annoyance is that we're testing bind mounts twice: I have one
file entry in auto.master, and that file has one entry in it, but
mount_bind.c:mount_init() is called twice.  Either the previous point
should be addressed and we invoke it once for each mount point, or it
should be invoked only one time, I'd imagine.

The next problem is in spawn.c:spawn_mount() itself.  This function
invokes do_spawn() and gets a return value.  It then checks the return
value with & MTAB_NOTUPDATED (0x1000) to see if the mtab was updated.
This is tied very tightly to the Linux standard mount(8) which defines
the exit code 16 (0x10) to be "problems locking or writing the mtab
file".  But other implementations of mount may not use these exit codes:
busybox mount, for example, exits with -1 (255) if you run mount --bind
on a filesystem where it isn't supported.

Even in do_spawn() it returns -1 for various errors such as fork() or
waitpid() failing.  I think the tests in spawn.c like:

	if (ret & MTAB_NOTUPDATED) {

should at least be modified to:

	if (ret & 0xff00 != 0xff00 && ret & MTAB_NOTUPDATED) {

or possibly:

	if (ret & 0xff00 < 0x8000 && ret & MTAB_NOTUPDATED) {

Otherwise, it actually retries the bind mount 3 times (for each
invocation, or 6 times total) waiting 3s between each one if do_spawn()
is returning -1 (or mount is exiting with 255).

One last minor thing: the return code from spawn_mount() doesn't tell us
whether the mount happened or not.  If it did, we could avoid trying the
umount if the mount didn't work.  But that's a minor point (except that
this also has the same retry/timeout issues as above).


Ultimately what I'd really like is some command line or configuration
option that suppressed the bind mount check in the first place, since I
already know it won't work.


Thanks for listening!

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Issues with failed bind mounts in autofs 5.0.5
  2010-01-22 20:02 Issues with failed bind mounts in autofs 5.0.5 Paul Smith
@ 2010-01-23  0:27 ` Marc Weber
  2010-01-25  3:55   ` Ian Kent
  0 siblings, 1 reply; 3+ messages in thread
From: Marc Weber @ 2010-01-23  0:27 UTC (permalink / raw)
  To: autofs

Excerpts from Paul Smith's message of Fri Jan 22 21:02:33 +0100 2010:
> I couldn't find any reference to how to access autofs latest source (is
> it available in git or CVS or somewhere? 
http://ftp.riken.go.jp/Linux/kernel.org/scm/linux/storage/autofs/autofs.git

I don't remember how I found it. Last change is
Date:   Tue Mar 17 11:43:40 2009 +0900

So I'm not totally sure wether this is still the correct location. But I
think not much has changed.

So yes: there should be a wiki!

I'm still willing to spend some minimal time on putting useful online..

HTH
Marc Weber

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Issues with failed bind mounts in autofs 5.0.5
  2010-01-23  0:27 ` Marc Weber
@ 2010-01-25  3:55   ` Ian Kent
  0 siblings, 0 replies; 3+ messages in thread
From: Ian Kent @ 2010-01-25  3:55 UTC (permalink / raw)
  To: autofs

On 01/23/2010 08:27 AM, Marc Weber wrote:
> Excerpts from Paul Smith's message of Fri Jan 22 21:02:33 +0100 2010:
>> I couldn't find any reference to how to access autofs latest source (is
>> it available in git or CVS or somewhere? 
> http://ftp.riken.go.jp/Linux/kernel.org/scm/linux/storage/autofs/autofs.git
> 
> I don't remember how I found it. Last change is
> Date:   Tue Mar 17 11:43:40 2009 +0900

That's got to be out of date.

The official location is on kernel.org at:

git.kernel.org/pub/scm/linux/storage/autofs/autofs.git

I believe that http should work OK as well as the usual git access
method. So

git clone git://git.kernel.org/pub/scm/linux/storage/autofs/autofs.git

should get you want you need.

And of course you can inspect the repo using the git web interface on
kernel.org at:

http://git.kernel.org/?p=linux/storage/autofs/autofs.git;a=summary

> 
> So I'm not totally sure wether this is still the correct location. But I
> think not much has changed.

No, that must be an out of date mirror of kernel.org.

> 
> So yes: there should be a wiki!
> 
> I'm still willing to spend some minimal time on putting useful online..

Yes, a wiki would be good.

The truth is that I'm well and truly over creating and administering web
sites so, even if we did have a place to host it, anything we do will
need to be a group effort. Clearly, I would be happy to review,
contribute and share (to a reasonable extent) administration.

I'm fairly confident that if we requested a wiki for autofs on
kernel.org that would be approved. I haven't looked into what that would
mean wrt. to administration and also if it is possible for people
without kernel.org accounts to carry out the administration and editing.
Mainly because I didn't think we had a sufficient number of people
interested in contributing time and effort.

Ian

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2010-01-25  3:55 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-01-22 20:02 Issues with failed bind mounts in autofs 5.0.5 Paul Smith
2010-01-23  0:27 ` Marc Weber
2010-01-25  3:55   ` Ian Kent

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.