From: Matthew Mitchell <matthew@geodev.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: autofs@linux.kernel.org
Subject: Re: "simultaneous" mounts causing weird behavior
Date: Tue, 04 Nov 2003 14:56:10 -0600 [thread overview]
Message-ID: <1067979370.2630.110.camel@aluminum> (raw)
In-Reply-To: <3FA7DBB3.1020904@zytor.com>
On Tue, 2003-11-04 at 11:02, H. Peter Anvin wrote:
> Matthew Mitchell wrote:
> > Hello,
> >
> > On some SMP processing nodes we have in our cluster we are noticing the
> > following odd behavior. It seems like there might be a race condition
> > somewhere in automount that results in the same (in this case NFS)
> > device mounted twice on the same mountpoint.
> >
> > In our case we have a (closed-source, vendor provided) data processing
> > app that runs 2-4 processes at a time on each of these nodes. The
> > processes communicate via MPI. What ends up happening is that each of
> > them tries to read data from these NFS-mounted volumes at exactly the
> > same time, and sometimes (about one node out of every 10) we get unlucky
> > and the disk gets double-mounted.
> >
> > Here is the entry from the messages file where the disks are getting
> > mounted:
> > Nov 2 16:52:53 fir32 automount[674]: attempting to mount entry
> > /etvf/data0
> > Nov 2 16:52:53 fir32 automount[674]: attempting to mount entry
> > /etvf/data0
> >
> > (Yes, there are two of them.)
> >
>
> This happens because mount silently changed behaviour -- autofs relies
> on mount only allowing one thing to be mounted on each mount point, but
> that was suddenly changed without warning.
Yes, I know that mount can do that now. But automount is spawning the
second mount before the first one completes, no? Still seems like there
should be some sort of mutual exclusion around the lookup_mount call. I
realize our workload is kind of funny in that the processes effectively
_try_ to synchronize their automount request.
Has any of this changed in the 4.0-pre autofs? I haven't read through
its source yet.
-m
next prev parent reply other threads:[~2003-11-04 20:56 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-04 14:42 "simultaneous" mounts causing weird behavior Matthew Mitchell
2003-11-04 17:02 ` H. Peter Anvin
2003-11-04 20:56 ` Matthew Mitchell [this message]
2003-11-04 21:03 ` H. Peter Anvin
2003-11-05 0:51 ` Ian Kent
2003-11-05 0:49 ` Ian Kent
2003-11-05 0:46 ` Ian Kent
2003-11-05 16:57 ` Matthew Mitchell
2003-11-06 3:53 ` Ian Kent
2003-11-10 16:57 ` Matthew Mitchell
2003-11-11 13:33 ` [autofs] " Ian Kent
-- strict thread matches above, loose matches on Subject: below --
2003-11-05 18:45 Ogden, Aaron A.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1067979370.2630.110.camel@aluminum \
--to=matthew@geodev.com \
--cc=autofs@linux.kernel.org \
--cc=hpa@zytor.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.