Re: Busy inodes after umount

[Tad Dolphay]

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?
> >
> >
> >
>