wackz is similar to wack, but it works on zombie files as well as the regular files (or should I say inodes). You might ask what is a zombie file/inode - great question, I can try and say that it is a file that was semi erased from the system - something marked as a "bad block". I expect NA to come up with a more sophisticated answer.
E.g.:
All the file system updates for a delete must be written out in a single consistency point[1], so that the entire delete takes place atomically.
This means that whatever CP (consistency point) will write out those changes cannot complete until the delete finishes.
A CP is what pushes file system changes to disk; until a CP completes, the NVRAM cannot be purged of entries for file system operations that made those changes, as, if the CP doesn't complete before a system reboot (so that none of the file system changes are visible in the file system), all of those operations must be replayed on the reboot.
A delete of a very large file can take quite a while; this means that a CP that would write out the file system changes for said delete can take quite a while, which means it could take quite a while to purge file system operations from the NVRAM.
If the NVRAM is full, this means it could take a while before the system is able to perform any file system operations that get logged to NVRAM - which includes just about every file system operation (including reads - they get logged so that file access time updates don't get lost, at least if you haven't disabled access time updating).
Therefore, a large delete can keep a filer from getting any work done for a while, if the NVRAM backs up.
To fix this, we introduced a mechanism that allows a partially-completed delete to be written out in a CP; the "half-dead" file is a "zombie", and an invisible metadata file keeps track of "zombie" files, which will be deleted if there are any such files detected when the system reboots.
[1] For a brief description of the way "consistency points" work, see
http://www.netapp.com/tech_library/3001.html#I43
which links to part of the WAFL section of the "An NFS File Server Appliance" paper by Dave Hitz in our technical library; the technical library is linked to by the teeny "Tech" link next to "Contact Us" at the bottom of our home page. I guess the idea was not to do technical stuff in public, as it'd frighten the horses^H^H^H^H^H^HPointy-Haired Bosses who probably sign the purchase orders for all the big E-word systems we're selling....