> All that and yet the fact > remains: I've never "ejected" a USB > drive from OS X or Windows, I simply pull it and go, > and I've never once lost data, or had it become > unrecoverable or even corrupted.<br> > <br>And yes, I do keep checksums of all the data > sitting on them and periodically check it. So, > for all of your ranting and raving, the fact remains > even a *crappy* filesystem like fat32 manages to > handle a hot unplug without any prior notice without > going belly up.<br> > <br>--Tim<br></div></div>
Just wanted to chime in with my 2c here. I've also *never* unmounted a USB drive from windows, and have been using them regularly since memory sticks became available. So that's 2-3 years of experience and I've never lost work on a memory stick, nor had a file corrupted. I can also state with confidence that very, very few of the 100 staff working here will even be aware that it's possible to unmount a USB volume in windows. They will all just pull the plug when their work is saved, and since they all come to me when they have problems, I think I can safely say that pulling USB devices really doesn't tend to corrupt filesystems in Windows. Everybody I know just waits for the light on the device to go out. And while this isn't really what ZFS is designed to do, I do think it should be able to cope. First of all, some kind of ZFS recovery tools are needed. There's going to be an awful lot of good data on that disk, making all of that inaccessible just because the last write failed isn't really on. It's a copy on write filesystem, "zpool import" really should be able to take advantage of that for recovering pools! I don't know the technicalities of how it works on disk, but my feeling is that the last successful mount point should be saved, and the last few uberblocks should also be available, so barring complete hardware failure, some kind of pool should be available for mounting. Also, if a drive is removed while writes are pending, some kind of error or warning is needed, either in the console, or the GUI. It should be possible to prompt the user to re-insert the device so that the remaining writes can be completed. Recovering the pool in that situation should be easy - you can keep the location of the uberblock you're using in memory, and just re-write everything. Of course, that does assume that devices are being truthful when they say that data has been committed, but a little data loss from badly designed hardware is I feel acceptable, so long as ZFS can have a go at recovering corrupted pools when it does happen, instead of giving up completely like it does now. Yes, these problems happen more often with consumer level hardware, but recovery tools like this are going to be very much appreciated by anybody who encounters problems like this on a server! -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
