> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss- > boun...@opensolaris.org] On Behalf Of Robert Milkowski > > What if you you are storing lots of VMDKs? > One corrupted block which is shared among hundreds of VMDKs will affect > all of them. > And it might be a block containing meta-data information within vmdk...
Although the probability of hash collision is astronomically infinitesimally small, if it were to happen, the damage could be expansive and unrecoverable. Even backups could not protect you, because the corruption would be replicated undetected into your backups too. Just like other astronomical events (meteors, supernova, etc) which could destroy all your data, all your backups, and kill everyone you know, if these risks are not acceptable to you, you need to take precautions against it. But you have to weigh the odds of damage versus the cost of protection. Admittedly, precautions against nuclear strike are more costly to implement than precaution against hash collision (enabling verification is a trivial task). But that does not mean enabling verification comes without cost. Has anybody measured the cost of enabling or disabling verification? The cost of disabling verification is an infinitesimally small number multiplied by possibly all your data. Basically lim->0 times lim->infinity. This can only be evaluated on a case-by-case basis and there's no use in making any more generalizations in favor or against it. The benefit of disabling verification would presumably be faster performance. Has anybody got any measurements, or even calculations or vague estimates or clueless guesses, to indicate how significant this is? How much is there to gain by disabling verification? _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
