We use the TrueNAS Scale 24.04.2.2 system
X11SSH-F + E3-1220 v6 + 32Gb ECC
12x 6Tb HDD in pool RAIDZ2, 2x SSD 240Gb OS
as a backup storage for latest Veeam Backup&Replication over NFSv4.1 (4.2 not supported by Veeam), and we are facing the problem of very long merges of backups.
While Windows repositories with ReFS backend and SMB merge copies in 10 minutes, our installation merges copies in 10+ hours (!). The size of one incremental copy is about 1TB.
In Windows/ReFS/SMB installations, Veeam uses the faststone mechanism to merge copies and create a synthetic full copy, this works very quickly, but this does not happen in ours: the merge takes a very long time, and the synthetic copy will take more than a few days
I have reproduced a similar configuration in a virtual environment: Veeam, TrueNAS SCALE 24.10-RC.2 with 6x vdrives of 100 GB each. I made sure that the same problem was present, then switched the connection to SMB. The problem remains.
As a result of searching for the reason, I found out that the FSCTL_DUPLICATE_EXTENTS_TO_FILE
instruction in SMB, as well as the flag of its support in the SMB2 protocol [MS-FSCC (*1)]:
FSINFO/FileFsAttributeInformation
- 0x08000000 FILE_SUPPORTS_BLOCK_REFCOUNTING
This flag is present in Windows/ReFS/SMB and is missing in TrueNAS.
According to the Samba documentation, this instruction is officially supported only in Btrfs, the functionality that is implemented through Samba VFS.
ZFS supports this feature since 2.2.0, which is called reflink
or block cloning
.
I’ve found mentions of slow Veeam+TrueNAS merges (*2)
In the current Release Candidate version of TrueNAS, we do not see any improvements in this regard. Now there is a question of expanding the space and we will not be able to afford such low performance due to the lack of support for functions that work out of the box in Windows for several years now
Are there any developments to implement this functionality in TrueNAS?