February 12, 20215 yr I seem to be in a similar situation. Logged into my unraid on a lark and discovered a pile of error notifications (my notification emails aren't working, apparently). My array is two 12TB parity disks and three data disks (two 12TB and one 6TB). Parity 2 and Disk 1 (12TB) are the error drives. I mounted the array in maintenance mode and ran XFS check on Disk 1 with the -nv option and... it completed within 20 seconds seemingly without finding any errors? Output below, plus I'm attaching the diagnostic zip. Running "check" again on Disk 1 with no option parameters didn't resolve the issue and both drives have passed short SMART tests, but I haven't run an extended SMART test on either drive yet. Also tried briefly restarting the array in non-maintenance mode after these checks, but no luck. This is my first experience with drive errors in unraid and the help guide seems to assume that "check" will find errors/provide advice, so I'm kinda at a loss for ideas here. Phase 1 - find and verify superblock... - block cache size set to 4096 entries Phase 2 - using internal log - zero log... zero_log: head block 111305 tail block 111305 - scan filesystem freespace and inode maps... - 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 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - 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 = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Thu Feb 11 22:31:38 2021 Phase Start End Duration Phase 1: 02/11 22:31:35 02/11 22:31:35 Phase 2: 02/11 22:31:35 02/11 22:31:36 1 second Phase 3: 02/11 22:31:36 02/11 22:31:37 1 second Phase 4: 02/11 22:31:37 02/11 22:31:37 Phase 5: Skipped Phase 6: 02/11 22:31:37 02/11 22:31:38 1 second Phase 7: 02/11 22:31:38 02/11 22:31:38 Total run time: 3 seconds vunraid-diagnostics-20210211-2226.zip
February 12, 20215 yr Author Logged into my unraid on a lark and discovered a pile of error notifications (my notification emails aren't working, apparently). My array consists of two 12TB parity disks and three data disks (two 12TB and one 6TB). Parity 2 and Disk 1 (12TB) are the error drives. I mounted the array in maintenance mode and ran XFS check on Disk 1 with the -nv option and... it completed within 20 seconds seemingly without finding any errors? Output below, plus I'm attaching the diagnostic zip. Running "check" again on Disk 1 with no option parameters didn't resolve the issue and both drives have passed short SMART tests, but I haven't run an extended SMART test on either drive yet. Also tried briefly restarting the array in non-maintenance mode after these checks, but no luck. This is my first experience with drive errors in unraid and the help guide seems to assume that "check" will find errors/provide advice, so I'm kinda at a loss for ideas here. Phase 1 - find and verify superblock... - block cache size set to 4096 entries Phase 2 - using internal log - zero log... zero_log: head block 111305 tail block 111305 - scan filesystem freespace and inode maps... - 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 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - 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 = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Thu Feb 11 22:31:38 2021 Phase Start End Duration Phase 1: 02/11 22:31:35 02/11 22:31:35 Phase 2: 02/11 22:31:35 02/11 22:31:36 1 second Phase 3: 02/11 22:31:36 02/11 22:31:37 1 second Phase 4: 02/11 22:31:37 02/11 22:31:37 Phase 5: Skipped Phase 6: 02/11 22:31:37 02/11 22:31:38 1 second Phase 7: 02/11 22:31:38 02/11 22:31:38 Total run time: 3 seconds vunraid-diagnostics-20210211-2226.zip
February 12, 20215 yr Community Expert I have split your post into its own thread. Please don't hijack. No evidence of filesystem problems so not surprising that filesystem check didn't find anything. Disk1 and Parity2 are disabled and need to be rebuilt. Are you running Unraid as a VM?
February 12, 20215 yr Author Yes, sorry, I thought better of hijacking immediately after posting, deleted my original comment, and started a new thread myself prior to your reply (which will need to be deleted now). Here's the new diagnostic with the array in normal mode. I'm running in ESXi 6.5u3 with all unraid drives (except the USB) on a passed-through LSI 2008 card. No power issues that I'm aware of (system is on a good UPS and hypervisor uptime is over six months at this point). Best practice for rebuild would be to use a spare to reconstruct Disk 1 and then deal with the disabled parity drive, yes? Thanks! vunraid-diagnostics-20210211-2257.zip
February 12, 20215 yr Community Expert 15 minutes ago, FlyingShawn said: Best practice for rebuild would be to use a spare to reconstruct Disk 1 and then deal with the disabled parity drive, yes? Yes, but it would be best if you could fix the problem that caused those disks to have problems. I don't have any experience with Unraid as a VM, and, in fact, that configuration isn't supported. So I don't know if you have something simple like bad connections, or something to do with your VM setup that caused this. We have a subforum where other people using Unraid as a VM help each other. I may move your thread there. 15 minutes ago, FlyingShawn said: started a new thread myself prior to your reply (which will need to be deleted now). I will have merge merged it into this thread. You can edit or delete your posts as you see fit.
February 12, 20215 yr Community Expert 33 minutes ago, trurl said: No evidence of filesystem problems so not surprising that filesystem check didn't find anything. And those latest diagnostics show emulated disk1 mounted so you should be able to see its files just fine.
February 12, 20215 yr Author Yeah, I'm aware that vm use is unsupported, but I'd be surprised if it was related to this considering there haven't been any hardware or configuration changes in months, nothing's been moved/jostled/power-cycled, and workloads on both ESXi and unraid have been pretty low (I'm not even sure if anything new has been written to the array in the last few months!).
February 12, 20215 yr Community Expert You can rebuild data disk to a spare and rebuild that parity disk at the same time. Then use Unassigned Devices to compare the original if you want, but since there wasn't any evidence of corruption should be fine.
Archived
This topic is now archived and is closed to further replies.