Well, I know there is a “Tips and Tricks” badge for these kinds of things. I was wondering, if some of the things I do with syncthing (successfully, I might say) are considered “dangerous” or “bad practice” and would like to hear opinions.
DON’T use this as a howto (yet), as I am not sure these are a good idea.
1.) Adding .stversions as (unshared) repo
Useful for: Slow bandwidth connections
Not recommended for: Machines low on RAM
This I did on some machines because while restructuring my Picture-library (renaming huge folders) syncthing occasionally deleted the folders instead of renaming them. Since the machine in question was behind a low bandwidth connection, I made use of syncthing’s ability to share data block between repos. This way I managed to get the files back much faster.
The good:
- I won’t need to transfer the files again if syncthing messed up
- I won’t need to transfer the files again if I messed up
The bad:
- The amount of RAM might increase drastically, depending on the size of changed files and the time to keep these files.
- (?)
2.) Symlinking the database folder… (…and share it in an Multiboot Environment)
Useful for: Multiboot Environments, Machines with a small dedicated System-Partition
Not recommended for: “default” Setup, with “Sync”-folder at ~/Sync
So, I keep my Linux installation on a fairly small partition (say 30 GB), while Windows lives on about 4 times the size (and still isn’t happy), the Rest of my hard drive is a dedicated “Data” partition. Syncthing’s database sometimes grows without measure, eats up all my space on my small system drive (regardless of the OS) (20+ GB) and lets syncthing stop when the drive is full. Also, I have the database twice (Few GB) on my system with essentially the same data. So now I share the database on my “Data” partition, which is much larger anyways.
The good:
- Saves space (and CPU-time) by not duplicating the database
- Actually helps Syncthing to do its job in certain scenarios
- Keeps your .config folder free of a multi-GB Database
- One is free to choose the location of the database
The bad:
- One must be careful to have “identical” setups on both OSs (Syncthing does not ensure this but will delete any “superfluos” data in the database)
- Careful: Repos actually have to be the same actual folder (e.g. not each at ~/Sync)
- Can be tricky to set up
- (?)
@AudriusButkevicius: I got this tip from you, but in a recent post you were somewhat critical about the idea yourself (?)
3.) Sharing the certificate on multiboot machines
Useful for: Multiboot Environments
Certainly not for: Virtual Machines, your complete device-zoo sharing the same certificate
Somewhat obvious and related - since the OSs cannot run simultanously and probably have the same repos.
The good:
- You won’t have several nodes which correspond to the same machine in your cluster
- With introducer feature on- you won’t have a node in your config that corresponds to this very same machine
The bad:
- (?)
I’d like to hear some qualified opinion on this, so it might end up in a “Tips and tricks” area of the docs, alongside with “ssh-tunneling to syncthing” and the somewhat misplaced “Reverse Proxy Setup”
Maybe somebody else has a secret trick he or she’d like to share?
