Andrew and Eric are correct, read_realloc is trumped by deduplication when it comes to VMs. I was asking these questions of the development team two weeks ago after reading about read_realloc in the ONTAP documentation. I'm still trying to find use cases/examples because it sounds like a neat volume option. The best advice I've been given is to enable it on non-deduplicated NAS volumes on SATA disks where file fragmentation can cause the most noticeable latency.
Thanks for the confirmation. Next question then is....if using deduplication (I primarily use it inside volumes that host NFS datastores to VMware so just returning the used space to the volume is quite sufficient), can I instead use a scheduled reallocate with the "-p" option? Any gotchas I should be aware of there?
As best I understand, regular reallocate can increase snapshot space usage (and therefore would diminish deduplication savings as well if I understand the relationship correctly) and the "-p" option can cause speed issues with Single File Restores (which SMVI uses in an NFS scenario).
Very curious if anyone has any thoughts here....I'm about to put up a big post outlining where I am right now with VMware, NFS datastores, deduplication, reallocation to get some feedback.....read_realloc being one of the pieces there.
We are in the middle of deploying ESXi 4 on a set of netapp clusters, 10ge, nfs, ibm blades. So far with just 10-ish vms (mix of windows, linux). we are seeing very good de-dup. Rapid Clone is Sweet. We do not have the time to validate the use of read_realloc vs scheduled reallocate (the command) or a combo of both, so I'm just flipping the bit for read_realloc and hoping for the best right now. I'll do some reallocate measures and see what happens after a month of usage.
We are on the last main part here and that's backups. We have an eval of SMVI. That's some neat stuff too.
Given deduplication is most powerful in VMware environments (and I use it in just about all my VMware environments), I'm thinking that takes read_realloc off the table. What I'm not sure of right now is whether scheduled reallocates (i.e. "reallocate start /vol/volname" and "reallocate schedule -s '22 0 * 6' /vol/volname") are off the tables as well (as I have been doing that on VMware volumes to improve performance....it has noticeably helped in certain environments).