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.
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 copy on write 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 copy on write is used to isolate changes to data at a granular level rather than at a file level.
The consideration is that most copy on write 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, copy on write may think there are actual data changes to files, and then take action to make block-change copies, run a dedupe, etc...
Holy copy on write you say!
So, it is possible that a defrag, any kind of defrag, causes a copy on write 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 copy on write 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 copy on write 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 copy on write (a lot of extra data storage demands created by not understanding defrag).
Copy on write 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 copy on write solution is Microsft's VSS (Volume Shadow Copy Service). However, as noted, most copy on write 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 copy on write 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 copy on writes.