On Thu, Sep 23, 2010 at 06:58:29AM +0000, Markus Kovero wrote: > > What is an example of where a checksummed outside pool would not be able > > to protect a non-checksummed inside pool? Would an intermittent > > RAM/motherboard/CPU failure that only corrupted the inner pool's block > > before it was passed to the outer pool (and did not corrupt the outer > > pool's block) be a valid example? > > > If checksums are desirable in this scenario, then redundancy would also > > be needed to recover from checksum failures. > > That is excellent point also, what is the point for checksumming if > you cannot recover from it? At this kind of configuration one would > benefit performance-wise not having to calculate checksums again.
The benefit of checksumming in the "inner tunnel", as it were (the inner pool), is to provide one more layer of protection relative to iSCSI. But without redundancy in the inner pool you cannot recover from failures, as you point out. And you must have checksumming in the outer pool, so that it can be scrubbed. It's tempting to say that the inner pool should not checksum at all, and that iSCSI and IPsec should be configured correctly to provide sufficient protection to the inner pool. Another possibility is to have a remote ZFS protocol of sorts, but then you begin to wonder if something like Lustre (married to ZFS) isn't better. > Checksums in outer pools effectively protect from disk issues, if > hardware fails so data is corrupted isn't outer pools redundancy going > to handle it for inner pool also. Yes. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
