Jump to content

Unmountable Drive, Tried Repair, Files are missing - Please Help!

Barb

By Barb
in General Support

Go to solution Solved by itimpi,

Recommended Posts

Barb Noob

Barb

Posted
Posted (edited)

I have 3 8TB drives. Parity. Disk 1. Disk 2.

I was trying to watch a show on Plex and I got an error about files missing. I logged onto Unraid and I saw that there was a red X on Disk 1. The device was disabled and unmountable. The drive was also now showing up under Historical Devices. What was really weird is that even though it said Contents Emulated, when I looked for the files, there were a significant number of files missing. I've had a drive fail before and I was able to see all my files during that time. First thing I tried was swapping cables and that didn't change anything.

 

I did some research and tried a repair. File system is XFS. I ran a check with -nv and then -Lv.

 

The drive still showed up as unmountable and files were still missing. I shut everything down, disconnected the drive, restarted Unraid, and everything looked the same (red X) except now the device showed up as disconnected.

 

I shut everything down again, plugged the drive back in and this time when I restarted there was a yellow triangle next to the drive saying contents emulated. I stopped the array and there was no drive assigned to Disk 1. I selected the drive to assign to Disk 1 and there was a blue square saying New Drive. Weird.

 

I start the array and I get a message saying: Disk 1, drive not ready, content being reconstructed. Also: Parity sync / Data rebuild started.

 

I still can't see most of my files and I was afraid the parity rebuild was going to wipe the drive so I paused the rebuild right away.

 

I'm not sure how to proceed 

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
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 231474589, counted 245099536
        - 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
        - agno = 4
imap claims a free inode 8589934733 is in use, would correct imap and clear inode
imap claims a free inode 8589934734 is in use, would correct imap and clear inode
        - agno = 5
        - agno = 6
bad nblocks 43807 for inode 12884902050, would reset to 21279
        - agno = 7
        - 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 = 2
        - agno = 5
        - agno = 3
        - agno = 7
        - agno = 4
        - agno = 6
entry "Succession.S03E05.1080p.WEBRip.x265-RARBG.mp4" at block 0 offset 352 in directory inode 8589934728 references free inode 8589934733
	would clear inode number in entry at offset 352...
entry "Succession.S03E06.1080p.WEBRip.x265-RARBG.mp4" at block 0 offset 416 in directory inode 8589934728 references free inode 8589934734
	would clear inode number in entry at offset 416...
bad nblocks 43807 for inode 12884902050, would reset to 21279
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
entry "Succession.S03E05.1080p.WEBRip.x265-RARBG.mp4" in directory inode 8589934728 points to free inode 8589934733, would junk entry
entry "Succession.S03E06.1080p.WEBRip.x265-RARBG.mp4" in directory inode 8589934728 points to free inode 8589934734, would junk entry
bad hash table for directory inode 8589934728 (no data entry): would rebuild
would rebuild directory inode 8589934728
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
Maximum metadata LSN (7:2202465) is ahead of log (7:2201629).
Would format log to cycle 10.
No modify flag set, skipping filesystem flush and exiting.

Here is the Check with -nv 

Phase 1 - find and verify superblock...
        - block cache size set to 691296 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 2201629 tail block 2201625
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 231474589, counted 245099536
        - 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
        - agno = 4
imap claims a free inode 8589934733 is in use, would correct imap and clear inode
imap claims a free inode 8589934734 is in use, would correct imap and clear inode
        - agno = 5
        - agno = 6
bad nblocks 43807 for inode 12884902050, would reset to 21279
        - agno = 7
        - 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 = 5
        - agno = 7
        - agno = 2
        - agno = 6
        - agno = 3
        - agno = 4
entry "Succession.S03E05.mp4" at block 0 offset 352 in directory inode 8589934728 references free inode 8589934733
	would clear inode number in entry at offset 352...
entry "Succession.S03E06.mp4" at block 0 offset 416 in directory inode 8589934728 references free inode 8589934734
	would clear inode number in entry at offset 416...
bad nblocks 43807 for inode 12884902050, would reset to 21279
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
entry "Succession.S03E05.mp4" in directory inode 8589934728 points to free inode 8589934733, would junk entry
entry "Succession.S03E06.mp4" in directory inode 8589934728 points to free inode 8589934734, would junk entry
bad hash table for directory inode 8589934728 (no data entry): would rebuild
would rebuild directory inode 8589934728
        - agno = 5
        - agno = 6
        - agno = 7
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
Maximum metadata LSN (7:2202465) is ahead of log (7:2201629).
Would format log to cycle 10.
No modify flag set, skipping filesystem flush and exiting.

        XFS_REPAIR Summary    Sat Jan 14 21:18:00 2023

Phase		Start		End		Duration
Phase 1:	01/14 21:17:48	01/14 21:17:48
Phase 2:	01/14 21:17:48	01/14 21:17:49	1 second
Phase 3:	01/14 21:17:49	01/14 21:17:55	6 seconds
Phase 4:	01/14 21:17:55	01/14 21:17:55
Phase 5:	Skipped
Phase 6:	01/14 21:17:55	01/14 21:18:00	5 seconds
Phase 7:	01/14 21:18:00	01/14 21:18:00

Total run time: 12 seconds

 

 

Here is the check with -Lv 

Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
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 231474589, counted 245099536
        - 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
        - agno = 4
imap claims a free inode 8589934733 is in use, would correct imap and clear inode
imap claims a free inode 8589934734 is in use, would correct imap and clear inode
        - agno = 5
        - agno = 6
bad nblocks 43807 for inode 12884902050, would reset to 21279
        - agno = 7
        - 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 = 2
        - agno = 5
        - agno = 3
        - agno = 7
        - agno = 4
        - agno = 6
entry "Succession.S03E05.mp4" at block 0 offset 352 in directory inode 8589934728 references free inode 8589934733
	would clear inode number in entry at offset 352...
entry "Succession.S03E06.mp4" at block 0 offset 416 in directory inode 8589934728 references free inode 8589934734
	would clear inode number in entry at offset 416...
bad nblocks 43807 for inode 12884902050, would reset to 21279
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
        - traversing filesystem ...
entry "Succession.S03E05.mp4" in directory inode 8589934728 points to free inode 8589934733, would junk entry
entry "Succession.S03E06.mp4" in directory inode 8589934728 points to free inode 8589934734, would junk entry
bad hash table for directory inode 8589934728 (no data entry): would rebuild
would rebuild directory inode 8589934728
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
Maximum metadata LSN (7:2202465) is ahead of log (7:2201629).
Would format log to cycle 10.
No modify flag set, skipping filesystem flush and exiting.

 

 

sidekick-diagnostics-20230114-2224.zip

Edited by Barb
Attach Diagnostic
Link to comment
Barb Noob

Barb

Posted
  • Author
Posted

I made such a silly mistake. I went back to perform a check and the autocomplete shows I typed -Ln instead of -Lv. I ran the check correctly this time, started the array, and all my data is back.

 

Thank you for looking into this. I swear I spent a while researching what I needed to do beforehand and a silly typo derailed everything.

 

 

 

 

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.

×
Go to topic listing
×
×
  • Create New...