From owner-freebsd-usb@FreeBSD.ORG Mon Jan 28 17:37:09 2008 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2201616A41A for ; Mon, 28 Jan 2008 17:37:09 +0000 (UTC) (envelope-from henrik@gulbra.net) Received: from av12-2-sn2.hy.skanova.net (av12-2-sn2.hy.skanova.net [81.228.8.186]) by mx1.freebsd.org (Postfix) with ESMTP id ABC7913C474 for ; Mon, 28 Jan 2008 17:37:08 +0000 (UTC) (envelope-from henrik@gulbra.net) Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id 1F13437FCC; Mon, 28 Jan 2008 18:37:07 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id E7C7037F99; Mon, 28 Jan 2008 18:37:06 +0100 (CET) Received: from [192.168.0.2] (81-235-156-87-no29.tbcn.telia.com [81.235.156.87]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 8803237E43; Mon, 28 Jan 2008 18:37:06 +0100 (CET) From: Henrik Gulbrandsen To: Peter Trifonov In-Reply-To: <000901c861bc$cb8b9e90$62a2dbb0$@nord.nw.ru> References: <000901c861bc$cb8b9e90$62a2dbb0$@nord.nw.ru> Content-Type: text/plain Date: Mon, 28 Jan 2008 18:36:52 +0100 Message-Id: <1201541812.2277.418.camel@Particle> Mime-Version: 1.0 X-Mailer: Evolution 2.12.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org Subject: Re: Mounting USB flash drive X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2008 17:37:09 -0000 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