This PR has a large blast radius because it takes the final step and bumps up the Controller to be fully async.
We have historically done a piece-by-piece update, so all operations were already async but the controller interface was kept synchronous.
With this update, the controller is now fully async and all tests are updated.
Most places where the new C# compiler warns about function names not ending in `Async` were also adressed, giving a massive refactor change.
Functionally, no changes are done.
This adds an extra clause when building a synthetic filelist to avoid cases where the synthetic filelist fails to be generated because some entries are orphans.
The tests that reproduce this are quite slow and require some tampering with the database to get into the faulty state, so the tests will not run in CI testing but can manually be executed.
When queries are slow on end-user machines it is hard to debug what the exact problem is.
The typical flow is to discover a "stuck" process. But since profiling logging was not enabled there is no output.
The user then has to re-run the problematic operation with profiling on, and locate the last output where the call gets stuck.
This PR introducces a monitor mechanism where all queries register themselves prior to execution, and then de-register once done.
At a fixed interval, the list of active queries is examined, and if a query is found to be running longer than the threshold, it will be logged as a warning.
This means the user can simply go view the live log for warnings, and the offending query will be emitted.
The default threshold is set at a conservative 30 minutes. Since the timer only checks at the interval, it can take at most 2x the interval before a message is logged. After this, a message is logged each time the interval is reached (e.g., a new warning is logged every 30 min).
The option `--long-database-query-threshold` can be used to set a different threshold.
This PR adds a test that generates a synthentic filelist of a variable size, and then measures the time it takes to recreate the fileset.
As there was a reported slowdown, analysis indicated that the query would grow in the order of O=N^2, where N is the number of paths.
The code is then updated to instead use some temporary on-disk space to lay out the paths and then insert them as a new fileset. This should bring the time down to O=N.
Based on a test with 10k files, the query speed up is ~900x, but will be more on larger filesets.
This PR adds guards to prevent creating filesets with multiple files that have the same path.
While it should technically be impossible to have multiple entries that have the same path, it could happend either due to glitches or because the source data (manual lists, remote sources, etc) returns duplicates.
This PR adds a simple check for each folder to ensure that on a folder-level, duplicate paths cannot be introduced.
There is also a post-backup check to evict any duplicates, and the recreate process will reject duplicate paths.
Finally, the repair command will remove duplicates if they somehow manage to get into the database anyway.
A database-level prevention is not currently feasible as it needs a cross-table check for uniqueness, which requires more work from the database to check for each added file. Since this is expected to be a very rare event, the added processing was not justified.
This adds an extra option to allow setting the SQLite page cache size as a regular option.
Prior to this commit it was only possible to set the SQLite page cache size via environment variables.
The option to use environment variables is preserved, and as options from the environment variable are applied after the new setting, environment variables take precedence.
The default value for the new option is to use 1% of the system memory for the page cache. For the restore process, a connection per worker may be made which defaults to half the number of cores, so the maximum amount of memory is 1% * half the CPU cores.
This is just the upper limit, and SQLite may choose not to use all of it.
This fixes#6178
Kenneth Skovhede