2009-09-20 05:47 AM
Today there are at least three mechanisms to ensure volume is defragmented. I would appreciate discussion about relative merits and applicability of each. If somebody could share real life experience, it is really appreciated.
This is not about snapshots impact on defragtmentation because it is the same for all three methods.
1. reallocate (-p).
2. vol options extent (space_optimized)
There is not much information what it actually does and how it is implemented. From available information I believe extent is implemented by reallocating (if neccessary) on write as opposed to read_realloc, which reallocates on read. Could somebody confirm it; and if I'm wrong, sched light on what extent options actually does? Assuming it does what I believe ...
3. vol options read_realloc (space_optimized)
Comments? Anyone using extent or read_realloc in production? Could you estimate overhead of these options?
2009-09-27 01:29 PM
We use read_reallocate on a few of our database volumes, and we really haven't seen any kind of performance hit to speak of. It was my understanding this was implemented as a work-around to the sequential read after random write issue that is present on the NetApp's due to how WAFL works. It's a nice engineering fix to an issue that I think plagued really a very small percentage of customers. I would love someone from NetApp though to break down all the options listed above in detail though.
2009-09-27 01:52 PM
I guess I should note that read_realloc only optimizes the data after non-contiguous blocks are read once. As for vol options extent, from NetApp's documentation: "You enable logical extents for volumes that contain Microsoft Exchange data only."