February 6Feb 6 I had a long series of CRC errors where Unraid "fixed" the drives, but when they came back the most of my appdata directories were empty but for a few log files. [not sure why unraid didn't use the parity to fill in the corrupted data]. My appdata backup has been giving repeated errors and not saving containers for a long while and I have been to complacent to figure out what was going wrong. Am I totally screwed and need to rebuild from scratch? THoughts?Diagnostic Logs have pages like this:Feb 6 08:18:07 Tower kernel: XFS (md4p1): Metadata CRC error detected at xfs_agfl_read_verify+0x27/0x60, xfs_agfl block 0x3 Feb 6 08:18:07 Tower kernel: XFS (md4p1): Unmount and run xfs_repairFeb 6 08:18:07 Tower kernel: XFS (md4p1): First 128 bytes of corrupted metadata buffer:Feb 6 08:18:07 Tower kernel: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:07 Tower kernel: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:07 Tower kernel: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:07 Tower kernel: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:07 Tower kernel: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:07 Tower kernel: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:07 Tower kernel: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:07 Tower kernel: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:07 Tower kernel: XFS (md4p1): metadata I/O error in "xfs_alloc_read_agfl+0x8d/0xf0" at daddr 0x3 len 1 error 74Feb 6 08:18:07 Tower kernel: XFS (md4p1): page discard on page 00000000a864de33, inode 0x88, pos 0.Feb 6 08:18:08 Tower kernel: XFS (md4p1): Metadata CRC error detected at xfs_agfl_read_verify+0x27/0x60, xfs_agfl block 0x3 Feb 6 08:18:08 Tower kernel: XFS (md4p1): Unmount and run xfs_repairFeb 6 08:18:08 Tower kernel: XFS (md4p1): First 128 bytes of corrupted metadata buffer:Feb 6 08:18:08 Tower kernel: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:08 Tower kernel: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:08 Tower kernel: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:08 Tower kernel: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:08 Tower kernel: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:08 Tower kernel: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:08 Tower kernel: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................Feb 6 08:18:08 Tower kernel: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
February 6Feb 6 Community Expert The logs you posted mean disk4 has corruption.Appdata should not be on the array.
February 6Feb 6 Author DiagnosticsAnd yes. Looks like disc 4 was the culprit. Rebooted and the system removed disc 4 (now says: Unmountable: wrong or no file system) but unraid has brought most of the files back to existence. Interestingly, disc 4 it is a brand new disc, installed last week. A WD Ultrastar (WUH721414ALE601) from serverpartdeals. Need to figure that out.In the meantime, need to rebuild some of my dockers that didn't make it all the way back. tower-diagnostics-20260206-1046.zip
February 6Feb 6 Community Expert SMART for disk4 looks OK, so that is good. You need to repair its filesystem.8 minutes ago, trurl said:Check filesystem on disk416 minutes ago, craigmaki09 said:disc 4 it is a brand new discMaybe new to you: 9 Power_On_Hours -O--C- 096 096 000 - 31431about 3.5 years old
February 6Feb 6 Community Expert 20 minutes ago, craigmaki09 said:RebootedI guess you took those diagnostics and then rebooted? If so, post new diagnostics.If you haven't rebooted you should because your logs are full, then post new diagnostics.
February 6Feb 6 Author 36 minutes ago, trurl said:Check filesystem on disk4Running now, but doesn't look promising so far as has been running quite a whilePhase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ....found candidate secondary superblock... unable to verify superblock, continuing...As the drive had been nearly empty, and as Unraid rebuilt most of the missing bits from parity, is there any reason that I shouldn't just reformat it again - starting from scratch?
February 6Feb 6 Community Expert 6 minutes ago, craigmaki09 said:Unraid rebuilt most of the missing bits from parityWhat do you mean? Did you rebuild it? You didn't mention that. Unraid doesn't rebuild anything automatically. And rebuild typically won't fix filesystem corruption. If you format it, any data that was on the drive will be gone.
February 7Feb 7 Author No actual rebuild, but some of my dockers came back to life after reboot so I thought that maybe unraid pulled from the parity, but maybe it was just a permissions issue that resolved itself on reboot. Drive 4 still going through it's filesystem check/repair . . . Neary 24 hours and counting (still Phase 1). Hope it is done soon. Want my server back. Lol. Edited February 7Feb 7 by craigmaki09
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.