A little back ground. The system in question runs the latest major version of TrueNAS Scale. It has a single RAIDZ2 vdvev of 8x 8TB 7200RPM SAS drives. I access the data via SMB shares from a Windows 11 client.
I was recently copying some video files out of one folder and into another so that I could easily setup a batch in handbrake. Both folders were to local to the NAS. When I did the copy the transfer speeds peaked just under 160Gb/s. Initially when I saw this I assumed that it was actually just creating some kind of link back to the originally file sense the max I would have expected this to actually transfer at is more like 20Gb/s if it was able to read some of the files from the arc cache. However, when I checked how much storage was used up I saw that it had increased by roughly the size of the video files. Which seems to imply that it did in fact copy the files. Given that video data is not compressible I’m struggling to understand how these drives could have possibly hit that kind of performance.

Block-cloning.
See here.
It doesn’t matter how large a file is. The main bottleneck (over SMB) for a copy operation is the number of files (i.e, metadata operations). A single 100-GiB file will copy instantly, even if facilitated via SMB.
The higher the number of files in the copy operation, the slower the process. Unlike with traditional “copying”, the sheer size will have almost no affect on performance if block-cloning is used.
2 Likes
So my confusion then would be how the extra space was used. From a quick read up it would seem that block-cloning would not have used the extra space as it simply references back to the original blocks unless one of them is modified. I did just very quickly read that thread and google how it works though, so I might be off base here.
No extra space was used.
You can verify with this:
sudo zpool list -o name,bclonesaved
The “consumed space” you’re seeing is just how a file/folder is reported by Windows File Explorer (or even when assessing the contents of a local directory on the server itself.)
Such file tools are unaware that “blocks” on a pool that are being “shared” by the same file(s).
3 Likes
I was actually checking the used space from the TrueNAS WebUI, but I do stand corrected. Upon just looking a little closer I noticed that while the “used” space increased by the amount expected for the files, so did the available space. I appreciate the answer and follow-up.
You can also use the above command to assess how much extra space would be consumed if you didn’t use block-cloning. (Think of block-cloning as “on-demand dedup”, without any extra RAM requirements.)
1 Like
Thank you, I did run the command earlier when I found it in the thread you linked. It does confirm that Block Cloning was used.