NetBSD kernel gurus ...

Another question. 

Can I assume that there is only 1 (one) inode per file
in a file system ? 

Thanks!

Ferry

--- Ferry Sutanto <fsutanto@yahoo.com> wrote:
> Hi Bill,
> 
> Thank you very much for the information. Can u
> elaborate more on "invalidating the file system" ?
> The
> kernel gets the "device gone" interrupt, the first
> thing it does is unmounting the FFS and call
> config_detach. Is this what u mean by "invalidating
> FFS" ?
> 
> I notice that although config_detach has finished,
> the
> kernel still tries to write by calling either
> vn_write
> or bwrite. I put little hack (a global flag == true
> if
> device has gone) which will bail out if the device
> has
> gone and I called brelse to clean up the buffer. FTP
> exit with EIO error, but the csh (shell) hangs. Does
> anybody have this problem before ? 
> 
> Thanks!
> 
> Ferry
> 
> 
> 
> --- Bill Studenmund <wrstuden@netbsd.org> wrote:
> > 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
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Great stuff seeking new owners in Yahoo! Auctions! 
> http://auctions.yahoo.com


__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com