removing external usb hdd without unmounting causes reboot?

[Momchil Ivanov]

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