From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 05:59:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69E4F16A4CE for ; Sun, 26 Sep 2004 05:59:10 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D69343D31 for ; Sun, 26 Sep 2004 05:59:10 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i8Q5x9vA081057; Sat, 25 Sep 2004 22:59:09 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i8Q5x9B9081056; Sat, 25 Sep 2004 22:59:09 -0700 (PDT) (envelope-from dillon) Date: Sat, 25 Sep 2004 22:59:09 -0700 (PDT) From: Matthew Dillon Message-Id: <200409260559.i8Q5x9B9081056@apollo.backplane.com> To: "Daniel O'Connor" References: <41555396.4030009@fer.hr> <20040926021347.721a025f.benlutz@datacomm.ch> <200409261142.24759.doconnor@gsoft.com.au> cc: freebsd-current@freebsd.org cc: Jeremy Chadwick Subject: Re: USB memory stick hotswap problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2004 05:59:10 -0000 :> Can't usbd (or better yet, usbd.conf) be modified or changed in some way :> to automatically handle the unmounting of any existing filesystems that :> match the device which is mounted? :> :> Seems like we're eventually going to need this to make hot-swappable USB :> devices more friendly. I understand why you must unmount a device :> before SCSI CAM gets disconnected from it, but it just seems that this :> should be a job for usbd. : :The problem is that once the device is removed it's too late :( : :One possibility would be to add a facility to mark all the data for a certa= :in=20 :device to be non-critical so it will throw it away when it tries to flush i= :t=20 :and fails instead of panicing. It's a fairly simple matter to make the I/O requests fail, CAM is actually quite good at that. But preventing filesystem panics requires a lot more work. Three things must be done: * The filesystem has to be able to error-out gracefully when read I/O's fail. * A mechanism for handling write errors, in particular synchronous write errors, is needed. Generally speaking the buffer cache must retain the (dirty) data, which it actually mostly does already, and the filesystem has to be able to proceed with the operation despite the write error in order to get to a stable point where it can either error out or complete the op. * The buffer flushing code has to be made aware of a dead backing device and do the right thing with the dirty buffers when the filesystem is forcefully unmounted. I did some work on the buffer cache dirty data issue a while back, a few years ago, so the buffer cache already deals with write errors somewhat, but more work is needed. -Matt