Date: Thu, 19 Jul 2007 00:57:57 +0200 From: Momchil Ivanov <idiotbg@gmail.com> To: Josh Paetzel <josh@tcbug.org> Cc: Mark Linimon <linimon@lonesome.com>, freebsd-stable@freebsd.org, LoN_Kamikaze@gmx.de Subject: Re: removing external usb hdd without unmounting causes reboot? Message-ID: <200707190057.57987.idiotbg@gmail.com> In-Reply-To: <200707181403.13410.josh@tcbug.org> References: <200707181541.l6IFf4ht051775@lurza.secnetix.de> <20070718173406.GA16748@soaustin.net> <200707181403.13410.josh@tcbug.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 gone, so you do not have to care about it. The state of the drive`s filesystem is of no interest since you cannot to anything to change it any more. The point is that the drive is gone. If you were in the middle of a write, you just return an error (like your disk is going physically bad/ some broken cable issue... for instance) and forget about the data you wanted to write, the drive is not there any more. Maybe I am naive and uneducated enough (don`t know how freebsd does things, 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 errors to the programs trying any I/O on that drive. May be when a drive is unplugged the OS has to mark it and the mounted file systems as not being there until all opened files on it are closed, return errors for all I/O except for closing opened files. And when all files are closed consider the 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 is in a consistent state after drive disconnect is something completely different (wanted to discuss just disconnecting devices, not filesystems that can be disconnected without unmount, not ensuring fully operational file system even it a case of disconnected drive). One can try to implement something here (as mentioned in some of the replies), but not necessary. If the user has unpluged the device without unmounting it first he might be left with a broken file system on that drive, we cannot do anything, so we should not care about it, it`s his mistake and his fs fucked up. The point is that unpluging should not lead to system crash, which is in my opinion critical system error. I as user I should be able to unplug any external device without crashing the OS. Doing this and thus leaving me with a broken filesystem or some other device issues should be considered my error. Thus I should learn the hard way to unmount first. Designing a filesystem or some hacks to ensure consistent state after 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..... -- PGP KeyID: 0x3118168B Keyserver: pgp.mit.edu Key fingerprint BB50 2983 0714 36DC D02E 158A E03D 56DA 3118 168B
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707190057.57987.idiotbg>