Re: usb flash drive removal (Re: Desktop NetBSD needs your help)

[Michal Suchanek <hramrach%centrum.cz@localhost>]

On 09/02/2009, Arnaud Lacombe <lacombar%gmail.com@localhost> wrote:
> On Mon, Feb 9, 2009 at 11:33 AM, Eric Haszlakiewicz 
> <erh%nimenees.com@localhost> wrote:
>  > On Mon, Feb 09, 2009 at 10:51:32AM -0500, Arnaud Lacombe wrote:
>  >> Hi,
>  >>
>  >> On Mon, Feb 9, 2009 at 10:33 AM, Eric Haszlakiewicz 
> <erh%nimenees.com@localhost> wrote:
>  >> > I think that there should not _be_ a wrong time to remove a USB drive.
>  >> > Yes, it may be hard to implement it in NetBSD, but it is entirely 
> possible
>  >> > to have a system that doesn't crash, and even does something reasonable.
>  >> > (e.g. like providing an api for prompting the user to reattach the 
> device)
>  >> >
>  >> You cannot ensure that the device is the same state than previously.
>  >> You cannot even ensure that the newly plugged device is the same that
>  >> the old one. The only sane thing to do is to clean-up everything.
>  >
>  > No, you're wrong.  You CAN ensure, with a reasonably high degree of 
> certainty,
>  > that the device is the same as the old one.
>
> Sorry to say that, but if it's not 100% of certainty you won't go far.
>
>
>  > Do all of the following:
>  > 1) A device is unplugged
>  >  a) If there is no unwritten data cached, gracefully unmount the device and
>  >  revoke any open file descriptors when the device is unplugged.
>  >  b) If there _is_ data cached, keep the mount around in a suspended state,
>  >     saving information about the device and in-flight data until later.
>  >     b.i) Issue an event that alerts the user that he should plug the device
>  >            back in.
>  > 2) When a device is reattached
>  >  a) If the device has a dependable hardware id of some kind, compare that
>  >        with what the previous id was.
>
> in the mean time, I took a picture with my camera/got a phone call,
>  the file-system on the device changed, you replug-it, things are not
>  as they used to be... and boom! There is billion reasons for a device
>  to alter its file-system while it is supposedly doing nothing. In the
>  best case, we crash, in the worst case, we corrupt the remote
>  file-system. Not speaking that you'll need to keep track of every
>  possible unique ID that can exist, good luck.
>
>

Many filesystems have "last mount time" in their superblock.

It's also possible to never attempt a reattach (and much easier and
less error-prone, too).

However, sometimes a bus reset can happen for various reasons on these
external buses, and these must be handled so you can't be ever 100%
sure that it's still the same device you are talking to.

What is not optional is that a sane system should not crash which is
what currently happens way too often.

Thanks

Michal