2012-08-01 17:35, opensolarisisdeadlongliveopensolaris пишет:
Personally, I've never been supportive of the whole "copies" idea. If you need more than one redundant copy of some data, that's why you have pool redundancy. You're just hurting performance by using "copies." And protecting against failure conditions that are otherwise nearly nonexistent... And just as easily solved (without performance penalty) via pool redundancy.
Well, there is at least a couple of failure scenarios where copies>1 are good: 1) A single-disk pool, as in a laptop. Noise on the bus, media degradation, or any other reason to misread or miswrite a block can result in a failed pool. One of my older test boxes has an untrustworthy 80Gb HDD for its rpool, and the system did crash into an unbootable image with just half-a-dozen of CKSUM errors. Remaking the rpool with copies=2 enforced from the start and rsyncing the rootfs files back into the new pool - and this thing works well since then, despite finding several errors upon each weekly scrub. 2) The data pool on the same box experienced some errors where raidz2 failed to recreate a userdata block, thus invalidating a file despite having a 2-disk redundancy. There was some discussion of that on the list, and my ultimate guess is that the six disks' heads were over similar locations of the same file - i.e. during scrub - and a power surge or some similar event caused them to scramble portions of the disk pertaining to the same ZFS block. At least, this could have induced many enough errors to make raidz2 protection irrelevant. If the pool had copies=2, there would be another replica of the same block that would have been not corrupted by such assumed failure mechanism - because the disk heads were elsewhere. Hmmm... now I wonder if ZFS checksum validation can try permutations of should-be-identical sectors from different copies of a block - in case both copies have received some non-overlapping errors, and together contain enough data to reconstruct a ZFS block (and rewrite both its copies now). //Jim _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
