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= =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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707190057.57987.idiotbg>