If you live in on the west coast (USA), you may have seen an ad campaign about happy cows coming from California. Given we're a CA-based software company we concur.
OK wait a minute. Why are we talking about cows? What does this have to do with defrag? Maybe you're thinking "Michael's talking bovine, he's had a few too many".
Well maybe yes, but... I do have a point.
CoW, or "copy on write" refers to a low level technology that looks at block data changes and then takes a particular action. Every time there is a write, a CoW technology would seek to make a copy of just the changes - not the entire new file. That action may be part of inline data dedupe, may be a snapshot, etc. The basic point is that CoW is used to isolate changes to data at a granular level rather than at a file level.
The consideration is that most CoW technologies are unable to distinguish between changes to data or movement of pieces of data, due to a defragmentation job. In other words, if you run a defrag, CoW may think there are actual data changes to files, and then take action to make block-change copies, run a dedupe, etc...
Holy CoW you say!
So, it is possible that a defrag, any kind of defrag, causes a CoW based technology to go into hyperactive mode. That may mean a CDP (continuous data protection)/snapshot program may be triggered in to keeping/taking far more copies that it needs to. It is basically fooled into thinking that a defrag represents actual changes to data, and that they need to process those changes. Now this is a false processing but, because most CoW solutions function underneath the file system layer, they simply cannot differentiate that actions that take place at the file system are not changes to data, but rather data-movement-for-optimization reasons.
So, if we're talking about a CoW solution that takes snapshots, we could see an increase in the amount of copies that a snapshot solution would have to take. That would make for a fairly fat CoW (a lot of extra data storage demands created by not understanding defrag).
CoW based solutions that work at the file system level (NTFS), have the possibility to recognize changes due to defrag and differentiate them from changes due to new actual data to a file. One such CoW solution is Microsft's VSS (Volume Shadow Copy Service). However, as noted, most CoW technologies operate at storage layers that are abstracted from the local disk file system - they operate at levels underneath the file system. Again, that means defrag jobs in the file system will not be recognized by these solutions, and a defrag job of any kind, will cause unnecessary copies.
In comes IntelliWrite. Now, it makes sense to think that IntelliWrite was invented as a faster and, perhaps cooler, solution to fragmentation. But, the truth is that solving fragmentation at the source (when it is created) is vital to ensure compatibility with many of the CoW solutions that may be implemented at virtualization host or SAN layer (i.e. underneath and hence, unaware of the file system).
So, in a nutshell, IntelliWrite was very much designed to ensure that defrag offered full compatibility with modern storage technologies. That, we feel, makes for happy CoWs.