DigPunk

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

OK, going for it... wish me luck! Thank you!

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!

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!

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!