Mounting USB flash drive

[Henrik Gulbrandsen]

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