Hi Dave, Having read through the whole thread, I think there are several things that could all be adding to your problems. At least some of which are not related to ZFS at all.
You mentioned the ZFS docs not warning you about this, and yet I know the docs explictly tell you that: 1. While a ZFS pool that has no redundancy (Mirroring or Parity,) like your's is missing, can still *detect* errors in the data read from the drive, it can't *repair* those errors. Repairing errors requires that ZFS be performing (at least) the (top-most level of) Mirroring or Parity functions. Since you have no Mirroring or Parity ZFS cannot automatically recover this data. 2. As others have said, a zpool can contain many filesystems. 'zfs umount' only unmounts a single filesystem. Removing a full pool from a machine requires a 'zpool export' no matter what disk technology is being used (USB, SCSI, SATA, FC, etc.) On the new system you would use 'zpool import' to bring the pool into the new system. I'm sure this next on is documented by Sun also though not in the ZFS docs, probably in some other part of the system dealing with removable devices: 3. In addition, according to Casper's message you need to 'off-line' USB (and probasbly other types too) storage in Solaris (Just like in Windows) before pulling the plug. This has nothing to do with ZFS. This will have corrupted (possibly even past the point of repair most other filesystems also. Still, I had an idea on something you might try. I don't know how long it's been since you pulled the drive, or what else you've done since. Which machine is reporting the errors you've shown us? The machine you pulled the drives from? or the machine you moved them too? Were you successful in 'zpool import' the pool into the other machines? This idea might work either way, but if you haven't successfully immported it into another machine there's probably more of a chance. If the output is from the machine you pulled them out of, then basically that machine still thinks the pool is connected to it, and it thinks the one and only disk in the pool is now not responding. In this case the errors you see in the tables are the errors from trying to contact a drive that no longer exists. Have you reconnected the disk to the original machine yet? If not I'd attempt a 'zpool export' now (though that may not work.) and then shut the machine down fully, and connect the disk. Then boot it all up. Depending on what you've tried to do with this disk to fix the problem since it happened I have no idea exactly how the machine will come up. If you couldn't do the 'zpool' export, then the machine will try to mount the FS's in the pool on boot. This may nor may not work. If you were successful in doing the export with the disks disconnected, then it won't try, and you'll need to 'zpool import' them after the machine is booted. Depending on how the import goes, you might still see errors in the 'zpool status' output. If so, I know a 'zpool clear' will clear those errors, and I doubt it can make the situation any worse than it is now. You'd have to give us info about what the machine tells you after this before I can advise you more. But (and the experts can correct me if I'm wrong) this might 'just work(tm)'. My theory here is that the ZFS may have been successful in keeping the state of the (meta)data on the disk consistent after all. The checksum and I/O errors listed may be from ZFS trying to access the non-existent drive after you removed it. Which (in theory) are all bogus errors, and don't really point to errors in the data on the drive. Of course there are many things that all have to be true for this theory to turn out to be true. Depending on what has happened to the machines and the disks since they were originally unplugged from each other, all bets might be off. And then there's the possibility that the my idea never could work at all. People much more expert than I can chime in on that. -Kyle D. Eckert wrote: > Hi, > > after working for 1 month with ZFS on 2 external USB drives I have > experienced, that the all new zfs filesystem is the most unreliable FS I have > ever seen. > > Since working with the zfs, I have lost datas from: > > 1 80 GB external Drive > 1 1 Terrabyte external Drive > > It is a shame, that zfs has no filesystem management tools for repairing e. > g. being able to repair those errors: > > NAME STATE READ WRITE CKSUM > usbhdd1 ONLINE 0 0 8 > c3t0d0s0 ONLINE 0 0 8 > > errors: Permanent errors have been detected in the following files: > > usbhdd1: 0x0 > > > It is indeed very disappointing that moving USB zpools between computers ends > in 90 % with a massive loss of data. > > This is to the not reliable working command zfs umount <poolname>, even if > the output of mount shows you, that the pool is no longer mounted and ist > removed from mntab. > > It works only 1 or 2 times, but removing the device back to the other > machine, the pool won't be either recognized at all or the error mentioned > above occurs. > > Or suddenly you'll find that message inside your messages: "Fault tolerance > of the pool may be compromised." > > However, I just want to state a warning, that ZFS is far from being that what > it is promising, and so far from my sum of experience I can't recommend at > all to use zfs on a professional system. > > Regards, > > Dave. > _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
