• Downgraded back to 6.6.7 due to Sqlite corruption


    limetech
    • Solved Urgent

    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.

    • Upvote 4



    User Feedback

    Recommended Comments



    On 7/5/2019 at 1:25 PM, BRiT said:

    Did you or anyone else set direct io to No?

    It is set to Auto, which is supposed to default to NO. 

    Link to comment

    I'm at the point where Plex can't even make a database backup before it corrupts again. Anyone at Limetech have an update, or even a rabbit hole we can run down to help resolve this issue?

    Link to comment
    11 hours ago, geraldbrent1 said:

    I'm at the point where Plex can't even make a database backup before it corrupts again. Anyone at Limetech have an update, or even a rabbit hole we can run down to help resolve this issue?

    I was able to remedy this by using a cache drive, try it out and see if it works for you! Mine was also corrupting before I could get a daily backup.

    Link to comment
    35 minutes ago, LumberJackGeek said:

    I was able to remedy this by using a cache drive, try it out and see if it works for you! Mine was also corrupting before I could get a daily backup.

    100%, i stuck an old 250GB SSD in mine and moved appdata to cache... no problems since.. previously I was getting corrupted every couple hours.

    Link to comment
    Just now, UNOPARATOR said:

    Any of you having problems with Plex, are you using Plex plugin Plex-Trakt-Scrobbler by any chance?

    No.  I am not.  

    Link to comment
    3 hours ago, spyd4r said:

    100%, i stuck an old 250GB SSD in mine and moved appdata to cache... no problems since.. previously I was getting corrupted every couple hours.

    Would rather have an actual software fix honestly. Just paid for textbooks so I don't exactly have cash for my server addiction. 😂

    Link to comment
    On 7/2/2019 at 6:15 AM, saarg said:

     

    You mean that you moved the docker.img to the USB or just the appdata?

    Just the appdata.  I have the image at /mnt/user/system/docker/docker.img.

    Link to comment

    Hi,

     

    I have my system downgraded to 6.6.7 due to the ongoing database corruption issue in 6.7.x

     

    I  rebuilded the database (6.6.7) in Plex from the scratch and appdata is on /mnt/diskN/appdata from the beginning. Direct I/O is set to off.

     

    I do not have a cache drive.

    Docker Image is on /mnt/diskN/appdata.

     

    As soon I upgrade to 6.7.x I get a database corruption. Is there anything else I can do? Besides waiting for a fix so that I can upgrade. Thank you.

    Edited by hpaar
    Link to comment

    Another day of corruption in the database.  

     

    Should we be doing anything different?  I've posted my diagnostics 2-3 times since this was moved to a bug fix, and I've not heard anything back on any of them.  After being called out for not giving correct information in the original posting...and then asked to do the testing on 6.7.2...there has been no response.  

     

    Here at the diags.  I'm trying to be an active contributor...but its getting tough when there is no feedback.  

     

    Thanksswissarmy-diagnostics-20190710-2354.zip

     

    rm

    • Upvote 1
    Link to comment
    21 hours ago, Rich Minear said:

    Here at the diags.  I'm trying to be an active contributor...but its getting tough when there is no feedback.  

     

    The other thing that makes it hard besides no feedback is that it seems that this issue happens at random. In my case, it could be hours, could be days, maybe even a few weeks. It's hard to grab logs/diags when it happens, cause you never know when it will.

    • Like 1
    Link to comment

    After two more corruptions since Sunday, I finally went back to 6.6.7 today.

     

    I am very disappointed by the lack of transparency from the UNRAID team. I understand finding/fixing the issue might take time, but at least communicate the current progress and next steps. 

    • Upvote 2
    Link to comment

    is it being looked at still?  This is a serious issue. If it was me I’d create a blog entry or wiki with daily status updates. The forum is nice but there’s lots of noise. 

    Link to comment

    If I'm on 6.7.1 with a cache drive and am experiencing no issues, is it advisable to go to 6.7.2? Or should I leave well enough alone given this investigation will probably yield yet another update?

    Link to comment
    15 hours ago, nraygun said:

    If I'm on 6.7.1 with a cache drive and am experiencing no issues, is it advisable to go to 6.7.2? Or should I leave well enough alone given this investigation will probably yield yet another update?

    If you have a cache disk and use /mnt/cache for the appdata, you will have no problem updating. Those that have issues got it from 6.7.

    • Like 1
    Link to comment
    2 hours ago, saarg said:

     

    Use /mnt/cache or /mnt/diskX if you want less/no corruption.

    Good morning.  I haven't had my coffee yet...but I saw that I had a message, and I wanted to respond.  

     

    This reply tells me nothing...other than to give up.  There is no explanation, and no information about the downsides to this.  

     

    I don't have a cache drive.  Anyone that looked at the diagnostics could see that.  Or even looking at my other posts in this same thread...or the thread that actually started this one.  And I'm not the only one...a lot of us do not.  So this answer does nothing for us.  

     

    Second...would someone please explain to us WHY moving to /mnt/diskX makes more sense?  Because to me, it sounds like you are telling us that the database and information for our dockers is not worth being protected.  Is it protected if we move it to a single disk?

     

    I chose Unraid because of it's ease of use.  And the fact that there was a good community around it.  Great howto videos on Youtube.  It has worked FANTASTIC up until now, with ZERO corruption.  But upgrading to 6.7 has started this.  And now that a bunch of us are having this issue, get told by the community here that we are doing it wrong.  Or worse yet...nothing but a one sentence answer that tells us nothing.  

     

    So far, no one has shared ANY information that makes it look like they have looked at the diagnostic information.  Which is fine...if someone has, and it is helping with an update soon, I'm very happy to do it.  If all I'm going to get is a one sentence answer that says "Use a cache drive", then I will stop, and start looking for a new solution.  

    Link to comment
    29 minutes ago, Rich Minear said:

    no information about the downsides to this.

    Basically none.  If anything, you will actually get a performance boost

    29 minutes ago, Rich Minear said:

    explain to us WHY moving to /mnt/diskX makes more sense?

    Because you are bypassing the fuse filesystem that combines shares stored on multiple drives into a unified directory

    29 minutes ago, Rich Minear said:

     Is it protected if we move it to a single disk?

    Yes.  All writes to /mnt/diskX are still protected by the parity system.

     

    29 minutes ago, Rich Minear said:

    get told by the community here that we are doing it wrong.

    Not at all.  We are giving you the work around.

     

    29 minutes ago, Rich Minear said:

    Or worse yet...nothing but a one sentence answer that tells us nothing.  

    Because the work around has been repeated over and over again.  Admittedly there is a user or two who still suffer from corruption for some unknown reason when specifying directly a disk to use.

    Edited by Squid
    Link to comment

    It’s more than a user or two that suffers from corruption on /mnt/diskX. That didn’t work for me.  I had to move to the cache drive which doesn’t have parity.  

    Link to comment
    4 hours ago, saarg said:

     

    Use /mnt/cache or /mnt/diskX if you want less/no corruption.

    What if you're like me and when you change directory from /mnt/user to met/cache Plex gets caught in an infinite crash loop?

    Link to comment

    @ps2sunvalley that happened to me. I had to start from scratch. I lost all my history and manual edits of media metadata. 

    Guys. Find another solution. It appears this company doesn’t care that your data is corrupting judging by their lack of responses. It’s time to move on. 

     

    Link to comment



    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.

    Guest
    Add a comment...

    ×   Pasted as rich text.   Restore formatting

      Only 75 emoji are allowed.

    ×   Your link has been automatically embedded.   Display as a link instead

    ×   Your previous content has been restored.   Clear editor

    ×   You cannot paste images directly. Upload or insert images from URL.


  • Status Definitions

     

    Open = Under consideration.

     

    Solved = The issue has been resolved.

     

    Solved version = The issue has been resolved in the indicated release version.

     

    Closed = Feedback or opinion better posted on our forum for discussion. Also for reports we cannot reproduce or need more information. In this case just add a comment and we will review it again.

     

    Retest = Please retest in latest release.


    Priority Definitions

     

    Minor = Something not working correctly.

     

    Urgent = Server crash, data loss, or other showstopper.

     

    Annoyance = Doesn't affect functionality but should be fixed.

     

    Other = Announcement or other non-issue.