July 8, 20169 yr I don't know if this issue is docker related or that is just what I use the most and noticed first. I am able to access the web gui just fine, but while I can see the user shares from my computer, they do not open. I can open all the disks except disk 1. I ran a short SMART test on disk 1 and it passed. Running long test now. I tried to delete my docker and start it over and the system worked fine for a few hours, but I am having the same issue again. This seems to be a telling part of the log, but the full log is also attached. I ran memtest for 6 hours and it was good, may run it again overnight tonight. Thanks for any help. Jul 7 18:53:38 Tower kernel: XFS (md1): xfs_do_force_shutdown(0x8) called from line 1008 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff8127468c Jul 7 18:53:38 Tower kernel: XFS (md1): Corruption of in-memory data detected. Shutting down filesystem Jul 7 18:53:38 Tower kernel: XFS (md1): Please umount the filesystem and rectify the problem(s) Jul 7 18:53:38 Tower shfs/user: shfs_create: create_path: /mnt/disk1/appdata/plexmediaserver/Library/Application Support/Plex Media Server/Media/localhost/5/de2baf69df4c7dbdc5ff6c0ed28a961bf7bdc03.bundle/Contents appdata/plexmediaserver/Library/Application Support/Plex Media Server/Media/localhost/5/de2baf69df4c7dbdc5ff6c0ed28a961bf7bdc03.bundle/Contents/Art/art1.jpg /mnt/disk12/appdata/plexmediaserver/Library/Application Support/Plex Media Server/Media/localhost/5/de2baf69df4c7dbdc5ff6c0ed28a961bf7bdc03.bundle/Contents (117) Structure needs cleaning Jul 7 18:53:39 Tower shfs/user: shfs_write: write: (5) Input/output error Jul 7 18:53:39 Tower shfs/user: shfs_write: write: (5) Input/output error Jul 7 18:53:39 Tower shfs/user: shfs_write: write: (5) Input/output error Jul 7 18:53:39 Tower shfs/user: shfs_write: write: (5) Input/output error Jul 7 18:53:39 Tower shfs/user: shfs_write: write: (5) Input/output error tower-diagnostics-20160707-2020.zip
July 8, 20169 yr Memtest would have been my first step, you've done that, good thinking. All of the XFS errors appear to be related to Disk 1. It does show corrupted memory in the XFS code, looks like a bug in that code, but most likely due to some sort of corruption in the file system of Disk 1, something the coders didn't expect. Perhaps a later version of the XFS modules will fix it (in unRAID 6.2?), but for now you need to attempt to clean up the file system on Disk 1. Try using xfs_repair with the -v option first, see Check Disk File systems, then follow any instructions it gives you. If you can't fix the issues, you may need to copy off all data and reformat it. One other worrying thing in your syslog, your system appears to be exposed to the Internet? Search the syslog for lines with sshd and see if you recognize any of the IP's attempting to connect. Some of the related messaging looks worrying to me, but I'm not experienced with sshd messages.
July 8, 20169 yr Author Thanks for the help. Looks like I had some old port forwarding setup that I have fixed now. I went ahead and replaced that drive last night since I had a spare but that didn't fix it (still have the old one just in case). After the rebuild I did the xfs_repair and it went quickly and seems to be working now. Dockers are up and running and I can access disk 1 now, but I thought that once before. If its working as expected now do you think I am in the clear? Anything else to look for? Thanks again, here is the repair dialogue. root@Tower:~# xfs_repair -v /dev/md1 Phase 1 - find and verify superblock... - block cache size set to 1492440 entries Phase 2 - using internal log - zero log... zero_log: head block 1846658 tail block 1846658 - scan filesystem freespace and inode maps... agi_freecount 44, counted 7 in ag 2 finobt - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 5 - agno = 3 - agno = 4 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... XFS_REPAIR Summary Fri Jul 8 10:57:40 2016 Phase Start End Duration Phase 1: 07/08 10:57:07 07/08 10:57:07 Phase 2: 07/08 10:57:07 07/08 10:57:38 31 seconds Phase 3: 07/08 10:57:38 07/08 10:57:39 1 second Phase 4: 07/08 10:57:39 07/08 10:57:39 Phase 5: 07/08 10:57:39 07/08 10:57:39 Phase 6: 07/08 10:57:39 07/08 10:57:39 Phase 7: 07/08 10:57:39 07/08 10:57:39 Total run time: 32 seconds done
July 8, 20169 yr A rebuild just rebuilds what was there before, good if a drive fails, but unhelpful if there's file system corruption. I find xfs_repair to be very unhelpful in its messaging. I haven't yet found anything different in the report whether you run it on a clean drive or a corrupted one! You'd think it would say something obvious like "no problems found" or "problems were fixed"! Even the message about moving files to lost+found appears in both. That's what happens when there's a disconnect between the developer and any feedback mechanisms. Any feedback at all should have resulted in clearer results.
Archived
This topic is now archived and is closed to further replies.