kahunamike Posted August 8, 2023 Share Posted August 8, 2023 I recently found one of my drives as "Unmountable: Unsupported or no file system". From directions in the forums, I ran: "xfs_repair -v /dev/sdd" from the console It gave me the error: "Sorry, could not find valid secondary superblock Exiting now." The drive still is unmountable. Any other ideas on bringing this drive back? I see instructions on looking for a lost+found folder but I don't see that anywhere. The drive never appears in Unassigned Devices with the array stopped or in maintenance mode. With the array started, I don't see the folder in /mnt/user Quote Link to comment
JorgeB Posted August 8, 2023 Share Posted August 8, 2023 26 minutes ago, kahunamike said: "xfs_repair -v /dev/sdd" from the console That's not the correct command, see check filesystem and use the WebGUI (without -n) Quote Link to comment
Solution kahunamike Posted August 8, 2023 Author Solution Share Posted August 8, 2023 Thanks @JorgeB. I'm getting this. Maybe because I ran the above already? Should I go ahead and run it with "-L"? Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... 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. Quote Link to comment
JorgeB Posted August 8, 2023 Share Posted August 8, 2023 3 minutes ago, kahunamike said: Should I go ahead and run it with "-L"? Yep. Quote Link to comment
kahunamike Posted August 8, 2023 Author Share Posted August 8, 2023 Not sure if this is good or bad.... Is it just try to start the array normally now? 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 destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata sb_fdblocks 488961967, counted 490185727 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 inode 5221924220 - bad extent starting block number 4503567550832887, offset 0 correcting nextents for inode 5221924220 bad data fork in inode 5221924220 cleared inode 5221924220 - agno = 3 - agno = 4 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 1 - agno = 4 - agno = 2 entry "IMG_2660.JPG" at block 1 offset 3136 in directory inode 5221034101 references free inode 5221924220 clearing inode number in entry at offset 3136... Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... bad hash table for directory inode 5221034101 (no data entry): rebuilding rebuilding directory inode 5221034101 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (39:3996936) is ahead of log (1:2). Format log to cycle 42. done Quote Link to comment
JorgeB Posted August 8, 2023 Share Posted August 8, 2023 10 minutes ago, kahunamike said: Is it just try to start the array normally now? Yes, disk should mount now, then look for a lost+found folder. Quote Link to comment
kahunamike Posted August 8, 2023 Author Share Posted August 8, 2023 Yay! Mounted successfully. The lost+found folder would be in the root of the drive right? In my case: /mnt/disk1? If so, I don't see any lost+found folder in there. Quote Link to comment
JorgeB Posted August 8, 2023 Share Posted August 8, 2023 9 minutes ago, kahunamike said: The lost+found folder would be in the root of the drive right? Correct. 9 minutes ago, kahunamike said: If so, I don't see any lost+found folder in there. That's a good sign, all data should be intact. Quote Link to comment
kahunamike Posted August 8, 2023 Author Share Posted August 8, 2023 Thanks so much @JorgeB! Was worried I'd have to restore from backup. Have a great rest of your day! 1 Quote Link to comment
Unraider1 Posted March 21 Share Posted March 21 I had the same issue. JorgeB's instructions worked! Saved me from having to do a restore from backup! 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.