Thank you, Tom.
As you can see from the output below, I’m currently only at about 6% used capacity, but I still have about 9% fragmentation.
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
share 65.5T 4.20T 61.3T - - 9% 6% 1.00x ONLINE /mnt
It’s coming down a bit as I am currently in the process of evacuating the data off from the system as the data is being migrated over to my Proxmox server, and the TrueNAS system is being decommissioned entirely.
My concern is going to be that as new data is written, that it is going to result in greater and greater levels of fragmentation with the copy-on-write nature of ZFS, as data is changing over time.
The system will eventually be hosting 32 drive spindles (mechanically rotating hard drives), and the second part of the concern is that as the fragementation increases, that it will mean that the system will have to quote/unquote “look harder” (across the spindles) to locate the fragmented pieces of data, as a result of the copy-on-write nature of ZFS, which will eventually degrade ZFS performance.
It is my understanding that for SSDs, fragmentation may be less of an issue (unless you exceed the modern version of the “file allocation table” where it stores the “map” of where the data is mapped onto the actual logical and/or physical block address of the NAND flash cells for the data being written and/or requested/read), so if you have high(er) levels of fragmentation with SSDs, but because seek times on SSDs are significantly faster than the seek times of HDDs, high(er) fragmentation on SSDs is not as big of a deal, but for HDDs - it can become (over time) a bigger and bigger deal.
And from googling this topic, it would appear that most common recommendation is to offload the data so that you can write it back to the ZFS pool in a more sequential manner, in order to “defrag” the ZFS pool.
But for a > 100TB ZFS pool, that’s just not (always) possible.
Thank you.