February 2, 20251 yr A hard drive failed on Friday and the replacements will arrive on Monday. There were a couple shares set to using only the drive that failed. These shares were readable Friday/Saturday, but do not exist today Sunday. Early Saturday a Read-Check started, which is still running and has not shown any read errors corrected. The failed drive is in an expected I/O error state UnRaid sees an expected amount of data on this drive and the Parity disk is still OK. (I remember about 2.8TB data used) Will I still be OK to replace the failed drive in this state? Any help would be much appreciated, Thank you! beast-diagnostics-20250202-0815.zip Edited February 2, 20251 yr by jenga201
February 2, 20251 yr Author Thanks. I started the array in maintenance mode and went to disk11. The Check button output 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 ignored because the -n option was used. Expect spurious inconsistencies which may be resolved by first mounting the filesystem to replay the log. - scan filesystem freespace and inode maps... Metadata CRC error detected at 0x47dddd, xfs_finobt block 0x20/0x1000 btree block 0/4 is suspect, error -74 sb_fdblocks 3223950395, counted 3251191352 - 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 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 5 - agno = 6 - agno = 8 - agno = 12 - agno = 2 - agno = 4 - agno = 3 - agno = 7 - agno = 9 - agno = 10 - agno = 11 - agno = 14 - agno = 13 - agno = 1 No modify flag set, skipping phase 5 Inode allocation btrees are too corrupted, skipping phases 6 and 7 No modify flag set, skipping filesystem flush and exiting. The Fix command output Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... 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. I see a button that says Zero Log, but I'm not sure that's what I should do. What is the preferred process after this? Should I; 1) mount /dev/md11p1 /temp/dir 2) unmount /temp/dir 3) Refresh WebUI disk11 and try to re-run Check/Fix ?
February 3, 20251 yr Community Expert 15 hours ago, jenga201 said: but I'm not sure that's what I should do. If the disk still mounts, you can try that, but likely it won't, so just click it.
February 3, 20251 yr Author Thank you so much, JorgeB. I replaced the failed drive, started the array and parity started to rebuild. The old drive was mountable using unassigned disk drives and all data seemed in tact. Worst case, I can copy from the old drive if the disk11 FS is still corrupt after parity rebuild.
February 3, 20251 yr Author No, I believe the file system is still corrupt in the parity (if that's possible). I'm waiting for the parity to finish rebuilding before fixing the file system on the good disk. About 2 days to go
February 4, 20251 yr Community Expert You should repair the filesystem before rebuilding, to see if the rebuild is worth it.
February 4, 20251 yr Author Awesome, Thanks JorgeB! I can see all the missing shares and the data rebuild is progressing. For anybody else, this disk wasn't actually bad. It was just the file system was corrupted. All I really had to do was; start in maintenance mode check & fix the file system stop the array mount the disk using unassigned devices unmount start the array normally wait for the Data-Rebuild to finish Edited February 4, 20251 yr by jenga201
February 4, 20251 yr Community Expert 6 minutes ago, jenga201 said: fix the file system Post new diagnostics
February 4, 20251 yr Community Expert 22 minutes ago, trurl said: Post new diagnostics Or just check yourself to see if you have a lost+found share. If you do, you can click Compute... for it on the User Shares page to see how much repair couldn't figure out.
February 4, 20251 yr Author Ah gotcha. Thanks for that info. I saw the lost+found dir and found it to be a single chunk proxmox backup file. I've scanned that and re-backed up the vm.
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.