> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of devsk > > If dedup is ON and the pool develops a corruption in a file, I can > never fix it because when I try to copy the correct file on top of the > corrupt file, > the block hash will match with the existing blocks and only reference > count will be updated. The only way to fix it is to delete all > snapshots (to remove all references) and then delete the file and then > copy the valid file. This is a pretty high cost if it is so (empirical > evidence so far, I don't know internal details).
Um ... If dedup is on, and a file develops corruption, the original has developed corruption too. It was probably corrupt before it was copied. This is what zfs checksumming and mirrors/redundancy are for. If you have ZFS, and redundancy, this won't happen. (Unless you have failing ram/cpu/etc) If you have *any* filesystem without redundancy, and this happens, you should stop trying to re-copy the file, and instead throw away your disk and restore from backup. If you run without redundancy, and without backup, you got what you asked for. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
