April 4, 20233 yr I rebooted my server and when the server came back up, I have a disk that is giving me the error "Unmountable: Wrong or no file system". I shut down the system and reseated the SATA and power cables but when it came back up, the same error was still present. The drive shows as "active" and SMART short self-test results 'completed without error'. elwood-diagnostics-20230404-0821.zip I've attached the diagnostics and the drive in question is (sdi) or 9RKZXEEL. This is the first time I've had this error so at a loss as to what to do next. Thanks for the help!
April 4, 20233 yr Author Below is the results of the Check Filesystem Status. Phase 1 - find and verify superblock... - block cache size set to 1445992 entries Phase 2 - using internal log - zero log... zero_log: head block 895343 tail block 895290 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... sb_fdblocks 751711058, counted 751774095 - 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 data fork in ino 5122596659 claims free block 643438727 data fork in ino 5122596663 claims free block 644002918 data fork in ino 5122596665 claims free block 644129314 - agno = 3 - agno = 4 - agno = 5 imap claims a free inode 12379779031 is in use, would correct imap and clear inode bad key in bmbt root (is 0, would reset to 1536) in inode 12379779032 data fork data fork in ino 12379779032 claims free block 1549002105 data fork in ino 12379779032 claims free block 1547472170 data fork in ino 12379779032 claims free block 1549015357 data fork in ino 12379779032 claims free block 1549015765 data fork in ino 12379779032 claims free block 1549006477 data fork in ino 12379779032 claims free block 1549002617 data fork in ino 12379779032 claims free block 1549006989 data fork in ino 12379779032 claims free block 1549016277 data fork in ino 12379779032 claims free block 1549007501 bad nblocks 394112 for inode 12379779032, would reset to 336196 bad nextents 411 for inode 12379779032, would reset to 319 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 0 - agno = 2 - agno = 4 - agno = 3 - agno = 5 entry "Ghost.Adventures.S25E22.Lovelock.Triangle.1080p.WEB.h264-REALiTYTV[rarbg]" in shortform directory 2472611719 references free inode 12379779031 would have junked entry "Ghost.Adventures.S25E22.Lovelock.Triangle.1080p.WEB.h264-REALiTYTV[rarbg]" in directory inode 2472611719 would have corrected i8 count in directory 2472611719 from 1 to 0 entry "Ghost.Adventures.S25E22.Lovelock.Triangle.1080p.WEB.h264-REALiTYTV[rarbg]" in shortform directory 12379779012 references free inode 17479382997 would have junked entry "Ghost.Adventures.S25E22.Lovelock.Triangle.1080p.WEB.h264-REALiTYTV[rarbg]" in directory inode 12379779012 would have corrected i8 count in directory 12379779012 from 1 to 0 - agno = 6 - agno = 7 - agno = 8 - agno = 9 bad key in bmbt root (is 0, would reset to 1536) in inode 12379779032 data fork bad nblocks 394112 for inode 12379779032, would reset to 336196 bad nextents 411 for inode 12379779032, would reset to 319 - agno = 10 setting reflink flag on inode 5122596658 Missing reference count record for (2/106534273) len 33542 count 2 Missing reference count record for (2/106939687) len 85851 count 2 setting reflink flag on inode 5122596659 setting reflink flag on inode 5122596662 setting reflink flag on inode 5122596663 setting reflink flag on inode 5122596664 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 - agno = 1 entry "Ghost.Adventures.S25E22.Lovelock.Triangle.1080p.WEB.h264-REALiTYTV[rarbg]" in shortform directory inode 2472611719 points to free inode 12379779031 would junk entry would fix i8count in inode 2472611719 - agno = 2 - agno = 3 - agno = 4 - agno = 5 entry "Ghost.Adventures.S25E22.Lovelock.Triangle.1080p.WEB.h264-REALiTYTV[rarbg]" in shortform directory inode 12379779012 points to free inode 17479382997 would junk entry would fix i8count in inode 12379779012 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 12379779032, would move to lost+found disconnected inode 12379779033, would move to lost+found disconnected inode 12379779034, would move to lost+found disconnected inode 12379779035, would move to lost+found Phase 7 - verify link counts... would have reset inode 2472611719 nlinks from 3 to 2 would have reset inode 12379779012 nlinks from 3 to 2 Maximum metadata LSN (1:896856) is ahead of log (1:895343). Would format log to cycle 4. No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Tue Apr 4 06:21:32 2023 Phase Start End Duration Phase 1: 04/04 06:21:26 04/04 06:21:26 Phase 2: 04/04 06:21:26 04/04 06:21:27 1 second Phase 3: 04/04 06:21:27 04/04 06:21:31 4 seconds Phase 4: 04/04 06:21:31 04/04 06:21:31 Phase 5: Skipped Phase 6: 04/04 06:21:31 04/04 06:21:32 1 second Phase 7: 04/04 06:21:32 04/04 06:21:32 Total run time: 6 seconds
April 4, 20233 yr Author Based on that, I ran xfs_repair -v /dev/sdi1 and got Phase 1 - find and verify superblock... - block cache size set to 1445992 entries Phase 2 - using internal log - zero log... zero_log: head block 895343 tail block 895290 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.
April 4, 20233 yr Community Expert Solution Run it again without -n or nothing will be done, and if it ask for it use -L.
April 4, 20233 yr Author Ran the Check filesystem with the -L and that seems to have fixed it. I'll run a parity check and keep an eye on it, but I'll mark this as resolved. Thanks for the help!
April 6, 20233 yr Author Parity check returned 1127053 errors over a 96TB array. Parity check hadn't found any errors in the past year of running monthly checks. Should I be concerned with that or is it a function of the drive dropping off?
April 6, 20233 yr Community Expert On 4/4/2023 at 2:47 PM, m4lki3r said: Based on that, I ran xfs_repair -v /dev/sdi1 and got I didn't notice before but you cannot do this or it will invalidate parity, the linked instructions say to use the GUI or the mdX device, using the sdX device won't update parity so sync errors are expected after this.
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.