DragonFly commits List (threaded) for 2007-06
DragonFly BSD
DragonFly commits List (threaded) for 2007-06
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: cvs commit: src/sys/bus/cam cam_sim.c cam_sim.h


From: "Jonas Trollvik" <jontro@xxxxxxxxx>
Date: Thu, 14 Jun 2007 13:21:32 +0200

Does this mean that we can do the same functionality for smbfs, i.e.
if the network connection is lost make it able to reconnect / unmount
it?

//Jonas

On 6/14/07, Matthew Dillon <dillon@apollo.backplane.com> wrote:
:  Do not destroy the device queue, it is needed by the peripheral code
:  (e.g. scsi/scsi_da.c, etc) even if the backend hardware has disappeared.
:  When cam_sim_free() is called, set up a dummy poll and action callback
:  and make the action callback generate an I/O error.
:
:  This allows things like filesystem mounts of USB memory sticks to start
:  returning I/O errors instead of blocking forever if the stick is pulled.
:
:  Revision  Changes    Path
:  1.9       +34 -5     src/sys/bus/cam/cam_sim.c
:  1.6       +0 -1      src/sys/bus/cam/cam_sim.h

   I'm still working on this.  umount works with the USB memory stick
   pulled, but the system will panic with 'dangling vnodes' under
   numerous conditions.  I am going to try to track some of them down.
   Theoretically we should be able to make the system robust enough to
   deal (as in not crash) with a pulled stick even if programs are CD'd
   into the mount.

   It would be really cool if the system could 'reconnect' to a USB memory
   stick if it is pulled and then put back in, but that's a project for
   another time (or for someone else to do!)... I don't even know if USB
   memory sticks have working serial numbers in order to figure out that
   the stick inserted is the same one that was ripped out.

-Matt




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]