Date: Mon, 28 Jan 2008 18:36:52 +0100 From: Henrik Gulbrandsen <henrik@gulbra.net> To: Peter Trifonov <petert@dcn.nord.nw.ru> Cc: freebsd-usb@freebsd.org Subject: Re: Mounting USB flash drive Message-ID: <1201541812.2277.418.camel@Particle> In-Reply-To: <000901c861bc$cb8b9e90$62a2dbb0$@nord.nw.ru> References: <000901c861bc$cb8b9e90$62a2dbb0$@nord.nw.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2008-01-28 at 17:48 +0300, Peter Trifonov wrote: > I am trying to configure FreeBSD 6.3 to allow hot removal of USB flash cards > without their manual unmounting. > I have successfully used the patches by Henrik Gulbrandsen > (http://www.freebsd.org/cgi/query-pr.cgi?pr=46176&cat= ) > to avoid kernel panic after device removal, and the only problem remaining > is cache management. Peter, I think you may be overly optimistic here. The patches that you are referring to (those that have already been committed to the tree) are only part of the full solution. Even if you integrate the full set of current patches (from http://www.gulbra.net/freebsd-usb/ ), things have only been alpha-tested on 8.0-CURRENT. Older kernels will have their own ways of failing, and I guess even 8.0-CURRENT will have regressions as it starts changing. Just so you know what you're into, the partial fix may seem to work, but can give you a system panic after up to a few hundred detach attempts. Or after less than ten attempts. It's really a random timing issue. That doesn't mean that it is impossible to fix the bug for FreeBSD 6.3. It just means that (a) you're basically on your own, and (b) you will have to test it very carefully. 1000 attach/detach cycles take about 2-3 hours of manual testing. You really don't want to do it. If you're about to do it anyway, I'd recommend having some good background music... > If the device is mounted without the sync option, the performance is > perfect, but hot removal > sometimes causes data corruption on the flash disk. If sync option is used > while mounting the device, > write performance becomes terrible (20 KB/s). Is there any way to improve > write performance with sync option > or prevent data corruption without it? No idea. I guess you can always use a noasync mount and regularly call sync(8) to limit the time before it's safe to detach the disk. That may work if users know that they must wait x seconds after finished writing. However, you should know that an msdosfs will try to write the "clean" bit back to disk at unmount. Besides the fact that this writing will obviously fail when the disk is gone, the combination of writing and releasing of kernel structures will exercise other parts of the code, which probably means an increased likelihood of system panic. This is handled in a patch for -o sync, but may give problems without it. > I understand that umount should be used to completely avoid these problems, > but in my case it is not > possible to invoke it, since the users will not be given shell access. Again, be careful! If possible, I would recommend avoiding hot removal for the moment. With the right kernel version, patches, and testing, it will be stable enough for a personal desktop or an internal server, where an occasional crash is not a catastrophe, but keep in mind that this is very much CURRENT code and definitely not STABLE... /Henrik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1201541812.2277.418.camel>