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

Reply via email to