I happen to have a number of raspberry pis lying around. I set syncthing up on one to see how it would perform. It is quite slow, but otherwise it is working great. I tried to set up multiple raspberry pis so they would sync different changed files from my PCS. They could then finish syncing between themselves at their leisure. One was set to sync large files first, one to sync small files first and another syncing at random. I had the idea to have them all sync to the same share network directory as on the pi it is the processing overhead for the encryption that seems to limit the speed. If I could sync to the same directory I could speed up the process by adding more RPis. The setup at first seemed to work fine, but causes problems when they try and sync the same file. Seeing then to sync in a different order helped a lot, but it still causes an error with the last file. Any suggestions for preventing this error? I know another system would be faster, but I happen to have a number of RPis spare and would like to figure this out.
It basically comes down to multiple instances should not sync the same share at once. ST is not designed for this to work and it will cause unexpected behaviour. It was mentioned recently I will see if I can find the thread.
Edit: Here it is.
One way of doing it without breaking would be sharding the files to be synced using ignores.
The .stignore file will be shared between both devices as well. So you will need to make the .stignore a symlink to ~/stignore (or something else) on both RPis. One ~/stignore ignores all the files that start with [a-m] case insensitive, the other one ignores [n-z] case insensitive.
That obviously won’t work if you have files that start with numbers or other characters. You can make the latter “only sync” [a-m] case insensitive, and there you have it. Then as you add more RPis, adjust the ignores accordingly.
I haven’t tried having a symlink .stignore so I don’t know how it will behave but I assume it will be fine as that file is only read, and not written at all as long as you don’t edit in the Syncthing GUI. (thanks @Alex for correcting me!)
You can edit the file in the syncthing gui, but when you don’t, syncthing does not write to it. Otherwise nice idea, could work in theory 
The ignore file is stored in the directory… You can’t have different instances use the same file and ignore different things.
Edit: Or were you suggesting creating multiple users and soft linking to an ignore file in their home directories?
Hi all, Thanks for the responses. I appreciate the input. I am not sure how I would go about setting up .stignore in a way that would work in a shared directory.
Is there any way to control the response to the error? If I could set one to retry quickly and 1 to retry after a few minutes then the problem would be solved. The “Master” Pi would fully resync the remaining block of the file while the other was waiting to retry.
Yes, I was suggesting soft linking to an ignore file in some directory, obviously home directory is a good choice. It doesn’t matter which directory it is, and which user it is as the Syncthing instances are running on separate devices.
@brotherkennyh I haven’t tried it so it may not work, or it may cause corrupted or lost files etc. I suggest you try it with a dummy folder. Here is how you would set it up:
On device A:
Create an stsharedignore file in ~ (home directory) of the user running Syncthing with the following content:
!(?i)[a-m]
On device B:
Create an stsharedignore file in ~ (home directory) of the user running Syncthing with the following content:
(?i)[a-m]
On terminal of both of the devices:
ln -s ~/stsharedignore [shared-sync-directory]/.stignore
If you have 3 devices you can set up their stsharedignore as:
!(?i)[a-i]
!(?i)[j-r]
(?i)[a-r]
thanks for the replys. I will give this a try when I get enough time to experiment.
In you example with 3 Pis with the line “(?i)[a-r]”. Am I correct in saying this also sync files starting with numbers or other characters?
Yes, this is ignoring anything starting with the characters a through r (not case sensitive). So numbers and other characters will be synced.
There is a negative side effect of this, each of the nodes will only index their own section of files and only be aware of some of the available blocks.
If you take @kbtombul’s example of 3 nodes with the following ignores:
NodeA: !(?i)[a-i]
NodeB: !(?i)[j-r]
NodeC: (?i)[a-r]
Then add a remote node “NodeX”.
On NodeX a file is created "AFile.img" The file is synced to NodeA On NodeX the file is Renamed to "MyFile.img" NodeA deletes "AFile.img" The file is be synced to NodeB requiring all of the blocks to be transferred again.
How much of an issue this is depends on how large your files are, if you are using relays and connection speeds but it is worth considering if you only tend to synchronise a few files at a time.
Also, in the example above, if Nodes A-C are set to use versioning you could add the .stversions folder to each of the Syncthing instances as unshared folders. That way they will be indexed and the blocks from the deleted file will be reused by NodeB to create “MyFile.img”. Unfortunately this still doesn’t help if “MyFile.img” is a copy of “AFile.img” and would cause extra space to be used when it could have been a simple rename.