Jump to content

Wrong or no file system


Go to solution Solved by JorgeB,

Recommended Posts

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!

Link to comment

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

Link to comment

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.

Link to comment
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.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...