craigmaki09

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.

Running now, but doesn't look promising so far as has been running quite a while Phase 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?

Diagnostics And 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

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_repair Feb 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 74 Feb 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_repair Feb 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 ................

Adjusting the "Docker Stop Timeout:" to 120 seconds worked for me (including calibre-web).