Barb Posted January 15, 2023 Share Posted January 15, 2023 (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 January 15, 2023 by Barb Attach Diagnostic Quote Link to comment
Solution itimpi Posted January 15, 2023 Solution Share Posted January 15, 2023 The last set of output says it also had the -n option set although you said you only used -Lv. Until you run without the -n (no modify) option set nothing will be repaired. The diagnostics posted seem to agree in that they show there is still corruption on disk1. Quote Link to comment
Barb Posted January 15, 2023 Author Share Posted January 15, 2023 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. Quote Link to comment
Recommended Posts
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.