[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: usb flash drive removal (Re: Desktop NetBSD needs your help)
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
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
Michael van Elst
"A potential Snark may lurk in every tree."
Main Index |
Thread Index |