On Mon, 28 Jan 2002, Ferry Sutanto wrote:

> Thank you for all the information. I have done all
> that in normal cases. Right now, I am trying to put a
> support in the kernel in a case where the
> device/compact flash is pulled out during ftp write
> session. FTP will call write to write to the flash and
> write will call vn_write and eventuall access the
> device driver. The problem I have now is that I
> mounted the compact flash with MNT_SYNCHRONOUS so
> bwrite (in vfs_bio.c) will call biowait to wait for
> "write completion" interrupt from the device. Since
> the device is already gone, no interrupt will come,
> hence, the kernel hangs because it is waiting for
> somebody to wake the buffer it puts to sleep (using
> tsleep). I haven't solved this problem yet, but I
> encountered another one.
>
> If the kernel calls bdwrite (delayed write), how does
> it work. I see that somebody calls the bwrite and it
> will eventual do the work. What is the condition that
> the actual write will occur ?

The problem is that you shouldn't still have a file system when the device
is gone. Yor error occured earlier when you let the kernel think there was
still a devive when there wasn't.

When you get the eject event in the disk driver, you need to invalidate
the file system then.

> Question on VOP_LEASE macro. It is not really obvious
> which function will get executed for FFS. Can anybody
> point it out to me ?

Look in sys/ufs/ffs/ffs_vnode.c. There are three dispatch tables. As with
all file systems that support fifos, there is one dispatch table for fifos
(fifo_this, fifo_that in it). As for all file systems that support device
nodes, there is one for device nodes (spec_this, spec_that). Then there is
one table for everything else in the filesystem.

So for most things, ufs_lease_check gets called. For device nodes,
spec_lease_check. For fifos, fifo_lease_check.

Take care,

Bill