Recap and result(as promised) about the deswizzler scanner
I wrote:
The da** thing walks inodes, and in all snapshots dirs as well *sigh*. It can also easily swamp the disks because it reads data fairly inefficiently. [...]
I'll try and find out if a reallocate -A has an effect on what the deswizzler needs to do, and share my findings here later (after summer).
1. There is no connection between reallocate -A and what the deswizzler is doing. I'd recommend turning off deswizzler before doing reallocate -A, just to save some IOPS. The disks are hammered very hard by reallocate -A, and W latency will shoot up. A lot.
2. The deswizzler scanner will do, in the bg, what a certain WAFL message also does. But it does it on-demand when data is read. Meaning that the 1st time a block is read, it will be "fixed" if there's an extra pointer there.
In a HFC (high file count) environment it's pointless to have deswizzler on. It won't do anything that is fruitful for the performance, rather on the contrary. Expecially with the bigger FAS models (80x0) my recommendation is to always set
options wafl.deswizzle.enable off
for good.
/M