tldr: Starting with 6.8.0-rc2 please visit Settings/Disk Settings and change the 'Tunable (scheduler)' to 'none'. Then run with SQLite DB files located on array disk shares and report whether your databases still become corrupted.
When we first started looking into this issue one of the first things I ran across was this monster topic:
https://bugzilla.kernel.org/show_bug.cgi?id=201685
and related patch discussion:
https://patchwork.kernel.org/patch/10712695/
This bug is very very similar to what we're seeing. In addition Unraid 6.6.7 is on the last of the 4.18 kernels (4.18.20). Unraid 6.7 is on 4.19 kernel and of course 6.8 is on 5.3 currently. The SQLite DB Corruption bug also only started happening with 4.19 and so I don't think this is coincidence.
In looking at the 5.3 code the patch above is not in the code; however, I ran across a later commit that reverted that patch and solved the bug a different way:
https://www.spinics.net/lists/linux-block/msg34445.html
That set of changes is in 5.3 code.
I'm thinking perhaps their "fix" is not properly handling some I/O pattern that SQLite via md/unraid is generating.
Before I go off and revert the kernel to 4.18.20, please test if setting the scheduler to 'none' makes any difference in whether databases become corrupted.
-
1
-
3
