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

[Michael van Elst <mlelstv%serpens.de@localhost>]

On Tue, Feb 10, 2009 at 02:23:33AM +0200, Antti Kantee wrote:
> On Mon, Feb 09, 2009 at 09:04:55PM +0000, Michael van Elst wrote:
> > lacombar%gmail.com@localhost (Arnaud Lacombe) writes:
> > 
> > >> 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.
> > 
> > It actually works fine on those systems that use this method.
> > 
> > 
> > >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!
> > 
> > And boom, suddenly there is new or changed data in the filesystem.
> > Just like it could happen on a network filesystem.
> 
> Boom, the problem is unexpected metadata.  Any disk file system
> goes south lightspeed if there isn't a match between on-media and
> in-memory metadata.

That's the part where I said to 'drop cached data'. There can only
be mismatch if you have outstanding writes.

> Network fail systems aren't a valid comparison,
> since their protocols are at a completely different logical level
> than on-disk file systems.

You know, that's not necessarily true. Nothing prevents you from
handling such failures in a graceful manner. The worst thing that
can happen is that writes cannot be completed, so you may end with
incomplete and sometimes corrupted data on disk.

> Generally speaking, I would consider it extremely unwise to add
> code to attempt to recover a mount for a device which was forcibly
> unplugged.

There used to be systems that handled it fine. In most cases the
mount could be recovered, if the user followed instructions. In
the worst case you got a corrupted file system (and no tool
to recover, but that's a different story) and the writing
process was left dead waiting for the file system to reappear
(which is again a different story).

There is obviously a difference between how such systems and
UNIX use data on a disk, in particular system files or swap,
but we aren't talking on handling recovery of the / mount.

> And of course you never want to mount untrusted file systems using
> a kernel file server, but everyone knows that by now.

The fact that our file system code crashes and burns if presented
'untrusted' data shouldn't be a model for removable media. And
that's independent of kernel vs. userland implementation.

But if you think a userland implementation is fine, I have no
worries :)

Greetings,
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."