Syncthing provides a –reset-database option for purging its database.
Syncthing offers the option to tune how it uses its database, but I suspect that you are asking about doing what is common procedure for relational databases.
For the latter, the storage engine underneath LevelDB is nothing like the ones for PostgreSQL, MySQL, DB2, MS SQL, SQLite, etc.
In a nutshell…
(If you are familiar with managing a Apache Cassandra database, the following concepts are very similar.)
With LevelDB, new changes cached in RAM are written to a log file (files named *.log
found in Syncthing’s index-*.db
directory). Then at a specific threshold, the contents of the log file are flushed to a new SST file (the *.ldb
files).
Once written, no further changes are made to a SST file. If compaction kicks in, the contents of a SST file are written to a new SST file in the process.
One benefit is avoiding file fragmentation. However, if the underlying filesystem is heavily fragmented, so will Syncthing’s *.log
and *.ldb
files due to a lack of contiguous filesystem blocks. There’s nothing that Syncthing can do about it. The choice of storage medium, filesystem and operating system for the database can be very important the more files there are being synced and the more frequently there are changes to the database.