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
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).
zfs-discuss mailing list