October 30, 20178 yr Hey guys...woke up this morning to a new one My fix common problems plugin told me that call traces were found on my server...looking into the diagnostic log it appears the below section is the relevant part. There's more than this but it appears to just endlessly repeat these same basic issues. Can anyone smarter than me tell me what these mean or what is most likely going on, and if there's anything I can do to fix it? I know I don't have the newest hardware, but I haven't had these issues ever before and Unraid has always been super stable in the past. Thank you!! Edited October 30, 20178 yr by d.ohlin
October 30, 20178 yr Always post the complete diagnostics, the culprit is usually before the trace, in this case likely a corrupt docker image.
October 30, 20178 yr Author @johnnie.black My fault...that was dumb of me that makes total sense now that I think about it. I'm hoping it's not a corrupt docker image in this case as I don't run as docker images on my server but what do I know haha Attached is the full .zip diagnostics file, hopefully that's got everything needed. Let me know if I can do anything else. Thanks! Edited October 30, 20178 yr by d.ohlin
October 30, 20178 yr The trace is related to btrfs but strangely I don't see nothing on the logs about which filesystem is causing the issues, and you may not have dockers but there's a docker image, try running a scrub on all 3 btrfs filesystem in use: docker, libvirt (VMs) and cache.
October 30, 20178 yr Author @johnnie.black Sorry...noob question time How do I do a manual scrub on those 3 filesystems? EDIT: I found the scrub option under the main cache drive (I have 2) and clicked that...still unsure on the docker and libvirt ones though. EDIT2: The cache scrub above completed with the following: scrub status for f36f83a5-045e-43f6-a2a5-74bde4367eaa scrub started at Mon Oct 30 11:11:08 2017 and finished after 00:00:24 total bytes scrubbed: 6.01GiB with 0 errors However, running the above definitely causes the system to produce call traces when I click the "Log" option in the upper right hand corner...and after rebooting and running a cache scrub again it appears I can reliably reproduce the call traces this way I also did a "--readonly" filesystem check on cache which gave the following: checking extents checking free space cache checking fs roots checking csums checking root refs Checking filesystem on /dev/sdf1 UUID: f36f83a5-045e-43f6-a2a5-74bde4367eaa found 69873664 bytes used, no error found total csum bytes: 67260 total tree bytes: 212992 total fs tree bytes: 32768 total extent tree bytes: 16384 btree space waste bytes: 121360 file data blocks allocated: 69660672 referenced 69484544 I upgraded to 6.4.0_rc10b from 6.4.0_rc8q...I never got these errors in 8q. Is there anything that changed between then and now that might be contributing to here? EDIT 3: So I just reverted back to rc8q and can confirm I can now run a scrub on my cache successfully without triggering the call traces...so that seems to rule out hardware issues and it's definitely something between 8q and 10b (although I'm not sure if it was between 8q and 9f, or 9f and 10b). I can't even find a download for 9f to be able to manually upgrade and determine which update the issue lies in. Now what? Edited October 30, 20178 yr by d.ohlin
October 30, 20178 yr Not sure also, first time I see that issue, call trace without an associate btrfs error/warning, you can try to re-format your cache: backups all data, format, restore, and see if the issue continues.
October 30, 20178 yr Author Hmmmm...alright I'm officially perplexed. In case anyone happens to find themselves running into anything similar, here's exactly the steps I took. So I wasn't completely sure on the best way to format the cache drive (in my case, drives - 2), so I did the following: 1. Stopped the array 2. Unassigned both cache devices 3. Re-assigned the cache devices as add'l. members of the main storage pool 4. Re-started the array (which obviously began clearing these 2 news disks) 5. Cancelling the clearing operation (pretty much immediately) and re-stopped the array 6. Re-assigned both previous cache disks as cache devices again 7. Re-started the array At that point it gave me the "unmountable" note and advised me to format them. I of course did so, and afterwards I was able to successfully run 3 scrubs on my cache pool (with and without the 'fix errors' box checked) without error. So I'm definitely confused as to what might have been going on before. Regardless, a little bit of up time should tell whether I'm truly good or not as previously the errors had happened within <24 hours of system uptime. Fingers crossed!
November 1, 20178 yr Author Just figured I'd come back to give an update on this as so often people don't post any confirmation of whether their solutions ended up working It would appear that I'm good to go (knock on wood!) as I'm at ~50 hours of uptime so far with no issues, and I just now confirmed again that I can run a scrub on the cache drive without triggering any log errors. Thanks again for all the help! Edited November 1, 20178 yr by d.ohlin
Archived
This topic is now archived and is closed to further replies.