April 10, 20251 yr Author Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... entry "A Shot Through the Wall (2022) {imdb-tt8588414} [WEBDL-1080p][AC3 5.1][h264]-EVO.mkv" in directory inode 135 not consistent with .. value (15032385667) in inode 34359738564, junking entry entry "A Shot ThroumiHT2BPO3022) {idb-tt8588414} [WEBDL-1080p][AC3 5.1][h264]-EVO.nfo" in directory inode 135 not consistent with .. value (10737418369) in inode 136, junking entry fixing i8count in inode 135 bad hash table for directory inode 33693602 (no data entry): rebuilding rebuilding directory inode 33693602 entry "Season 12" in dir ino 2147483794 doesn't have a .. entry, will set it in ino 4294967438. bad hash table for directory inode 2147483835 (no data entry): rebuilding rebuilding directory inode 2147483835 bad hash table for directory inode 2165900194 (no data entry): rebuilding rebuilding directory inode 2165900194 entry ".." in directory inode 2351323147 points to free inode 176, junking entry bad hash table for directory inode 2351323147 (no data entry): rebuilding rebuilding directory inode 2351323147 corrupt block 1 in directory inode 4294967424: junking block entry "Memories of Murder (2003)" in dir ino 4294967424 doesn't have a .. entry, will set it in ino 4294967454. corrupt block 3 in directory inode 4294967424: junking block entry "Triangle of Sadness (2022)" in dir ino 4294967424 doesn't have a .. entry, will set it in ino 4294967436. rebuilding directory inode 4294967424 Metadata corruption detected at 0x47b3d2, inode 0x10000008f dinode fatal error -- couldn't map inode 4294967439, err = 117 This is the end of the output
April 10, 20251 yr Community Expert Xfs_repair is unable to fix the filesystem, you can try upgrading to 7.1-beta.4 to see if a newer kernel/tools help, if still not, you will need to restore from a backup, or try a file recovery app like UFS explorer.
April 10, 20251 yr Author I do not have any backups of my array, only flash and appdata, and prefer to stay on the stable version of unraid. I don't mind losing some of the data on disk19 as I can get it back pretty easily. Is there a way to keep whatever is being emulated and get back to a healthy parity/array state even if I lose some of what's on that bad disk19?
April 10, 20251 yr Author Also, thank you for joining in JorgeB, the support from you and trurl has been invaluable!
April 10, 20251 yr Community Expert 27 minutes ago, Lean_ said: Is there a way to keep whatever is being emulated Not sure I follow, nothing is being emulated from disk19, since it doesn't mount.
April 10, 20251 yr Community Expert It's emulated, but note no used/free stats for that disk, because it's not mounted:
April 10, 20251 yr Author Understood, if I'm okay losing the ~9tb that's on here, how should I proceed to get the drive working again and parity in a good state? Would I have to restart the array and format disk19 and allow parity to resync? Also, should I still be worried about the other drives presenting read errors again? Or was that only an issue because I was rebuilding an unmountable filesystem with bad parity. Edited April 10, 20251 yr by Lean_
April 10, 20251 yr Community Expert Solution 8 minutes ago, Lean_ said: how should I proceed to get the drive working again and parity in a good state? Finished the rebuild and format the disk, or vice versa. 8 minutes ago, Lean_ said: Or was that only an issue because I was rebuilding an unmountable filesystem with bad parity. Most likely.
April 10, 20251 yr Author Wish me luck! rebuild has started with a now mountable, formatted disk. Thank you guys for all the help, I will update this with any new info and/or mark any solution.
April 12, 20251 yr Author Update: After formatting the disk and rebuilding/resyncing everything is back to normal in a healthy state, still not sure about the root cause but quite possibly had some weird power issue even though I'm on a UPS since my uptime reset even though I had no NUT reports of an outage.
April 12, 20251 yr Author Sorry, new problem I have 3 more disks with read errors suddenly, while typing this it is now 4 disks. superplex-diagnostics-20250412-1313.zip
April 12, 20251 yr Author I reinstalled mover tuning plugin and re-enabled my script that runs "sudo modprobe disktemp" for my coolercontrol docker container to be able to see disk temp sensors
April 12, 20251 yr Author I'm using dual platinum PWS-920P-SQ's. - I was using a new one ONLY during the rebuild that took the past 2 days. I wonder if plugging in the second PSU may be the culprit? is it safe to shutdown with read errors on theses disks? I will unplug the potential bad PSU and monitor disks for a while longer.
April 12, 20251 yr Community Expert 2 hours ago, Lean_ said: is it safe to shutdown with read errors on theses disks? yes
April 13, 20251 yr Community Expert Errors look like a power/connection issue, could be a backplane issue for example.
April 13, 20251 yr Author Understood, If I run into more issues on the newer PSU I think the next steps will be swapping out the HBA, and then lastly the backplane since it's the more expensive item.
April 17, 20251 yr Author So, I went 4 days with no errors on a new PSU and decided to try out 'sudo modprobe disktemp' again for my fan controller docker container and I had 2 disks instantly get disabled. I'm guessing it wasn't the PSU after all and just this module being incompatible
April 17, 20251 yr Author checking the filesystem status of the disks in maintenance mode returns: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - 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 - 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. Am I going to need to rebuild again? ;( superplex-diagnostics-20250417-0745.zip
April 17, 20251 yr Community Expert 1 minute ago, Lean_ said: checking the filesystem status of the disks in maintenance mode The screenshot doesn't show any disks unmountable, just disabled. And I didn't notice anything in syslog that indicated filesystem repair was needed. 4 minutes ago, Lean_ said: rebuild again? That is the way you take care of disabled disks.
April 17, 20251 yr Community Expert 19 minutes ago, trurl said: That is the way you take care of disabled disks. If you do get a disabled disk that is also unmountable, best to repair before rebuild. Otherwise you rebuild an unmountable disk.
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.