Long story short, the power went out a few days ago when I was out of town and I've been putting out fires. The latest discovery was that most of the content on one of my disks is missing. I ran a SMART test that came back clean and ran an xfs_repair test that very much did not. Hundreds of errors. And I don't really know how to read that report properly, despite trying to decipher it with the wiki open on another monitor. I'm gonna guess this pretty much sums it up:

bad magic number

bad on-disk superblock 4 - bad magic number

primary/secondary superblock 4 conflict - AG superblock geometry info conflicts with filesystem geometry

would zero unused portion of secondary superblock (AG #4)

would reset bad sb for ag 4

bad uncorrected agheader 4, skipping ag...

sb_icount 19968, counted 11520

sb_ifree 5257, counted 5218

sb_fdblocks 469533046, counted 462796299

As I scroll through the log, it "would junk" a whole lot of entries. And a bunch more would end up in "lost+found".

So with this in mind, I think I am supposed to run the check with a -v instead of a -n tag? But would it be easier to just run a parity rebuild on the disk, since this is the only one with problems at the moment? And how would I run a parity rebuild on a disk that is historically already in the array?

4 hours ago, ucrbuffalo said:

But would it be easier to just run a parity rebuild on the disk, since this is the only one with problems at the moment?

Parity is calculated in real time, so if you rebuild, the rebuild disk will have the same corruption it already has.  Run the repair.

Ok, am I correct in thinking that the flag just needs to change from -n to -v, then I can use the “Check” box in the GUI? Or should I use the terminal instead? 

You can use the GUI, without -n or with -v will work.

Might also require -L if asked.