On Wed, 5 Jan 2011, Edward Ned Harvey wrote:
You are asking a very intelligent question though. At first blush, it would appear to be possible for the client to detect a checksum error, and then due to lack of redundancy, be unable to correct it. Fortunately that's not possible (see below) but if it were, you would have to scrub at the server and then scrub or clear at the client. But that's precisely why it's an impossible situation. In order for the client to see a checksum error, it must have read some corrupt data from the pool storage, but the server will never allow that to happen. So the short answer is No. You don't need to add the redundancy at the client, unless you want the client to continue working (without pause) in the event the server is unavailable.
I don't agree with the above. It is quite possible for the server or network to cause an error. Computers are not error free. Network checksum algorithms are not perfect. ECC memory is not perfect. OS kernel's and CPUs are not perfect. The probability of data error goes down quite a lot due to zfs on the server, but the probability is not zero. If zfs on the server detects an error in its data, then it won't allow the client to read that known bad data. This does not help the client produce good data, except for via backups, or a LUN on a redundant pool.
However, it should also be said that the client is also not error free and at some point the return diminishes enough that improving server reliability does not help much client reliability.
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
