Hello,
We have seen the same message on a box with vanilla 2.4.18 kernel with
rmap12h patch. Mount version is 2.11b and autofs4-4.0.0pre10-10 (SuSe
package). If it matters, we are using only nisplus to get our maps.
I know the above setup is kinda old. We are still having some other issues
moving to a newer release.
<< ryan
On Thu, 11 Sep 2003, H. Peter Anvin wrote:
> Arun Sharma wrote:
> >
> > We've seen a few "VFS: Busy inodes after unmount. Self-destruct in 5
> > seconds. Have a nice day.." messages on a dual processor NFS client.
> > Here's the use case:
> >
> > - Due to network load issues, the NFS server becomes unreachable for
> > some time
> > - The automounter tries to expire the mount
> > - The unmount finds a couple of busy inodes. Putting some debug printks
> > shows that typically two inodes are busy i.e. have inode->i_count == 1.
> > But they don't have any waiters on inode->i_wait. Further, the inodes
> > that are busy are
> > /mnt/foo -> autofs mount point
> > /mnt/foo/bar -> bar is a symbolic link
> >
> > It's not clear if this is a NFS issue or a autofs issue, but it's seen
> > often with autofs. Are there any known race conditions that have been
> > fixed after 2.4.20 ? The two calls I'm worried about are:
> >
> > fs/autofs/root.c:305: d_instantiate(dentry, iget(dir->i_sb,ent->ino));
> > fs/autofs/root.c:416: d_instantiate(dentry, iget(dir->i_sb,ino));
> >
>
> Which version of autofs are you running? What version of mount(8)?
>
> It's possible NFS lets you umount a mount which has busy inodes under
> certain conditions. autofs stresses mounting/umounting NFS in ways that
> sometimes exposes bugs that otherwise wouldn't be seen.
>
> -hpa
>
> _______________________________________________
> autofs mailing list
> [EMAIL PROTECTED]
> http://linux.kernel.org/mailman/listinfo/autofs
>
_______________________________________________
autofs mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/autofs
