Re: FS Development (or interrupting ls)

[Jan Harkes <jaharkes@cs.cmu.edu>]

On Thu, Aug 02, 2001 at 08:26:04PM -0400, Sujal Shah wrote:
> 
> I'm working on a userspace filesystem daemon which replaces Venus (from
> CODA) or podfuk (UserVFS) using the CODA driver.  I'm still early in my
> development process, but I've run into one frustrating problem.  While
> testing my code, I have started causing ls to hang. 
> 
> It keeps the directory open, which means I can't do things like, oh,
> unmount the filesystem. :-)  Anyone have any suggestions on recovering
> gracefully when this happens short of rebooting (which is what I do
> now)?  Basically, 'ls' hangs, and can't be killed (even kill -9) and
> 'lsof' lists the directory as open (which is furthered confirmed by
> umount complaining about the filesystem being busy).

Kill the userspace daemon, when the /dev/cfs0 device is closed all
pending upcalls are aborted and further accesses to /coda will return
EIO or something.

You still won't be able to unmount until all processes that have a
reference to a file in /coda, typically caused by their 'cwd', i.e.
use cd to move shell's out of the /coda tree and kill off any
applications that were started from a shell that was at the time in
/coda.

It is unusual that you are unable to kill ls, all upcalls to the
userspace process should be interruptable (except for close). There
might be something wrong in the way you created your directory container
files and the kernel gets stuck in readdir, but strace or enabling
verbose debugging from the kernel module should help you narrow it down.
(echo 1 > /proc/sys/coda/printentry ; echo 4095 > /proc/sys/coda/debug)

Jan