May 6, 20242 yr Hey everyone. Would really appreciate some help here. I went out of town for 3-4 days, and returned to drives having a bunch of errors. I did a safe restart via Unraid UI. When my server rebooted - 2 of 17 (19 with parities) drives are labeled as 'Disabled' and 'Unmountable:Unsupported or no file system'. Please help! Thanks in advance. kai-diagnostics-20240506-1726.zip
May 6, 20242 yr Community Expert SMART for both of those disks looks OK. Check filesystem on disk8 from the webUI. Capture the output and post it.
May 7, 20242 yr Author Here is the filecheck output. Phase 1 - find and verify superblock... bad primary superblock - bad CRC in superblock !!! attempting to find secondary superblock... .found candidate secondary superblock... verified secondary superblock... would write modified primary superblock Primary superblock would have been modified. Cannot proceed further in no_modify mode. Exiting now.
May 9, 20242 yr Author Apologies for the delayed post. Was traveling. Here are the results from running: -L Phase 1 - find and verify superblock... sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 128 resetting superblock root inode pointer to 128 sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap inode pointer to 129 sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary inode pointer to 130 Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata sb_icount 0, counted 74368 sb_ifree 0, counted 20780 sb_fdblocks 4394060173, counted 1298698275 - found root inode chunk Phase 3 - for each AG... - scan and 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 - agno = 15 - agno = 16 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 1 - agno = 4 - agno = 5 - agno = 10 - agno = 7 - agno = 3 - agno = 12 - agno = 14 - agno = 9 - agno = 15 - agno = 6 - agno = 11 - agno = 13 - agno = 8 - agno = 16 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (16:410369) is ahead of log (1:2). Format log to cycle 19. done
May 9, 20242 yr Author Unfortunately, the Disk 8 and Disk 12 are still showing red Xs. Ran -L for Disk 12 as well (before starting in Normal Mode): Phase 1 - find and verify superblock... sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 128 resetting superblock root inode pointer to 128 sb realtime bitmap inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 129 resetting superblock realtime bitmap inode pointer to 129 sb realtime summary inode value 18446744073709551615 (NULLFSINO) inconsistent with calculated value 130 resetting superblock realtime summary inode pointer to 130 Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata sb_icount 0, counted 57504 sb_ifree 0, counted 11834 sb_fdblocks 4882434433, counted 1257858882 - found root inode chunk Phase 3 - for each AG... - scan and 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 out-of-order bmap key (file offset) in inode 19381809594, data fork, fsbno 2427919491 bad data fork in inode 19381809594 cleared inode 19381809594 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - 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 = 1 - agno = 3 - agno = 9 - agno = 11 - agno = 12 - agno = 13 - agno = 4 - agno = 6 - agno = 14 - agno = 15 - agno = 7 - agno = 8 - agno = 10 - agno = 2 entry "Preacher.S02E01.2160p.WEB.H265-PETRiFiED.mkv" in shortform directory 19381809593 references free inode 19381809594 junking entry "Preacher.S02E01.2160p.WEB.H265-PETRiFiED.mkv" in directory inode 19381809593 corrected i8 count in directory 19381809593, was 4, now 3 - agno = 16 - agno = 17 - agno = 18 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (9:2219024) is ahead of log (1:2). Format log to cycle 12. done
May 9, 20242 yr Author Ran another Diagnostics after running -L on Disk 8 and Disk 12 and then booting in Normal Mode. Wanted to share - if it's helpful. kai-diagnostics-20240509-0902.zip
May 9, 20242 yr Community Expert Solution Disks 8 and 12 are mounting now, but they will remain disabled, that's expected until they are rebuilt, look for a lost+found folder, and if contents look correct you can rebuild them.
May 9, 20242 yr Community Expert 1 minute ago, Boy Kai said: Disk 8 and Disk 12 are still showing red Xs Repairing the filesystem will not fix that. But it will allow you to rebuild a mountable filesystem now. Looks like repair didn't create any lost+found, and the emulated disks are mounted with plenty of data. You can rebuild both at the same time. https://docs.unraid.net/unraid-os/manual/storage-management/#rebuilding-a-drive-onto-itself
May 9, 20242 yr Author Awesome! The array seems to be rebuilding now. THanks @trurl for that doc link and lost+found confirmation. Saved me a lot of time searching. Wish I could mark 2 posts as Solution. Thanks again!! QQ. Is it clear why this happened? Is there a way I can avoid in the future?
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.