There is something in the syncthing that preventing my hard drive from sleeping peacefully. How to debug it?
I put my syncthing folders in a ZFS raidz1, the main ubuntu system is in a usb drive so if it’s log, it should be writing to usb drive. I narrow down the culprit of the disk-waker to be syncthing using iotop and btrace. But still dont know if i do any wrong config here
Any guide on how to find the culprit? i’m on syncthing 1.23.1 in ubuntu server 22.04.1
Syncthing will periodically (hourly by default I think?) walk the filesystem, regardless of the fact that file watches are used.
All those periodic scan already set to 24 hours, any other poasible cause?
I believe I may have the same problem. I’m running Syncthing v1.20.4 Build 2022-08-20 as a service in my XigmaNAS server. Syncthing seems to be doing something with my disk drives about once every 3-5 seconds. This happens even when I disconnect the server from the Internet. The only way I can stop it is to disable the Syncthing service in my NAS. I haven’t changed any of the Syncthing settings under “Advanced”. Is there anything I can do to at least reduce the frequency of it accessing the drives?
Thanks! Dan
One option is to turn off “Watch for Changes” on all of the Syncthing folders and also adjust the “Full Rescan Interval” as needed (default is 3,600 seconds).
Thanks for the prompt response. The NAS has four drives, all configured as mirrors of each other (probably a bit of overkill on my part). The OS used by XigmaNAS is FreeBSD and the filesystem is ZFS. I’m not really sure where Syncthing’s database is stored - XigmaNAS doesn’t present that information in its user interface. However, I think it’s in the ZFS mirror array at /mnt/Large/Syncthing as shown in this upload:
All of the folders have the “Watch for Changes” already disabled since modifications of the sync’d files and folders are never initiated at the server - just at the clients.
The “Full Rescan Interval” on all the folders was set at 60 seconds. I’ve just changed that to 3600 seconds (1 hour) and restarted Syncthing. That increased the time between disk accesses to probably once every 15-20 seconds. Syncthing is configured six remote clients that sync a total of 13 folders, and most of these have a LOT of subfolders. Is the rescan interval of each Syncthing folder affacted by the number of subfolders and files it contains?
Thanks! Dan
One question: Changing the “Full Rescan Interval” on the folders seems to have made a significant improvement. But since changes to files and folders are never initiated at my server, and only at the clients, just like I disabled “Watch for Changes” on all of the folders, why not do the same with “Full Rescan Interval”? If I were to set the interval to 0, would that turn it off? Or would making the folders “Receive Only” turn it off?
Dan
I don’t think there is anything to switch it off completely.
Even if you don’t make changes, we still need to check in case something makes changes, because otherwise we might end up with data loss in case something has changed, and we’re not aware of it, when we need to modify the file. Or even in the case of being able to provide a revert button, we need to know that something has changed.
I believe zero will just set it to some default.
Without knowing anything about the choices that were made during the XigmaNAS installation, and going by the limited info available…
Based on your screenshot, and the fact that you said that /mnt/Large is your ZFS mirror – or in ZFS-lingo, a “zpool” – your Syncthing database (the index-v0.14.0.db subfolder) is definitely helping to keep your drives awake.
Besides tracking file and folder changes, Syncthing also logs regular status updates for every Syncthing peer it’s connected to.
Technically, Syncthing’s configuration directory is probably only on a single drive, but your 4-way mirror keeps the other 3 drives equally busy.
ZFS doesn’t play well with RAID controllers, so you’re most likely using ZFS’ software RAID-like equivalents. ZFS has additional internal housekeeping tasks that makes putting drives to sleep tricky – if a drive takes too long to spin up and respond, ZFS will consider the drive to be offline and drop it from the zpool.
One possible solution depends on the expansion options available for your NAS (you didn’t mention anything else about the hardware):
Keeping the OS and Syncthing off the storage array has several advantages including:
No, the “Full Rescan Interval” is only the specified number of seconds plus some randomness. Per the Syncthing documentation:
Scanning
To make sure that not all folders are rescanned at the same time, the actual scan interval is a random time between 3/4 and 5/4 of the given scan interval.
So setting the full rescan interval to 3600 seconds for a Syncthing folder means a full rescan could occur every 45 to 75 minutes.
Extrapolate that for 13 Syncthing folders plus the time required to scan a lot of subfolders and/or files, and there could very well be overlapping scans.
Setting the folder type to “Receive Only” is a good safety measure if you don’t want any changes propagating from your NAS to your six remote clients, but it has negligible effect on disk activity.
I’m not aware of an option to disable both the watcher and full scans. If you’re absolutely certain that any local changes on the NAS can be ignored, then set “Full Rescan Interval” to something like 86400 (1 day), or even 31536000 (1 year). It all but guarantees that changes from the six remote clients will take precedence over the contents of the NAS.
It’ll remove another disk activity, but there’s still the catch-22 of your Syncthing configuration being on the very storage array you’re trying to minimize frequent I/O activity on.
Thanks again! That explains a lot.
I discovered that I misunderstood the XigmaNAS UI for Syncthing installation! The one folder it lets me specify is for the location of the Syncthing database. As for the sync’d folders, I can (of course) independently configure them in Syncthing.
So I’d like to move my Syncthing database. Is it sufficient to:
What about the other files: *.pem, *.log, and *.txt?
Thanks again,
Dan
You’re welcome. 
I don’t know how XigmaNAS’ UI alters Syncthing’s settings, but I assume it’s using one of Syncthing’s options for specifying the location of its database. If so, then yes, the steps above are fine.
The other files above the database directory seldom change, especially the *.pem files (unless you decide to reset the SSL certificate, encryption key, etc.). config.xml only changes when you change settings in Syncthing.
Great! I’ll make that change tomorrow!
Best,
Dan
Just make sure to first make a backup of the Syncthing config folder. Especially the *.pem files and the config. Database can be regenerated usually, but you might get conflicts if other peers change files in between.
As for finding the actually used paths, have a look at the dialog under Actions > About, it lists all relevant filesystem locations.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
