Coda File System

Re: unmounting /coda

From: Jan Harkes <jaharkes_at_cs.cmu.edu>
Date: Thu, 12 Jul 2001 11:20:26 -0400
Why 3 virtually identical emails?


On Thu, Jul 12, 2001 at 08:00:42AM -0700, Ed Kuo wrote:
> 
> Sorry again
> > 
> > Sorry for the spam again.
> > I try to shutdown venus by vutil -shutdown, ok.
> > But able to umount /coda---------->umount: /coda:
> device is busy\
> It was "unable"
> > 
> > Is there really nothing I can do except rebooting
> linux?
> > Thanks in advance.

The problem is that some application still has a reference to a file or
directory in /coda, possibly the one that triggered venus to crash, but
anything that has it's 'current working directory' somewhere in /coda
will hold a reference. The filehandles/inodes have been turned into bad
ones so any subsequent operations will fail with ENXIO or ENODEV or
something.

However, the mounted filesystem (i.e. it's superblock) is the owner of
all inodes that were created. There is no way of telling the Linux VFS,
'take these from me', or 'forget about these'. As a result, the VFS
refuses to unmount the mounted /coda filesystem and there is nothing we
can really do about it from the kernel side of things.

>From userspace you have some options. Reboot the system. Or hunt down
all applications that have a reference to a file or directory in /coda.
fuser and lsof are a lot of help for this. However an application's
current working directory often doesn't show up which makes it necessary
to start killing off various shells, xterms and apps that might have
been started while you were somewhere in /coda.

Oh, and sometimes it's a system cron script that happened to wander into
the /coda namespace (locate/updatedb comes to mind).

Jan
Received on 2001-07-12 11:20:29