treywarren

Thanks for all the help, that seems to have worked without any issues!

I can’t seem to mount it so is -L my only option?

Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... Metadata corruption detected at xfs_agf block 0x575428d9/0x200 flfirst 118 in agf 1 too large (max = 118) agf 118 freelist blocks bad, skipping freelist scan sb_fdblocks 51463847, counted 52201682 - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 3 - agno = 2 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. Thanks, that definitely seems to be the case. This was done before mounting then I pulled this log after mounting (cannot access webUI now). Any suggestions from here? tower-diagnostics-20170928-1326.zip

I feel like I'm chasing gremlins. The first problem I noticed was when trying to update docker programs there would be an error and I could no longer open or update them. Now I can only get the UI to load for safe mode. Drives look ok on the dashboard. Attached are log files and a bad picture of what is displayed when I mount the drives. Not sure if it is being picked up in the logs. tower-diagnostics-20170928-1058.zip

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

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

Well, I figured I would give it a shot and ran it with the -L command and it seems to be working. I will update this if anything changes. Here is the output of -L Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... agi_freecount 55, counted 34 in ag 2 finobt agi_freecount 10, counted 12 in ag 3 finobt sb_fdblocks 244062387, counted 244070579 - 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 data fork in ino 4626212297 claims free block 578276535 correcting imap correcting imap data fork in ino 4626212299 claims free block 578276544 data fork in ino 4626212299 claims free block 578276545 correcting imap correcting imap correcting imap correcting imap correcting imap data fork in ino 4626212304 claims free block 582587375 data fork in ino 4626212304 claims free block 582587376 correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap correcting imap - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 2 - agno = 1 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 4626212298, moving to lost+found Phase 7 - verify and correct link counts... done

Phase 1 - find and verify superblock... - block cache size set to 1492432 entries Phase 2 - using internal log - zero log... zero_log: head block 53802 tail block 53796 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. Not able to mount and run, any ideas before I try -L? I am actually in the middle of rebuilding and updating my setup so I am not too worried about data loss, but would like to avoid it if I can.

Attached is the log file. Pasted below is the log that happens after this zip when I try to start the array (can't figure out how to get the whole log after that) Jul 23 01:10:22 Tower emhttp: shcmd (31): rmmod md-mod |& logger Jul 23 01:10:22 Tower kernel: md: unRAID driver removed Jul 23 01:10:22 Tower emhttp: shcmd (32): modprobe md-mod super=/boot/config/super.dat slots=24 |& logger Jul 23 01:10:22 Tower kernel: md: unRAID driver 2.5.0 installed Jul 23 01:10:22 Tower emhttp: get_message: /boot/config/._Pro.key (-4) Jul 23 01:10:22 Tower emhttp: Pro key detected, GUID: 0781-5571-2000-010130107341 FILE: /boot/config/Pro.key Jul 23 01:10:22 Tower emhttp: Device inventory: Jul 23 01:10:22 Tower emhttp: shcmd (33): udevadm settle Jul 23 01:10:22 Tower emhttp: SSD2SC240G1SA754D117-820_PNY05150000696191589 (sdb) 234431064 Jul 23 01:10:22 Tower emhttp: WDC_WD40EZRX-00SPEB0_WD-WCC4E5SL3034 (sdc) 3907018584 Jul 23 01:10:22 Tower emhttp: WDC_WD20EARX-00PASB0_WD-WCAZAC946332 (sdd) 1953514584 Jul 23 01:10:22 Tower emhttp: WDC_WD40EZRX-00SPEB0_WD-WCC4E3TNXEPZ (sde) 3907018584 Jul 23 01:10:22 Tower emhttp: WDC_WD30EZRX-00D8PB0_WD-WCC4N0784239 (sdf) 2930266584 Jul 23 01:10:22 Tower emhttp: WDC_WD40EZRX-19SPEB0_WD-WCC4E3FLKZUT (sdg) 3907018584 Jul 23 01:10:22 Tower emhttp: WDC_WD40EZRX-22SPEB0_WD-WCC4E1FXXK89 (sdh) 3907018584 Jul 23 01:10:22 Tower emhttp: WDC_WD40EZRX-19SPEB0_WD-WCC4E7PL30PR (sdi) 3907018584 Jul 23 01:10:22 Tower emhttp: array slots: 24 Jul 23 01:10:22 Tower emhttp: cache slots: 1 Jul 23 01:10:22 Tower kernel: mdcmd (1): import 0 8,32 3907018532 WDC_WD40EZRX-00SPEB0_WD-WCC4E5SL3034 Jul 23 01:10:22 Tower kernel: md: import disk0: [8,32] (sdc) WDC_WD40EZRX-00SPEB0_WD-WCC4E5SL3034 size: 3907018532 Jul 23 01:10:22 Tower kernel: mdcmd (2): import 1 8,48 1953514552 WDC_WD20EARX-00PASB0_WD-WCAZAC946332 Jul 23 01:10:22 Tower kernel: md: import disk1: [8,48] (sdd) WDC_WD20EARX-00PASB0_WD-WCAZAC946332 size: 1953514552 Jul 23 01:10:22 Tower kernel: mdcmd (3): import 2 8,64 3907018532 WDC_WD40EZRX-00SPEB0_WD-WCC4E3TNXEPZ Jul 23 01:10:22 Tower kernel: md: import disk2: [8,64] (sde) WDC_WD40EZRX-00SPEB0_WD-WCC4E3TNXEPZ size: 3907018532 Jul 23 01:10:22 Tower kernel: mdcmd (4): import 3 8,80 2930266532 WDC_WD30EZRX-00D8PB0_WD-WCC4N0784239 Jul 23 01:10:22 Tower kernel: md: import disk3: [8,80] (sdf) WDC_WD30EZRX-00D8PB0_WD-WCC4N0784239 size: 2930266532 Jul 23 01:10:22 Tower kernel: mdcmd (5): import 4 8,96 3907018532 WDC_WD40EZRX-19SPEB0_WD-WCC4E3FLKZUT Jul 23 01:10:22 Tower kernel: md: import disk4: [8,96] (sdg) WDC_WD40EZRX-19SPEB0_WD-WCC4E3FLKZUT size: 3907018532 Jul 23 01:10:22 Tower kernel: mdcmd (6): import 5 8,112 3907018532 WDC_WD40EZRX-22SPEB0_WD-WCC4E1FXXK89 Jul 23 01:10:22 Tower kernel: md: import disk5: [8,112] (sdh) WDC_WD40EZRX-22SPEB0_WD-WCC4E1FXXK89 size: 3907018532 Jul 23 01:10:22 Tower kernel: mdcmd (7): import 6 8,128 3907018532 WDC_WD40EZRX-19SPEB0_WD-WCC4E7PL30PR Jul 23 01:10:22 Tower kernel: md: import disk6: [8,128] (sdi) WDC_WD40EZRX-19SPEB0_WD-WCC4E7PL30PR size: 3907018532 Jul 23 01:10:22 Tower kernel: mdcmd (: import 7 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (9): import 8 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (10): import 9 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (11): import 10 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (12): import 11 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (13): import 12 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (14): import 13 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (15): import 14 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (16): import 15 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (17): import 16 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (18): import 17 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (19): import 18 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (20): import 19 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (21): import 20 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (22): import 21 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (23): import 22 0,0 Jul 23 01:10:22 Tower kernel: mdcmd (24): import 23 0,0 Jul 23 01:10:22 Tower emhttp: import 24 cache device: no device Jul 23 01:10:22 Tower emhttp: import flash device: sda Jul 23 01:10:23 Tower emhttp: Spinning up all drives... Jul 23 01:10:23 Tower kernel: mdcmd (25): spinup 0 Jul 23 01:10:23 Tower kernel: mdcmd (26): spinup 1 Jul 23 01:10:23 Tower kernel: mdcmd (27): spinup 2 Jul 23 01:10:23 Tower kernel: mdcmd (28): spinup 3 Jul 23 01:10:23 Tower kernel: mdcmd (29): spinup 4 Jul 23 01:10:23 Tower kernel: mdcmd (30): spinup 5 Jul 23 01:10:23 Tower kernel: mdcmd (31): spinup 6 Jul 23 01:10:23 Tower emhttp: shcmd (34): /usr/local/sbin/set_ncq sdc 1 &> /dev/null Jul 23 01:10:23 Tower kernel: mdcmd (32): set md_num_stripes 1280 Jul 23 01:10:23 Tower kernel: mdcmd (33): set md_write_limit 768 Jul 23 01:10:23 Tower kernel: mdcmd (34): set md_sync_window 384 Jul 23 01:10:23 Tower kernel: mdcmd (35): set spinup_group 0 0 Jul 23 01:10:23 Tower kernel: mdcmd (36): set spinup_group 1 0 Jul 23 01:10:23 Tower kernel: mdcmd (37): set spinup_group 2 0 Jul 23 01:10:23 Tower kernel: mdcmd (38): set spinup_group 3 0 Jul 23 01:10:23 Tower kernel: mdcmd (39): set spinup_group 4 0 Jul 23 01:10:23 Tower kernel: mdcmd (40): set spinup_group 5 0 Jul 23 01:10:23 Tower kernel: mdcmd (41): set spinup_group 6 0 Jul 23 01:10:23 Tower emhttp: shcmd (35): /usr/local/sbin/set_ncq sdd 1 &> /dev/null Jul 23 01:10:23 Tower emhttp: shcmd (36): /usr/local/sbin/set_ncq sde 1 &> /dev/null Jul 23 01:10:23 Tower emhttp: shcmd (37): /usr/local/sbin/set_ncq sdf 1 &> /dev/null Jul 23 01:10:23 Tower emhttp: shcmd (38): /usr/local/sbin/set_ncq sdg 1 &> /dev/null Jul 23 01:10:23 Tower emhttp: shcmd (39): /usr/local/sbin/set_ncq sdh 1 &> /dev/null Jul 23 01:10:23 Tower emhttp: shcmd (40): /usr/local/sbin/set_ncq sdi 1 &> /dev/null Jul 23 01:10:23 Tower emhttp: Start array... Jul 23 01:10:23 Tower kernel: mdcmd (42): start STOPPED Jul 23 01:10:23 Tower kernel: unraid: allocating 42180K for 1280 stripes (7 disks) Jul 23 01:10:23 Tower kernel: md1: running, size: 1953514552 blocks Jul 23 01:10:23 Tower kernel: md2: running, size: 3907018532 blocks Jul 23 01:10:23 Tower kernel: md3: running, size: 2930266532 blocks Jul 23 01:10:23 Tower kernel: md4: running, size: 3907018532 blocks Jul 23 01:10:23 Tower kernel: md5: running, size: 3907018532 blocks Jul 23 01:10:23 Tower kernel: md6: running, size: 3907018532 blocks Jul 23 01:10:23 Tower emhttp: shcmd (41): udevadm settle Jul 23 01:10:23 Tower emhttp: Mounting disks... Jul 23 01:10:23 Tower emhttp: shcmd (42): /sbin/btrfs device scan |& logger Jul 23 01:10:23 Tower logger: Scanning for Btrfs filesystems Jul 23 01:10:23 Tower emhttp: shcmd (43): mkdir -p /mnt/disk1 Jul 23 01:10:23 Tower emhttp: shcmd (44): set -o pipefail ; mount -t xfs -o noatime,nodiratime /dev/md1 /mnt/disk1 |& logger Jul 23 01:10:23 Tower kernel: XFS (md1): Mounting V5 Filesystem Jul 23 01:10:24 Tower emhttp: shcmd (45): xfs_growfs /mnt/disk1 |& logger Jul 23 01:10:24 Tower kernel: XFS (md1): Ending clean mount Jul 23 01:10:24 Tower logger: meta-data=/dev/md1 isize=512 agcount=4, agsize=122094660 blks Jul 23 01:10:24 Tower logger: = sectsz=512 attr=2, projid32bit=1 Jul 23 01:10:24 Tower logger: = crc=1 finobt=1 Jul 23 01:10:24 Tower logger: data = bsize=4096 blocks=488378638, imaxpct=5 Jul 23 01:10:24 Tower logger: = sunit=0 swidth=0 blks Jul 23 01:10:24 Tower logger: naming =version 2 bsize=4096 ascii-ci=0 ftype=1 Jul 23 01:10:24 Tower logger: log =internal bsize=4096 blocks=238466, version=2 Jul 23 01:10:24 Tower logger: = sectsz=512 sunit=0 blks, lazy-count=1 Jul 23 01:10:24 Tower logger: realtime =none extsz=4096 blocks=0, rtextents=0 Jul 23 01:10:24 Tower emhttp: shcmd (46): mkdir -p /mnt/disk2 Jul 23 01:10:24 Tower emhttp: shcmd (47): set -o pipefail ; mount -t xfs -o noatime,nodiratime /dev/md2 /mnt/disk2 |& logger Jul 23 01:10:24 Tower kernel: XFS (md2): Mounting V5 Filesystem Jul 23 01:10:24 Tower emhttp: shcmd (48): xfs_growfs /mnt/disk2 |& logger Jul 23 01:10:24 Tower kernel: XFS (md2): Ending clean mount Jul 23 01:10:24 Tower logger: meta-data=/dev/md2 isize=512 agcount=4, agsize=244188659 blks Jul 23 01:10:24 Tower logger: = sectsz=512 attr=2, projid32bit=1 Jul 23 01:10:24 Tower logger: = crc=1 finobt=1 Jul 23 01:10:24 Tower logger: data = bsize=4096 blocks=976754633, imaxpct=5 Jul 23 01:10:24 Tower logger: = sunit=0 swidth=0 blks Jul 23 01:10:24 Tower logger: naming =version 2 bsize=4096 ascii-ci=0 ftype=1 Jul 23 01:10:24 Tower logger: log =internal bsize=4096 blocks=476930, version=2 Jul 23 01:10:24 Tower logger: = sectsz=512 sunit=0 blks, lazy-count=1 Jul 23 01:10:24 Tower logger: realtime =none extsz=4096 blocks=0, rtextents=0 Jul 23 01:10:24 Tower emhttp: shcmd (49): mkdir -p /mnt/disk3 Jul 23 01:10:24 Tower emhttp: shcmd (50): set -o pipefail ; mount -t xfs -o noatime,nodiratime /dev/md3 /mnt/disk3 |& logger Jul 23 01:10:24 Tower kernel: XFS (md3): Mounting V5 Filesystem Jul 23 01:10:24 Tower kernel: XFS (md3): Starting recovery (logdev: internal) Jul 23 01:10:25 Tower kernel: XFS: Internal error XFS_WANT_CORRUPTED_GOTO at line 1594 of file fs/xfs/libxfs/xfs_alloc.c. Caller xfs_free_extent+0xbe/0xef Jul 23 01:10:25 Tower kernel: CPU: 3 PID: 28999 Comm: mount Not tainted 4.0.4-unRAID #5 Jul 23 01:10:25 Tower kernel: Hardware name: Supermicro X10SL7-F/X10SL7-F, BIOS 2.2 03/24/2015 Jul 23 01:10:25 Tower kernel: ffff880409e50410 ffff8803f91ebae8 ffffffff815ff789 ffff88041fcce601 Jul 23 01:10:25 Tower kernel: ffff880409ca3800 ffff8803f91ebb08 ffffffff8127a230 ffffffff8124cd93 Jul 23 01:10:25 Tower kernel: 00000000070273c1 ffff8803f91ebb88 ffffffff8124bd66 0000000200000000 Jul 23 01:10:25 Tower kernel: Call Trace: Jul 23 01:10:25 Tower kernel: [] dump_stack+0x4c/0x6e Jul 23 01:10:25 Tower kernel: [] xfs_error_report+0x38/0x3a Jul 23 01:10:25 Tower kernel: [] ? xfs_free_extent+0xbe/0xef Jul 23 01:10:25 Tower kernel: [] xfs_free_ag_extent+0xd3/0x51d Jul 23 01:10:25 Tower kernel: [] xfs_free_extent+0xbe/0xef Jul 23 01:10:25 Tower kernel: [] xlog_recover_process_efi+0x122/0x170 Jul 23 01:10:25 Tower kernel: [] ? unlock_new_inode+0x57/0x5c Jul 23 01:10:25 Tower kernel: [] xlog_recover_process_efis+0x63/0xa5 Jul 23 01:10:25 Tower kernel: [] xlog_recover_finish+0x18/0x94 Jul 23 01:10:25 Tower kernel: [] xfs_log_mount_finish+0x23/0x3c Jul 23 01:10:25 Tower kernel: [] ? xfs_iunlock+0x44/0x5d Jul 23 01:10:25 Tower kernel: [] xfs_mountfs+0x563/0x60a Jul 23 01:10:25 Tower kernel: [] xfs_fs_fill_super+0x27d/0x317 Jul 23 01:10:25 Tower kernel: [] mount_bdev+0x13e/0x192 Jul 23 01:10:25 Tower kernel: [] ? xfs_parseargs+0x9a9/0x9a9 Jul 23 01:10:25 Tower kernel: [] xfs_fs_mount+0x10/0x12 Jul 23 01:10:25 Tower kernel: [] mount_fs+0x12/0x8d Jul 23 01:10:25 Tower kernel: [] vfs_kern_mount+0x5f/0xf8 Jul 23 01:10:25 Tower kernel: [] do_mount+0x832/0x929 Jul 23 01:10:25 Tower kernel: [] ? strndup_user+0x37/0x82 Jul 23 01:10:25 Tower kernel: [] SyS_mount+0x72/0xa1 Jul 23 01:10:25 Tower kernel: [] system_call_fastpath+0x12/0x17 Jul 23 01:10:25 Tower kernel: XFS (md3): Failed to recover EFIs Jul 23 01:10:25 Tower kernel: XFS (md3): log mount finish failed tower-diagnostics-20150722-2121.zip

I am getting this error when I try to start my array. I can start it in maintenance mode, but when I try to bring the array online I get this error. Jul 22 16:47:28 Tower kernel: XFS (md3): Mounting V5 Filesystem Jul 22 16:47:29 Tower kernel: XFS (md3): Starting recovery (logdev: internal) Jul 22 16:47:29 Tower kernel: XFS: Internal error XFS_WANT_CORRUPTED_GOTO at line 1594 of file fs/xfs/libxfs/xfs_alloc.c. Caller xfs_free_extent+0xbe/0xef Jul 22 16:47:29 Tower kernel: CPU: 0 PID: 32148 Comm: mount Tainted: G W 4.0.4-unRAID #5 Jul 22 16:47:29 Tower kernel: Hardware name: Supermicro X10SL7-F/X10SL7-F, BIOS 2.2 03/24/2015 Jul 22 16:47:29 Tower kernel: ffff88040af27ad0 ffff8803f8897ae8 ffffffff815ff789 ffff88041fc0e601 Jul 22 16:47:29 Tower kernel: ffff8800d9535000 ffff8803f8897b08 ffffffff8127a230 ffffffff8124cd93 Jul 22 16:47:29 Tower kernel: 00000000070273c1 ffff8803f8897b88 ffffffff8124bd66 0000000200000000 Jul 22 16:47:29 Tower kernel: Call Trace: Jul 22 16:47:29 Tower kernel: [] dump_stack+0x4c/0x6e Jul 22 16:47:29 Tower kernel: [] xfs_error_report+0x38/0x3a Jul 22 16:47:29 Tower kernel: [] ? xfs_free_extent+0xbe/0xef Jul 22 16:47:29 Tower kernel: [] xfs_free_ag_extent+0xd3/0x51d Jul 22 16:47:29 Tower kernel: [] xfs_free_extent+0xbe/0xef Jul 22 16:47:29 Tower kernel: [] xlog_recover_process_efi+0x122/0x170 Jul 22 16:47:29 Tower kernel: [] ? unlock_new_inode+0x57/0x5c Jul 22 16:47:29 Tower kernel: [] xlog_recover_process_efis+0x63/0xa5 Jul 22 16:47:29 Tower kernel: [] xlog_recover_finish+0x18/0x94 Jul 22 16:47:29 Tower kernel: [] xfs_log_mount_finish+0x23/0x3c Jul 22 16:47:29 Tower kernel: [] ? xfs_iunlock+0x44/0x5d Jul 22 16:47:29 Tower kernel: [] xfs_mountfs+0x563/0x60a Jul 22 16:47:29 Tower kernel: [] xfs_fs_fill_super+0x27d/0x317 Jul 22 16:47:29 Tower kernel: [] mount_bdev+0x13e/0x192 Jul 22 16:47:29 Tower kernel: [] ? xfs_parseargs+0x9a9/0x9a9 Jul 22 16:47:29 Tower kernel: [] xfs_fs_mount+0x10/0x12 Jul 22 16:47:29 Tower kernel: [] mount_fs+0x12/0x8d Jul 22 16:47:29 Tower kernel: [] vfs_kern_mount+0x5f/0xf8 Jul 22 16:47:29 Tower kernel: [] do_mount+0x832/0x929 Jul 22 16:47:29 Tower kernel: [] ? strndup_user+0x37/0x82 Jul 22 16:47:29 Tower kernel: [] SyS_mount+0x72/0xa1 Jul 22 16:47:29 Tower kernel: [] system_call_fastpath+0x12/0x17 Jul 22 16:47:29 Tower kernel: XFS (md3): Failed to recover EFIs Jul 22 16:47:29 Tower kernel: XFS (md3): log mount finish failed Any ideas?

Well I sorted out why one drive was connecting but not the other by replacing the network.cfg file on the old drive. It seems to be working now, but I still am getting the interrupt 42 error on the new drive. I have not rebooted the Unraid server because I am just happy it is working for now. I some spare drives coming in today to copy some important stuff to before I try rebooting to see if it is really sorted out. Anybody had the interrupt 42 error before?

I have tried new cables and even a different router, so I don't think that is the problem. This is the ifconfig when I use the new virgin flash drive. I don't have a pro license for this one so I would rather use the previous one, but don't know if its as simple as deleting a few settings and starting over or what. Also, I was able to access the web interface from this new drive.

I had a power outage yesterday and was not able to shut down cleanly before my UPS died as well. I am having all sorts of connection issues and I can't pinpoint the problem. I have trouble connecting to the web interface reliably. When I can connect to that I have trouble staying connected to shares. I have tried updating to a newer release (I was on rc12, now on the current release) and have have same issues on and off since. I have even installed unraid on a new flash drive and seem to have a similar issue. I attached the current ifconfig. Any suggestions on my next step? Everything else on my network seems to be working fine and I have tried a different router.