First, you need to download and install it into your computer, create a job, select source and destination folders, and choose your automation options. It is quite simple and easy to use the tool. Unlike most of the leading data backup and synchronization systems, GoodSync also offers web access and restoration features that allow you to enjoy its service anytime on the web.
#ARRSYNC SLOW FULL#
The software ensures full data redundancy and ease of recovery while it also provides real-time and automated synchronization that ensures the ability to access, edit and save the document in a fast and secure manner from any location to increase operational efficiency and data security. I actually keep a distribution running on WSL1 primary for this reason - For me, the issue is running a very large s3sync, and the performance on WSL1 is orders of magnitude faster on WSL1.GoodSync is a data backup and synchronization software solution for businesses of all sizes with centralized management and reporting features.
#ARRSYNC SLOW WINDOWS#
You might try using the -whole-file option to disable delta-transfers.īut the best solution (assuming this is your problem) is likely to use WSL1 whenever accessing files on Windows drives, assuming that you can access the VeraCrypt container from it. This goes to the "small file reads/writes" issue from above. When syncing to an existing directory, rsync will automatically use its "delta-transfer algorithm" to send only the changed portions. I have a theory on this that I haven't had a chance to test yet. The problem is much worse for small file reads, in my understanding, although I can't recall having done any benchmarks with large files. I've seen a git clone of a large repo (the WSL2 Linux kernel Github) take 8 minutes on WSL2 on a Windows drive, but only seconds on the root filesystem. See my answer here for more details, but as a comparison from that answer: If that's the case, then realize that WSL2 is notoriously slow when accessing Windows drives specifically. it sounds like the source directory may be a Windows folder (e.g. Īnother Windows tool compared these folders in 0m 50s! Taking a bit of a guess here, but based on this statement. What is slowing down local folder comparison in steps 1 and 2?.Is there anything to improve the performance in my rsync command?.iname xyz runs in 2m 0s, so wsl2 is probably not the culprit. So something must be slowing down reading target file list. If I do dry run from step (1) to a non-existing folder on the same VeraCrypt drive, it runs pretty fast. I also send the same files to a remote Linux machine using: rsync -rtvih -progress -stats -delete -compress -e %SSH% %SRC% -filter 'merge. Sending the files would take at most a couple of seconds. rsync-filter-work' -info=progress2 -no-inc-recursiveĪnother Windows tool compared these folders in 0m 50s! It worked without any filter, so it checked 201k files and 60k folders. rsync-filter-work' -nĪctual run: 13m 16s (while the file list was built in 1m 50s) wsl rsync -rtvih -progress -stats -delete %SRC% '%DEST%' -modify-window=2 -filter 'merge.
There should be 78 files transferred with the size of 40 MB.ĭry run: 11m 45s wsl rsync -rtvih -progress -stats -delete %SRC% '%DEST%' -modify-window=2 -filter 'merge.
Rsync reported a total of 17158 files + 2431 dirs, and total size 2 GB. There is fast CPU and disks, speeds >50 MB/s. I sync files from a SSD disk to an exFAT VeraCrypt container on an HDD (entire HDD is encrypted with VeraCrypt, the encrypted container is formatted in exFAT) on Windows using WSL 2. Something is wrong with rsync speeds in one scenario.
0 kommentar(er)
