From owner-freebsd-current@FreeBSD.ORG Sun Sep 26 20:41:36 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 6229A16A4CE for ; Sun, 26 Sep 2004 20:41:36 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75ABC43D5C for ; Sun, 26 Sep 2004 20:41:35 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (harmony.village.org [10.0.0.6]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id i8QKeVAH069683; Sun, 26 Sep 2004 14:40:31 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 26 Sep 2004 14:41:40 -0600 (MDT) Message-Id: <20040926.144140.45874749.imp@bsdimp.com> To: benlutz@datacomm.ch From: "M. Warner Losh" In-Reply-To: <20040926182113.7ccffc2c.benlutz@datacomm.ch> References: <20040926005943.GA61350@parodius.com> <200409261036.49484.Lucas.James@LDJcs.Com.Au> <20040926182113.7ccffc2c.benlutz@datacomm.ch> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org 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 20:41:36 -0000 In message: <20040926182113.7ccffc2c.benlutz@datacomm.ch> Benjamin Lutz writes: : > We should be telling the kernel at some point that this is a removable : > device, and not have the kernel complain if we umount it when the device : > has already disappeared (assuming that we have mounted it with -o sync). : : Even if it's mounted async, the kernel should just shrug, flush the now : useless stuff from memory, and get on with it's live. Maybe a log entry : could be made when there's still unwritten data that has now been lost. : : I'm anxious to see what phk comes up with :) There's multiple problems with devices going away. In this case, there kernel has references to the device that goes away and tries to flush its buffers to the now defunt device. Bad kharma ensues. phk's device work should help this somewhat, but there aren't any sleepers, per se, in this case, so I'll be very interested to see how he deals with that issue. Warner