From: Ian Kent <raven@themaw.net>
To: Mike Marion <mmarion@qualcomm.com>
Cc: "autofs@linux.kernel.org" <autofs@linux.kernel.org>
Subject: Re: 5.0.5 non-expiring mounts
Date: Tue, 15 Feb 2011 11:11:04 +0800 [thread overview]
Message-ID: <1297739464.13007.8.camel@perseus> (raw)
In-Reply-To: <20110215011037.GT27735@sunapee.qualcomm.com>
On Mon, 2011-02-14 at 17:10 -0800, Mike Marion wrote:
> On Tue, Feb 08, 2011 at 01:30:59AM -0800, Philip Ong Jr. wrote:
>
> > I've set the logging level to debug and can see messages of expiring
> > mounts in /var/log/messages...but when I check /etc/mtab or /proc/mounts
> > or df, i can still see them there. Any ideas if this is a known issue or
> > if I can give more info than below?
>
> Out of curiosity... are these direct or indirect mounts? We're seeing an
> issue where our huge maps served from LDAP are seeing indirects not umounting
> while logging expires just fine, but the direct maps are working great. I
> believe a co-worker has replicated this exact same behavior with local files
> based maps too though, so pretty sure it's not really related to LDAP at all,
> but we've found using LDAP helped clear out a lot of old issues we had a few
> years ago related to the hashing bits.
>
> I've even done network sniffing while doing a kill -USR1 and the automount
> daemon opens new sockets for each indirect (our homedirs) path it wants to
> expire, but there never is any actual network traffic sent across the wire.
> Even better, the sockets stay stuck in ESTABLISHED for a long time. Some more
> USR1/expires and/or HUPs can help clear is, or I just run a script that does
> an fuser then umount on unused homedirs and that flushes the ports out. When
> the ports pile up to >300 or so, you start getting NFS failures with syslog
> showing "couldn't read superblock."
>
> Oh, and when I say huge maps.. I mean it. We're >10k direct mounts and I don't
> know how many indirect mounts, but it's even more then that.
What kernel and source?
Ian
next prev parent reply other threads:[~2011-02-15 3:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-08 9:30 5.0.5 non-expiring mounts Philip Ong Jr.
2011-02-11 3:10 ` Ian Kent
2011-02-15 1:10 ` Mike Marion
2011-02-15 3:11 ` Ian Kent [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2011-02-17 1:08 Deke Clinger
2011-02-17 7:57 ` Ian Kent
2011-02-17 19:21 Deke Clinger
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=1297739464.13007.8.camel@perseus \
--to=raven@themaw.net \
--cc=autofs@linux.kernel.org \
--cc=mmarion@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).