(Illustration by Gaich Muramatsu)
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). JanReceived on 2001-07-12 11:20:29