James, on a UFS ore reiserfs such errors could be corrected.
It is grossly negligent to develop a file system without proper repairing tools. More and more becomes clear, that it just was a marketing slogan by Sun to state, that ZFS does not use any repairing tools due to healing itself. In this particular case we are talking about a a loss of at least 35 GB (!!!!) of data. And as long as the ZFS Developer are more focused on proven wrong marketing aspects I can't recommend ZFS at all in a professional area and I am thinking about to make this issue clear on the Sun Conference we have in Germany in March this year. It is not a good practice just to make someone believe who just lost that mass of data "I am sorry, but I can't help you." Even in the fact, if you don't understand why it happened. A good practice would be to care first for a proper documentation. There's nothing stated in the man pages, if USB zpools are used, that the zfs mount/unmount is NOT recommended and zpool export should be used instead. Having facilities to override checksumming to get even an as corrupted tagged pool mounted to rescue the data shouldn't be just a dream. it should be a MUST TO HAVE. I agree, it is always - regardless the used FSType - to have a proper backup facility in place. But based on the issues ZFS was designed for - for very big pools - it becomes as well a cost aspect. And as well it would be a good practice by Sun due to having internet boards full of complaining people loosing data just because of using zfs, to CARE FOR THAT. Regards, DE -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
