Now the question is: how to know the fragmentation of the data since frag is the fragmentation of the free space?
This one is not really possible to know. But ZFS is designed such that it shouldn't make a difference or be important what the data fragmentation is which is why there is no way to report on it.
The FRAG property was added not too much past a year ago. It's purpose was to create a map of where the free space in ZFS is all located so that the ZFS slab allocator can more quickly and efficiently pick the best metaslab to load to perform the write.
Previously ZFS would always choose the most empty metaslab and would always swiss-cheese it up nearly right away when it wrote new blocks to it. But now with the FRAG property, all the metaslabs keep a record of how fragmented their individual free spaces are.
So now the ZFS slab allocator can instantly know what the write performance of a given slab will be like. If ZFS sees a very heavy write load coming into the system it can choose a high performance metaslab that has very un-fragmented free space. But late at night for instance when the system is under a much lighter write load it can spend more time searching through metaslabs with more fragmented free space to find better fits for the incoming writes. Thus so ZFS can preserve more high performance metaslabs for future heavy write loads.
Basically why "waste" a pristine, high performance metaslab and swiss-cheese it all up when the incoming write load is so small and the system has plenty of time to do more searching? Lets find better fits for the writes when the write load is small and save the pristine metaslabs for when the system is very busy and the system doesn't have time to find better fits.
Overall this improves the write performance in ZFS as the filesystem fills up.
This is the real place where ZFS performance has suffered, as it fills up. But it is not nearly as bad as it used to be.
As far as fragmented data for reads, it hasn't proven to be a real problem in terms of normal data reading performance. Fragmentation is inevitable in a CoW filesystem, but all the technologies built into ZFS (transaction groups, ZIL, ARC) allow it to maintain acceptable read performance throughout. Fragmented data does have an impact on scrub and resilver performance. However this is currently being solved in OpenZFS as someone at Delphix is working on adding sequential scrub and resilver to OpenZFS so that scrubs and resilvers are performed sequentially on the disks no matter the fragmentation of the data at the user level. Oracle already has this feature in their codebase, but we will be getting it ourselves soon.