From owner-freebsd-stable@FreeBSD.ORG Thu Jul 19 15:04:33 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A330A16A405 for ; Thu, 19 Jul 2007 15:04:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 632F813C494 for ; Thu, 19 Jul 2007 15:04:33 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.8/8.13.4) with ESMTP id l6JF2iJo085460; Thu, 19 Jul 2007 09:02:44 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 19 Jul 2007 09:02:50 -0600 (MDT) Message-Id: <20070719.090250.1387160138.imp@bsdimp.com> To: idiotbg@gmail.com From: "M. Warner Losh" In-Reply-To: <200707190943.55428.idiotbg@gmail.com> References: <20070719130252.6880b967@localhost> <469F101C.5060906@gmx.de> <200707190943.55428.idiotbg@gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Thu, 19 Jul 2007 09:02:44 -0600 (MDT) Cc: LoN_Kamikaze@gmx.de, freebsd-stable@freebsd.org, freebsd@meijome.net, olli@lurza.secnetix.de, josh@tcbug.org Subject: Re: removing external usb hdd without unmounting causes reboot? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2007 15:04:33 -0000 In message: <200707190943.55428.idiotbg@gmail.com> Momchil Ivanov writes: : What is then the reason for the kernel not being able to unmount a : filesystem whose provider is no longer present? The problem is that the device driver has wound down, deallocated memory, etc. Now the kernel comes along with stale references to the device and panic ensues. It is really just that simple. There's no replacement of the now-dead device with dead calls. And even if you fixed that, most of the file systems in the tree today do not tolerate errors on writes at all and that also leads to panics. This is why firewire freezes the I/Os rather than failing them (and why umount -f on a firewire drive hangs). Warner