May 30, 20251 yr Had a random disk drop that was healthy. After running dry runs of xfs_repair, it could not find a superblock. Running xfs_data on it found a zeroed out header and a version of xfs that is really old.Output:xfs_db: /dev/sdc is not a valid XFS filesystem (unexpected SB magic number 0x00000000) xfs_db: V1 inodes unsupported. Please try an older xfsprogs.Diagnostics attached. Currently thinking of running an older version of unraid (6.10 era) to see if xfs_data or xfs_repair can communicate with whatever metadata got scrambled during the final phases of repair. Parity process reported 0 errors once finished.Ordering a HDD now to dd image the disk to for non-destructive troubleshooting.Any suggestions? tower-diagnostics-20250530-1250.zip
May 31, 20251 yr having the same problem on my disk2/3. it happened after i moved my HDDs to a cage and installed a new LSI card. disk1 is not behaving for a while now, not sure if it's the cause tho.chito-diagnostics-20250528-1114.zip
May 31, 20251 yr Community Expert Solution 8 hours ago, Unraid_Student said:/dev/sdcThis won't work, start the array in maintenance mode and check filesystem.
May 31, 20251 yr Author 8 hours ago, JorgeB said:This won't work, start the array in maintenance mode and check filesystem.Thanks! Will do this after recovering mission critical stuff and report back.
June 6, 20251 yr Author I was scared to use the GUI so I did this in maintenance instead - worked perfectly! I think the main issue was non maintenance mode and targeting wrong disk naming convention.1st Command:xfs_repair -v /dev/md2p1 Phase 1 - find and verify superblock... - block cache size set to 3823616 entries Phase 2 - using internal log - zero log... Log inconsistent or not a log (last==0, first!=1) empty log check failed zero_log: cannot find log head/tail (xlog_find_tail=22) ERROR: The log head and/or tail cannot be discovered. Attempt to mount the filesystem to replay the log or use the -L option to destroy the log and attempt a repair.2nd Command:xfs_repair -vL /dev/md2p1Phase 1 - find and verify superblock... - block cache size set to 3823616 entriesPhase 2 - using internal log - zero log...Log inconsistent or not a log (last==0, first!=1)empty log check failedzero_log: cannot find log head/tail (xlog_find_tail=22) - scan filesystem freespace and inode maps...clearing needsrepair flag and regenerating metadata - found root inode chunkPhase 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 - 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 = 3clearing reflink flag on inode 8949clearing reflink flag on inode 4429733124clearing reflink flag on inode 2147483778clearing reflink flag on inode 2671464208clearing reflink flag on inode 2671464209clearing reflink flag on inode 2671464210clearing reflink flag on inode 2671464211clearing reflink flag on inode 2671464212clearing reflink flag on inode 2671464214clearing reflink flag on inode 2671840328clearing reflink flag on inode 2671840337Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - reset superblock...Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ...Phase 7 - verify and correct link counts...Maximum metadata LSN (7:625855) is ahead of log (1:2).Format log to cycle 10.XFS_REPAIR Summary Fri Jun 6 00:42:39 2025Phase Start End DurationPhase 1: 06/06 00:28:14 06/06 00:28:14Phase 2: 06/06 00:28:14 06/06 00:28:51 37 secondsPhase 3: 06/06 00:28:51 06/06 00:29:03 12 secondsPhase 4: 06/06 00:29:03 06/06 00:29:05 2 secondsPhase 5: 06/06 00:29:05 06/06 00:29:06 1 secondPhase 6: 06/06 00:29:06 06/06 00:29:14 8 secondsPhase 7: 06/06 00:29:14 06/06 00:29:14Total run time: 1 minutedoneThanks :)
June 6, 20251 yr Community Expert 6 hours ago, Unraid_Student said:I was scared to use the GUI so I did this in maintenance instead - worked perfectly! I think the main issue was non maintenance mode and targeting wrong disk naming convention.Actually doing it via the GUI is safer as it stops you getting the device name wrong.
June 6, 20251 yr Author 5 hours ago, itimpi said:Actually doing it via the GUI is safer as it stops you getting the device name wrong.That's fair - after the random drop I just wanted to control what was going on in case of a random bug. Thanks for the tips unraid team!
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.