I have now tried out syncthing for a couple of days, and must say it works quite good. I am running syncthing on several nodes, one is a NAS that is quite slow and not a lot of memory. That NAS suffered from high cpu usage and high memory usage which in turn made syncs very slow. It turned out the fix was quite easy - increase the rescan interval. However, since the same files also are shared via samba, that made it not very responsive when a file was updated through samba. However after finding the inotify I realized that I now have a solution.
This makes me wonder why the decision has been taken to have inotify as a separate process, and not part of syncthing core. Also it is a part of syncthing-gtk which is confusing since I do not want GTK on a headless server. Should it not make sense to have it included by default in the core instead of the quite expensive scan that currently is default? At least as a configuration option? And also get rid of the REST API calls to make the sync which could instead be a direct call?
Hi and welcome to the forum
Maybe you can find the answer over there:
Check the wexisting ticket on github for reasons (which might not be as valid anymore as they were then). It was basically issues with cross compiling due to how fsnotify works on osx, plus standard kernel limits, which the normal user will not know how to raise.
I have seen and used syncthing-inotify, and it works really perfect. That is why I wanted it included in syncthing, not beeing a separate thing I need to find, install and then manage (update etc). Instead I proposed a configuration option (for backwards compatibility) to have inotify enabled for my folder. I really think the scan is a not very good solution, due to resource need and timing. I really do not care as an end-user if this is realized as a separate process or built in to the existing process. What I do care about is ease of use which in turn effects my perception of the solution.
@AudriusButkevicius: I do not understand which issue you are refering to, but issues with cross-compiling is probably solvable. If by kernel limits you are refering to the need of raising fs.inotify.max_user_watches I think the problem is solvable by documentation, as it is (or should be) in the syncthing-inotify project. I do understand that some platforms, now or in the future, maybe cannot support this, that is why you should keep the fallback.
Why I am proposing this is very much related to the third item on syncthing.net; “Easy to Use”. It would have been much easier for me in the case above if I did not have to search forums and the network to find the companion to syncthing, syncthing-inotify, that I really needed. It would have been easier, and I probasbly would have found it fast, if it was just a configuration switch and mentioned in the documentation (which by the way is really, really good!).
This feature request is really about ease of use for the end user. Apart from that it’s also about performance. In my scenario I see a tremendous performance gain, since the NAS has scarce resources.
It is also about separation of concerns. Should really a gui (syncthing-gtk) have features that effects how syncing is done?