I'm not aware of a detailed discussion, however this is what we've experienced with it.
We don't know *exactly* what it does, but as a generalization, it tries to catch filesystem parity inconsistencies before they crash your filer and force you to wack it. When it finds an inconsistency, it will log a message to /etc/messages and also put some extended information in /etc/parity_inconsistencies for NetApp Tech Support. It is a vol option and therefore persistent through reboots until turned off. As far as we know, it examines the checksum for each block as it reads or writes it to disk - can anyone confirm or deny this?
Once you turn it on, it is a continuous process that will take an additional 1-5% of the filer's CPU. On an F630 or F760, this seems to be negligeable; however, on an F540, we found that backups just about pegged the CPU at 100%.
Nevertheless, we have this option turned *on* for all our filers except the F540.
-- Jeff
-- ---------------------------------------------------------------------------- Jeff Krueger E-Mail: jeff@qualcomm.com NetApp File Server Lead Phone: 858-651-6709 IT Engineering and Support Fax: 858-651-6627 QUALCOMM, Incorporated Web: www.qualcomm.com
From Jim Davis on Tue, 11 Jan 2000 10:21:00 MST:
Poking about now.netapp.com didn't turn up a lot of details about just what this does -- or what sort of potential performance hit there might be when it's turned on. Is there a detailed discussion about this somewhere, or could someone in the know comment on it? Thanks!