This is continuation of this original issue report.
There is some conflicting information in that topic and, therefore, with your help, we want to try and get to the bottom of this. We have several test servers running trying to reproduce this problem, so far hasn't happened.
The first thing we want to definitively establish is whether the problem is isolated to only those cases where /config inside the container is mapped to:
/mnt/user/appdata
vs.
/mnt/cache/appdata
or
/mnt/diskN/appdata
Note: it does not matter what the "Default appdata storage location" is set to on Settings/Docker page. Of interest is the actual path used by an individual container.
What I'd like to ask is this: For those of you who have seen this DB corruption occur after updating from Unraid 6.6.x to 6.7.x, please note the placement of your 'appdata' folder and how it's mapped to your problematic container. Then update to 6.7.2 and run normally until you see corruption. At that point, please capture diagnostics and report how appdata is being mapped. If this is a huge PITA for you, then bow out of this testing - we are not trying to cause big disruptions for you.
Finally I want to make clear: we are not "blaming" this issue on any other component, h/w or s/w, and also not "admitting" this is our problem. We have not changed any code we're responsible for that would account for this, which doesn't mean we don't have a bug somewhere - probably we do, and a change in the kernel or some other component might simply be exposing some long hidden issue. We are only interested in identifying and fixing the problem.
- 4
Recommended Comments
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.