Date: Sun, 27 Jan 2008 19:36:28 +0100 From: Henrik Gulbrandsen <henrik@gulbra.net> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: oliver@freebsd.org, freebsd-usb@freebsd.org Subject: Re: usb/84336: [usb] [reboot] instant system reboot when unmounting a powered off/unplugged+replugged USB device Message-ID: <1201458988.2277.285.camel@Particle> In-Reply-To: <20080127032955.GI53741@server.vk2pj.dyndns.org> References: <200801260034.m0Q0YVVD012819@freefall.freebsd.org> <1201348494.2277.96.camel@Particle> <20080127032955.GI53741@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2008-01-27 at 14:29 +1100, Peter Jeremy wrote: > This approach doesn't work because GEOM doesn't know the drive has > gone away until it's no longer present. At that point it's too late > to write unflushed buffers. And a devfs-triggered forced unmount does > not address the issue of in-flight I/O's between when the media goes > away and the filesystem is unmounted. Well, unflushed buffers will obviously be discarded, but this scenario is focused on small umass devices, which should be mounted with -o sync. In this case, everything will typically already be written to disk. The in-flight I/O part used to be a cause of crashes, but this should work now, with the patches that Warner has already committed to 8.0-CURRENT. > This problem is one of a number of problems within FreeBSD where there > is a disconnect between the people who want the problem solved and those > with the skills to actually solve the problem. This is a side-effect of > FreeBSD being a volunteer project and it's not clear how to fix this. The "volunteer project" mantra is not an excuse to leave the difficult problems unsolved. It just means that sometimes I have to be the one who volunteers a solution. Ideally, that solution would then be reviewed and either committed to the tree or rejected for a valid technical reason. Unfortunately, there are few volunteers for this part of the process :-( On Sat, 2008-01-26 at 20:40 -0700, M. Warner Losh wrote: > One of the things that I've been working on with someone (whose name > escapes me) and Bruce Evans is trying to address these issues. One > problem we have today is that when the device return ENXIO, the buffer > cache retries the operation rather than failing it upstream. There > are a number of issues with doing this, including fixing all the > filesystems to cope with errors. I've committed a number of 'keep the > system from panicing' type fixes, but much works remains to be done. I'd like to think that I'm "someone" :-) While I agree with you that there is still work to do, I think most of it would actually be side issues not directly related to usb/46176 or usb/84336. Things should be working for USB memory sticks and cameras, but perhaps flash cards still trigger it, or file systems other than msdosfs have problems, or the fix happens to introduce a memory leak. All of these problems would be better handled with more specific PRs. Writing as the guy who actually spent two and a half hours in a futile attempt to reproduce this problem with all patches applied, I'd say that the usb/46176 problem has passed on. It is no more. It has ceased to be. This is an ex-bug! At least until someone tells me why I'm a fool! :-) /Henrik P.S. I had some extra background information here, but it turned out to be longer than expected, so I will send it as a separate email.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1201458988.2277.285.camel>