DigPunk Posted July 1 Share Posted July 1 Disk 1 in my array has been working great. It's a data disk (not parity) formatted as xfs. Got this Unmountable Disk Present error- so I checked the cables, and rebooted. Turned on Maintenance mode, and ran the xfs_repair with the -n option. Here's the results... 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_ifree 148, counted 140 sb_fdblocks 518221300, counted 519531190 - 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 - 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 = 3 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. Not sure what all this means or where to go from here. This is critical data and I need to salvage it- any suggestions? Thank you! Quote Link to comment
JorgeB Posted July 1 Share Posted July 1 Run it again without -n, and if it asks for it use -L Quote Link to comment
DigPunk Posted July 1 Author Share Posted July 1 Here's the results without -n 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. I started the array in normal mode (unchecked maintenance), but still says unmountable. Are there any other options before running the -L option? I don't want to risk corrupting this without exhausting all options first. Thank you for your help! Quote Link to comment
itimpi Posted July 1 Share Posted July 1 You need to use the -L option since mount is failing if you want any repair to happen. It will not corrupt data. The very worst is that the last file update to the drive gets discarded and even that rarely happens. After doing that when the array is restarted in normal mode it should mount. Quote Link to comment
DigPunk Posted July 1 Author Share Posted July 1 OK- just so I'm clear... I run the -L option in MAINTENANCE MODE? or NORMAL mode? Thank you soo much, I really appreciate the help! Quote Link to comment
Solution itimpi Posted July 1 Solution Share Posted July 1 Just now, DigPunk said: OK- just so I'm clear... I run the -L option in MAINTENANCE MODE? or NORMAL mode? Thank you soo much, I really appreciate the help! Assuming you are running from the GUI (which is strongly recommended) Unraid will only let you run xfs_repair in Maintenance mode. Quote Link to comment
DigPunk Posted July 1 Author Share Posted July 1 OK, going for it... wish me luck! Thank you! Quote Link to comment
DigPunk Posted July 1 Author Share Posted July 1 Here's the results of the -L option. Looks like it worked! Drive is now mounted and all shares/data are present. I'm going to run an immediate off site backup- but- anything else I can/should do to prevent future problems or failures? THANK YOU SOO MUCH FOR YOUR HELP!!! Soo happy I didn't lose the data! 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_ifree 148, counted 140 sb_fdblocks 518221300, counted 519531190 - 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 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 2 - agno = 3 - agno = 1 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (1:2993012) is ahead of log (1:2). Format log to cycle 4. done 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.