A couple weeks ago my UPS crapped out and dropped power to my server causing a hard shutdown. I've had a few problems since but the worst is a disk became corrupted. I was met with Unmountable: No file system on the gui.

I used 

xfs_repair -v /dev/md2

to attempt to repair the drive which seemed to work at first. Unfortunately when I restarted the server a couple days later I was met with the same message. Unmountable: No file system. This lead me to believe it was the disk itself that was the problem so I swapped it for a spare and let unraid rebuild it. Unfortunately after rebuild I'm met with  the Unmountable: No file system again. I tried the xfs_repair -v /dev/md2 again but this time I get the message:

xfs_repair -v /dev/md2
Phase 1 - find and verify superblock...
        - block cache size set to 2252344 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 59899 tail block 59890
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.

Help me see what I'm missing here. Did I just lose 8TB of data?

 

htpc-diagnostics-20200406-2010.zip

1 hour ago, thatnovaguy said:

Help me see what I'm missing here. Did I just lose 8TB of data?

hopefully not, SMART looks fine

1 hour ago, thatnovaguy said:

If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair.

JB ( ↓ ) is the resident expert on hardware, FS corruption, etc, below are a few threads where he's discussed how to handle this type of thing. I'm by no means an expert so do your due diligence but what I get from the first thread is that you should run xfs_repair without -n, and use -L if needed (you may end up with a lost and found of recovered files). Then verify that the emulated files are all intact before attempting to rebuild. Only rebuild to the same disk if you're positive the disk is good, which I believe it is.

 

The next post "XFS File System Corruption - Safest way to Fix?" talks about using UFSExplorer to recover data from formatted XFS disks if necessary, also the OP discusses repairing the corruption outside of unRaid in Fedora where the xfs_repair is native.

• also mentioned in the next post...

Quote

Though rare I've seen at least 3 or 4 cases where xfs_repair couldn't fix the filesystem, your filesystem looks very damaged, there's metadata corruption and the primary superblock is damaged also, xfs_repair has very few options and it's usually very simple to use, but when it fails there's really nothing a normal user can do, if you can't restore from backups IMO your best option would be the xfs mailing list, and possibly even if they can help you'll end up with a lot of corrupt/lost files.

The last thread is probably less relevant but discusses possible causes such as bad ram...

1 hour ago, thatnovaguy said:

This lead me to believe it was the disk itself that was the problem so I swapped it for a spare and let unraid rebuild it.

So you actually have the original disk intact, ultimately that could prove to be less corrupt make sure you don't clear it until this is all resolved.

8 hours ago, thatnovaguy said:

I tried the xfs_repair -v /dev/md2 again but this time I get the message:

Use -L

On 4/7/2020 at 4:41 AM, johnnie.black said:

Use -L

I think that did the trick but I'm afraid to hope. So is it safe to assume that if the data has restored properly on the new drive that the old drive is in fact going bad?

 

Also should I be worried that another disk seems to be gaining 10 or so reallocations every few days?

 

52 minutes ago, thatnovaguy said:

So is it safe to assume that if the data has restored properly on the new drive that the old drive is in fact going bad?

No, we'd need to see the diags from when the disk failed, or at lest its SMART report.

 

52 minutes ago, thatnovaguy said:

Also should I be worried that another disk seems to be gaining 10 or so reallocations every few days?

I would.