Is that as soon as Syncthing runs or only when the configured folder(s) is(/are) being synchronised? I don’t think that there should be a lot of continues Syncthing-related HDD-activity when the watcher is disabled. Does the task-manager/top show what process makes excessive use of the hard drive?
I’m not sure about specific configuration items to tweak for relatively slow hard drives, as I don’t have any device using those anymore. But there is a configuration-tuning page in the docs which you can read through, to check what makes sense for your use-case;
USB can be a contributing bottleneck depending on the adapter being used (I’m assuming that both HDDs are SATA.
Some additional details that would help a lot:
Make/model of both 2.5" and 3.5" HDDs.
Make/model of the USB enclosures if the two HDDs were purchases as bare drives.
Are both HDDs affected by the slow performance?
Number of files being managed by Syncthing.
Based on what’s known so far, given the drive capacities, one or both of the HDDs might be using SMR (shingled magnetic recording) and not CMR (conventional magnetic recording).
Both HDD are WD hdd with the proprietary enclosures, the 5TB is SMR and is USB, the other has a WD enclosure but internally I imagine it’s a sata drive, the bigger drive performance is a lot higher, I guess being 3.5" and CMR.
WD sometimes modifies their drives, attaching the USB-to-SATA bridge directly to the drive (without a SATA connector) instead to save on costs.
Ah, SMR drives often have similar read performance to comparable CMR drives, but random non-sequential writes is where it becomes I/O bound.
SMR drives are fine for archival storage such as backups, but applications such as Syncthing, Dropbox, rclone, rsync and so on that are updating existing files don’t work as well.
If upgrading to a CMR drive is an option, it’d be the best long-term solution. Otherwise, a few tips when using a SMR drive:
In Linux, set the noatime mount option to reduce the number of random writes (most distros either use the default atime or take a middle approach with relatime).
Use a filesystem with COW (Copy-on-Write) support, or at least one that tries to reduce file fragmentation.
Newer Linux kernels and filesystems such as btrfs (since version 5.12) support optimizations for zoned storage used by SMR and some NVMe drives.