From owner-freebsd-stable@FreeBSD.ORG Wed Jul 18 22:58:01 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 7CECB16A405 for ; Wed, 18 Jul 2007 22:58:01 +0000 (UTC) (envelope-from idiotbg@gmail.com) Received: from smtp.studnetz.uni-leipzig.de (smtp.studnetz.uni-leipzig.de [139.18.143.252]) by mx1.freebsd.org (Postfix) with ESMTP id 120A813C4BA for ; Wed, 18 Jul 2007 22:58:01 +0000 (UTC) (envelope-from idiotbg@gmail.com) Received: from localhost (localhost [127.0.0.1]) by smtp.studnetz.uni-leipzig.de (Postfix) with ESMTP id 5DEF926C; Thu, 19 Jul 2007 00:58:00 +0200 (CEST) X-Virus-Scanned: by amavisd-new at studnetz-ul Received: from smtp.studnetz.uni-leipzig.de ([127.0.0.1]) by localhost (smtp.studnetz.uni-leipzig.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9xHYxd6EdiZ; Thu, 19 Jul 2007 00:58:00 +0200 (CEST) Received: from [192.168.63.4] (a144026.studnetz.uni-leipzig.de [139.18.144.26]) by smtp.studnetz.uni-leipzig.de (Postfix) with ESMTP id C0FAB26B; Thu, 19 Jul 2007 00:57:59 +0200 (CEST) From: Momchil Ivanov To: Josh Paetzel Date: Thu, 19 Jul 2007 00:57:57 +0200 User-Agent: KMail/1.9.6 References: <200707181541.l6IFf4ht051775@lurza.secnetix.de> <20070718173406.GA16748@soaustin.net> <200707181403.13410.josh@tcbug.org> In-Reply-To: <200707181403.13410.josh@tcbug.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200707190057.57987.idiotbg@gmail.com> Cc: Mark Linimon , freebsd-stable@freebsd.org, LoN_Kamikaze@gmx.de 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: Wed, 18 Jul 2007 22:58:01 -0000 On Wednesday 18 July 2007 21:03:10 Josh Paetzel wrote: > On Wednesday 18 July 2007, Mark Linimon wrote: > > On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote: > > > Bottom line here is that the kernel panics when removing a USB > > > device that has filesystems mounted. > > > > s/USB // > > > > > I also have a hard time believing that the reason it hasn't been > > > fixed is because "there isn't an easy fix". I'm under the > > > impression it hasn't been fixed because either no one cares > > > enough to fix it (using the workaround as a scapegoat excuse), or > > > because the majority of people do not use USB-based storage > > > devices. > > > > The reason is not the USB stack; the reason (IIRC) is that the > > FreeBSD VM was written with the default assumption that Devices > > Never Go Away. A large rewrite, I'm told, will be needed to fix > > this, and the code is convoluted and tricky. > > > > No one finds the situation acceptable; introducing the "scapegoat" > > word isn't going to win you any support. The problem is not a > > weekend's worth of work to fix, nor does it have anything to do > > with avoidance by one particular maintainer, which you apparently > > had encountered before. > > > > mcl > > Panicing really is the right thing to do with the current > architecture. Not panicing when a mounted filesystem disappears runs > the risk of corrupting other mounted filesystems. > > Mark is entirely correct, FreeBSD faces an architecture problem here > in that the vm and filesystems we have today were not designed in an > era when they could just disappear from a running system. The BSD > way isn't to apply a quick and dirty little hack to fix > the 'problem', it's to design the system properly. And this is > assuming a quick and dirty hack even exists. > > The other problem you're running in to with UFS anyways is that there > is no chance to 'unmount' the filesystem when you disconnect the > drive. By the time anything has a chance to realize it's gone it's > too late. Whether the disk is in the middle of a write, still has > buffers to be written out, or is perfectly clean and needs to just be > marked as such by the time the OS realizes any of that needs to be > done the drive is no longer physically connected to the computer. I think you are missing the point here and it is that the drive is already= =20 gone, so you do not have to care about it. The state of the drive`s=20 filesystem is of no interest since you cannot to anything to change it any= =20 more. The point is that the drive is gone. If you were in the middle of a=20 write, you just return an error (like your disk is going physically bad/ so= me=20 broken cable issue... for instance) and forget about the data you wanted to= =20 write, the drive is not there any more.=20 Maybe I am naive and uneducated enough (don`t know how freebsd does things,= =20 nor am I a programmer) but I will give my 2 "stotinki" here. The most natural way for me seems to be that the OS should just return erro= rs=20 to the programs trying any I/O on that drive. May be when a drive is=20 unplugged the OS has to mark it and the mounted file systems as not being=20 there until all opened files on it are closed, return errors for all I/O=20 except for closing opened files. And when all files are closed consider the= =20 fs as unmounted and remove the drive from the kernel. This is my idea of how things should be done. Ensuring that a file system i= s=20 in a consistent state after drive disconnect is something completely=20 different (wanted to discuss just disconnecting devices, not filesystems th= at=20 can be disconnected without unmount, not ensuring fully operational file=20 system even it a case of disconnected drive). One can try to implement=20 something here (as mentioned in some of the replies), but not necessary. If= =20 the user has unpluged the device without unmounting it first he might be le= ft=20 with a broken file system on that drive, we cannot do anything, so we shoul= d=20 not care about it, it`s his mistake and his fs fucked up. The point is that= =20 unpluging should not lead to system crash, which is in my opinion critical= =20 system error. I as user I should be able to unplug any external device without crashing t= he=20 OS. Doing this and thus leaving me with a broken filesystem or some other=20 device issues should be considered my error. Thus I should learn the hard w= ay=20 to unmount first. Designing a filesystem or some hacks to ensure consistent state after=20 disconnect should not be in the scope of this thread and problem, I think. > > What might need to happen is a redesign of the vm subsystem so that it > can safely deal with mounted filesystems going away, and designing a > filesystem that doesn't need to be unmounted specifically for > removeable devices. Doesn't sound trivial to me. > > Or > > You can just not remove devices with mounted filesystems from your > computer..... =2D-=20 PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E =A0158A E03D 56DA 3118 168B =20