Date: Wed, 18 Jul 2007 13:11:42 -0400 From: "Zaphod Beeblebrox" <zbeeble@gmail.com> To: "Baldur Gislason" <baldur@foo.is> Cc: LoN_Kamikaze@gmx.de, freebsd-stable@freebsd.org, Momchil Ivanov <idiotbg@gmail.com>, josh@tcbug.org Subject: Re: removing external usb hdd without unmounting causes reboot? Message-ID: <5f67a8c40707181011n768ad311y9a9dd76a59dde428@mail.gmail.com> In-Reply-To: <20070718163642.GY36311@gremlin.foo.is> References: <200707181541.l6IFf4ht051775@lurza.secnetix.de> <200707181830.48727.idiotbg@gmail.com> <20070718163642.GY36311@gremlin.foo.is>
next in thread | previous in thread | raw e-mail | index | archive | help
Nobody's said what the problem is. I'm not a filesystem code monkey, but IIRC, the problem is that the filesystem plays fast and loose with pointers and is too closely related to the VM. One solution is (as mentioned) a userland filesystem that doesn't panic. automount approximates this if you set the disconnect interval short (< 5 seconds). The other way to look at this, though, is the general goal of "not panicing" when it can be avoided. As a research OS, it's my feeling that BSD derived unixes have followed the "if in doubt, panic" regime. I don't think this is appropriate to a modern desktop or server OS. To my mind, an OS should only panic if there are indications of hardware corruption in a subsystem that can't be turned off. Ie: memory bad: panic; controller bad, turn off controller. In this particular case, we have unmount -f. If there are no dirty buffers, the USB system triggering the equivalent of unomunt -f should succeed. If we only mount usb devices async, this should be sufficient for most cases. If there are dirty buffers, what do we loose by just forgetting about them? The filesystem on the device is already as corrupt as its going to be...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5f67a8c40707181011n768ad311y9a9dd76a59dde428>