From owner-freebsd-current@FreeBSD.ORG Sun Jan 30 15:37:41 2005 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 F1FB716A4CE for ; Sun, 30 Jan 2005 15:37:40 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id B555B43D54 for ; Sun, 30 Jan 2005 15:37:40 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 59F0246B32; Sun, 30 Jan 2005 10:37:40 -0500 (EST) Date: Sun, 30 Jan 2005 15:37:03 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <69175.1107098435@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Alexander Leidinger cc: imp@bsdimp.com cc: current@freebsd.org cc: pete@altadena.net cc: Warner Losh Subject: Re: Devd event from GEOM? 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, 30 Jan 2005 15:37:41 -0000 On Sun, 30 Jan 2005, Poul-Henning Kamp wrote: > In message <20050130161323.5e25414e@Magellan.Leidinger.net>, Alexander Leidinger writes: > > >Let's take a CD for example, when it arrives the auto-mounter mounts it. > >Fine, but the CD is locked then. What do we do when we want to remove > >the CD? Or another example, an USB stick. The hardware isn't locked, but > >when we just remove it, we're calling for a kernel panic. > > Now that local-storage filesystems are GEOM users, we can actually get > the "orphan" event from GEOM communicated to the filesystem which can > then take proper evasive action. No filesystem has implemented this yet. I think tolerance of hard removal faults will always be a tricky issue -- we can clearly handle it better than we do today. The user losing data is fine: if you don't want to lose data, you have to arrange for a clean unmount. However, today's panic is a bit extreme. The good news is that soft eject is a lot easier to handle, as it's more of a question of signalling and management than hard technical issues in how to tear down state at a bad moment in the kernel. Robert N M Watson