From: Ian Kent <raven@themaw.net>
To: Deke Clinger <dclinger@qualcomm.com>
Cc: autofs@linux.kernel.org
Subject: Re: 5.0.5 non-expiring mounts
Date: Thu, 17 Feb 2011 15:57:13 +0800 [thread overview]
Message-ID: <1297929433.15852.6.camel@perseus> (raw)
In-Reply-To: <alpine.LSU.2.00.1102161700370.29435@tux.qualcomm.com>
On Wed, 2011-02-16 at 17:08 -0800, Deke Clinger wrote:
> On Wed Feb 16 12:18:15 UTC 2011 Ian Kent wrote:
>
> > A backtrace generally doesn't do us any good when were trying to find an
> > expire problem, the debug log is where we have to start on these.
>
> I've got a debug log from a sled10sp3 machine running the Novell autofs
> 5.0.5 update. Ian - could I mail you this personally? I'd rather not have
> this log with usernames, paths, hostnames, etc. on a public archive.
Yes please.
>
> FWIW, I did do a test with autofs5.0.5 built from source with all the
> patches in the patch order list from kernel.org and it demonstrated the
> same behavior: a USR1 signal unmounted the direct map entries but not the
> indirect. I changed the maps to files, pruned them to a few hundred entries
> and converted the indirect entries to direct and re-ran the
> test. Configured like this all entries unmounted upon a USR1 signal so I do
> believe this has something to do with direct vs indirect mounts.
There are a couple of possibilities. I'm always working with the current
source and basic testing includes expiring both direct and indirect
mounts as a matter of course and I'm not seeing this. So there has to be
more to it or I have one or other patches already in the queue that
resolve the problem.
Does this happen straight away or start after some time of running?
Do all indirect mounts stop expiring or only some?
What is the for of the indirect map entries, are they multi-mount
entries?
Obviously the debug log will probably answer most of these questions.
Ian
next prev parent reply other threads:[~2011-02-17 7:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-17 1:08 5.0.5 non-expiring mounts Deke Clinger
2011-02-17 7:57 ` Ian Kent [this message]
-- strict thread matches above, loose matches on Subject: below --
2011-02-17 19:21 Deke Clinger
2011-02-08 9:30 Philip Ong Jr.
2011-02-11 3:10 ` Ian Kent
2011-02-15 1:10 ` Mike Marion
2011-02-15 3:11 ` Ian Kent
2011-02-15 3:37 ` Ian Kent
2011-02-15 5:28 ` Mike Marion
2011-02-15 12:28 ` Ian Kent
2011-02-15 18:11 ` Leonardo Chiquitto
2011-02-16 7:08 ` Ian Kent
2011-02-16 12:18 ` Ian Kent
2011-02-23 20:22 ` Leonardo Chiquitto
2011-02-16 12:58 ` Leonardo Chiquitto
2011-03-04 20:10 ` Leonardo Chiquitto
2011-03-05 5:18 ` Ian Kent
2011-03-24 22:03 ` Leonardo Chiquitto
2011-03-28 3:17 ` Ian Kent
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=1297929433.15852.6.camel@perseus \
--to=raven@themaw.net \
--cc=autofs@linux.kernel.org \
--cc=dclinger@qualcomm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).