Date: Thu, 01 Nov 2007 13:37:37 +0100 From: Henrik Gulbrandsen <henrik@gulbra.net> To: freebsd-usb <freebsd-usb@freebsd.org> Subject: Re: Patches for usb/46176 (problems with umass removal before unmount) Message-ID: <1193920657.1166.192.camel@Particle> In-Reply-To: <1193917730.1166.186.camel@Particle> References: <1193917730.1166.186.camel@Particle>
next in thread | previous in thread | raw e-mail | index | archive | help
Well, apparently the list is stripping even small binary attachments, so
I guess I'll just have to point you to a suitable location on the web:
http://www.gulbra.net/freebsd-usb/umass.tar.gz
/Henrik
On Thu, 2007-11-01 at 12:48 +0100, Henrik Gulbrandsen wrote:
> This is not a complete fix, but this bug has been, eh... bugging me ever
> since I first crashed my system back in 2004. I had a set of patches for
> 5.3-BETA3, but it was too late to have it included on the 5.3 track, and
> since I was expecting some heavy redesign in the involved kernel parts,
> I dropped the patch delivery.
>
> Unfortunately, not that much has changed in this area in the past three
> years, and the current behavior is still far from the ideal I'd prefer:
> when you plug in a USB memory stick, a new directory is automatically
> mounted, and when it is unplugged, the directory silently disappears.
>
> The attached umass.tar.gz file contains patches and scripts that will
> give you this functionality in about 99% of the cases. The exact point
> of failure had moved a little since 5.3-BETA3, but the panic is still
> not difficult to avoid. However, the code is still highly experimental.
> In about 1% of USB detaches, the kernel will freeze. More specifically,
> in my four test runs, it happened after 63, 107, 6, and 321 cycles of
> attach followed by detach. Your mileage will most likely vary.
>
> I understand that the disk and file systems were not really designed for
> disappearing devices, so it's not that surprising if some lock is left
> locked under some circumstances. Or something completely different :-)
> Normally, I would continue looking for it, but I have other plans for
> the next month or two, so I don't know if I'll get the time. Perhaps
> someone else is interested enough to give it a shot...
>
>
> Anyway, here is a quick overview of the contents of umass.tar.gz:
>
> etc/usbd.conf.patch: an added entry in the usbd.conf file, to handle the
> umass devices. Yeah, I know... this should probably have used devd.conf
> instead, but this part is three years old and I didn't want to rerun the
> 321 attach/detach tests to verify that there is no important difference.
>
> etc/usbd/umass: the script that handles mounting and unmounting of the
> device directory under /media. I tried to make it work as expected, but
> I only have a single environment and a single USB memory stick to test
> with, so there may be some issues left. You'll get the gist, though...
>
> home/.umass: the main umass script will mount a directory if there is a
> single X11 user, or if there is no X11 user but a single user logged in
> at a local text terminal. The new directory will be owned by that user.
> If a .umass file exists in the user's home directory, it will be run to
> do more advanced things with the data. The included .umass is an example
> script that opens the GNOME file manager when the directory is mounted.
>
> src/msdosfs_vfsops.c.patch: the msdosfs will normally try to write the
> "clean" bit back to disk at unmount. When the drive is unplugged without
> warning, this would not only leave the file system marked as dirty, but
> will also cause a write failure. This patch modifies the implementation
> to keep the bit clean all the time if the file system is mounted with
> the "-o sync" option. This should be the case for USB memory sticks.
>
> src/usb_subr.c.patch: the usbd fails to match a usbd.conf entry during
> detach, since the detach event is filled in after the device is gone.
> This is easily fixed by moving a line to fill in the information before
> we clear all the relevant data.
>
> src/vfs_bio.c.patch: when the device is gone, remaining write attempts
> will correctly fail with ENXIO, but the failed buffer will get stuck in
> the sync queue. In 5.3-BETA3, this wasn't obvious until it blocked the
> unmounting of file systems at shutdown. Nowadays, it's detected earlier
> but this patch still seems to help.
>
> src/vfs_mount.c.patch: the only null-pointer problem left in the way of
> detaching is when the unmounting code discovers that it couldn't access
> the device and attempts to backtrack the correct handling already done.
> This patch makes it ignore the ENXIO error and finish the unmounting.
>
>
> That's it. I would hate to see another major release of FreeBSD where a
> system must be rebooted just because you forgot to do the umount before
> unplugging a umass device. It may again be too late to fix the remaining
> problems in time for the release, but I am at least hoping to see things
> work in 8-CURRENT Real Soon Now...
>
> /Henrik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1193920657.1166.192.camel>