All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ragnar Kjørstad" <xfs@ragnark.vestdata.no>
To: Tad Dolphay <tbd@sgi.com>
Cc: mjacob@feral.com, Christian Chip <chip.christian@storageapps.com>,
	linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org,
	nfs@lists.sourceforge.net
Subject: Re: Busy inodes after umount
Date: Tue, 31 Jul 2001 02:15:47 +0200	[thread overview]
Message-ID: <20010731021546.A7750@vestdata.no> (raw)
In-Reply-To: <20010719165758.D50024-100000@wonky.feral.com> <200107200038.TAA40153@fsgi158.americas.sgi.com>
In-Reply-To: <200107200038.TAA40153@fsgi158.americas.sgi.com>; from Tad Dolphay on Thu, Jul 19, 2001 at 07:38:15PM -0500

On Thu, Jul 19, 2001 at 07:38:15PM -0500, Tad Dolphay wrote:
> > > 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?
>
> 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-------------------

I just tested with 2.4.7, and the problem remains.


-- 
Ragnar Kjorstad
Big Storage

  parent reply	other threads:[~2001-07-31  0:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <23D04BDBA646D411BDDD00D0B774B53902963BE8@SA-BWMAIL1>
2001-07-19 23:53 ` Busy inodes after umount Ragnar Kjørstad
2001-07-19 23:58   ` Matthew Jacob
2001-07-20  0:38     ` Tad Dolphay
2001-07-20  0:49       ` Ragnar Kjørstad
2001-07-31  0:15       ` Ragnar Kjørstad [this message]
2001-08-01  8:18         ` Tony Gale
2001-08-01 18:05           ` Ragnar Kjørstad
2001-08-01 18:30             ` Steve Lord
2001-08-02 11:34         ` Neil Brown

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=20010731021546.A7750@vestdata.no \
    --to=xfs@ragnark.vestdata.no \
    --cc=chip.christian@storageapps.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=mjacob@feral.com \
    --cc=nfs@lists.sourceforge.net \
    --cc=tbd@sgi.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.