From: Tad Dolphay <tbd@sgi.com>
To: mjacob@feral.com
Cc: xfs@ragnark.vestdata.no (Ragnar Kjørstad),
chip.christian@storageapps.com (Christian Chip),
linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: Busy inodes after umount
Date: Thu, 19 Jul 2001 19:38:15 -0500 (CDT) [thread overview]
Message-ID: <200107200038.TAA40153@fsgi158.americas.sgi.com> (raw)
In-Reply-To: <20010719165758.D50024-100000@wonky.feral.com> from "Matthew Jacob" at Jul 19, 2001 04:58:36 PM
I know there was a fix for a "Busy inodes after unmount" problem in
2.4.6-pre3. Here's an excerpt from a posting to the NFS mailing list
from Neil Brown:
-------------Included message-----------------------
Previously anonymous dentries were hashed (though with no name, the
hash was pretty meaningless). This meant that they would hang around
after the last reference was dropped. This was actually fairly
pointless as they would never get referenced again, and caused a real
problem as umount wouldn't discard them and so you got the message
printk("VFS: Busy inodes after unmount. "
"Self-destruct in 5 seconds. Have a nice day...\n");
In 2.4.6-pre3 I stopped hashing those dentries so now when the last
reference is dropped, the dentry is freed. So now there will never be
more anonymous dentries than there are active nfsd threads.
---------------end included message-------------------
Tad
>
> I reported this a couple of months back. It's reassuring to know that it's a
> consistent problem.
>
> On Fri, 20 Jul 2001, [iso-8859-1] Ragnar Kjørstad wrote:
>
> > On Thu, Jul 19, 2001 at 04:22:07PM -0400, Christian, Chip wrote:
> > > I found the same thing happening. Tracked it down in our case to using fdisk to re-read disk size before mounting. Replaced it with "blockdev --readpt" and the problem seems to have gone away. YMMV.
> >
> > I've now been able to reproduce:
> >
> > * make a filesystem
> > * mount it
> > * export it (nfs)
> > * mount on remote machine
> > * lock file (fcntl)
> > * unexport
> > * unmount
> >
> > Then you get the VFS message about self-destruct. Tested with both ext2
> > and xfs.
> >
> > The lock is still present in /proc/locks after the umount.
> >
> > With ext2 I can remount the filesystem successfully, but with XFS I get
> > the message about duplicate UUIDs and the mount failes. I believe this is a totally
> > different problem from the one you were experiencing. (and blockdev doesn't help for me)
> >
> > I suppose this is a generic kernel bug?
> >
> >
> >
>
next prev parent reply other threads:[~2001-07-20 0:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <23D04BDBA646D411BDDD00D0B774B53902963BE8@SA-BWMAIL1>
2001-07-19 23:53 ` Ragnar Kjørstad
2001-07-19 23:58 ` Matthew Jacob
2001-07-20 0:38 ` Tad Dolphay [this message]
2001-07-20 0:49 ` Ragnar Kjørstad
2001-07-31 0:15 ` Ragnar Kjørstad
2001-08-02 11:34 ` Neil Brown
2001-08-01 8:18 ` Tony Gale
2001-08-01 18:05 ` Ragnar Kjørstad
2001-08-01 18:30 ` Steve Lord
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=200107200038.TAA40153@fsgi158.americas.sgi.com \
--to=tbd@sgi.com \
--cc=chip.christian@storageapps.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@oss.sgi.com \
--cc=mjacob@feral.com \
--cc=xfs@ragnark.vestdata.no \
/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
all inboxes | Powered by JetHome®