>James, > >on a UFS ore reiserfs such errors could be corrected. That's not true. That depends on the nature of the error.
I've seen quite a few problems on UFS with corrupted file contents; such filesystems always are "clean". Yet the filesystems are corrupted. And no tool can fix those filesystems. >It is grossly negligent to develop a file system without proper repairing >tools. Repairing to what state? One of the reasons why there's a "ufs fsck" is because its disk state is nearly always "corrupted". The log only allows you to repair the metadata, NEVER the data. And I've seen the corrupted files many times. (Specifically, when you upgrade a driver and it's buggy, you would typically have a broken driver_alias, name_to_major, etc. Though I added a few fsyncs in update_drv and ilk and it is better, fsck does not "fix" UFS filesystems. Fsck can only repair known faults; known discrepancies in the meta data. Since ZFS doesn't have such known discrepancies, there's nothing to repair. >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. If it can repair, then it does. But if you only have one copy of the data, then you cannot repair the data missing. >In this particular case we are talking about a a loss of at least 35 GB (!!!!) >of data. >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. You have a live pool and you yank it out of the system? Where does it say that you can do that? >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. Depends on how much of the data is corrupted and which parts they are. >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. I've not seen a lot of people who complained; or perhaps I don't look carefully (I'm not in ZFS development) What I have seen is some issues with weird BIOS issues (taking part of a disk); connecting a zpool to different systems at the same time, including what you may have done by having the zpool "imported" on both systems. Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
