July 1, 20242 yr 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!
July 1, 20242 yr Author 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!
July 1, 20242 yr Community Expert 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.
July 1, 20242 yr Author 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!
July 1, 20242 yr Community Expert Solution 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.
July 1, 20242 yr Author 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
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.