Hi!
Was going to replace one of my drives that got a red X, but decided to update first. I guess the reboot didn't shutdown the system clean, so I went to start the array, and got unmountable on disk 5, while disk 1 is still emulated (still the old drive)

Unmountable: no filesystem

I followed part of SpaceinvaderOne’s video and ran xfs_repair with -v in maintenance mode and got this:

Phase 1 - find and verify superblock...
superblock read failed, offset 0, size 524288, ag 0, rval -1

fatal error -- Input/output error

I am running Unraid 7.2.4 and updated from 7.19 on a R5 2600. I do have one parity drive so I'm hoping I can at least fix and replace one and only lose a little bit of my data. Diag linked

theboysbox-diagnostics-20260411-1257.zip

13 hours ago, The Boys Box said:

fatal error -- Input/output error

This typically means an I/O error, and looking at SMART for disk5

197 Current_Pending_Sector -O---K 001 001 000 - 65535

Run an extended SMART test to confirm, but it looks like that disk, is a goner, which may mean some data loss since you already have another disabled disk with single parity.

9 hours ago, JorgeB said:

Run an extended SMART test to confirm, but it looks like that disk, is a goner, which may mean some data loss since you already have another disabled disk with single parity.

Exactly what I was afraid of, currently running an extended test on both Disk1 and Disk5, but a short test on Disk5 has already shown a read failure.

If Disk1 passes does that at least mean I can save that one? I did a short test on that one before and it passed it, I kinda thought on Disk1 it might have just been a bad sata cable.

Just now, The Boys Box said:

but a short test on Disk5 has already shown a read failure.

If this fails I would expect that it is almost certain the extended test will fail as well.

6 minutes ago, itimpi said:

If this fails I would expect that it is almost certain the extended test will fail as well.

That’s what I assumed as well. Disk1 passed the short test, if it passes the extended one, do you think it’ll be salvageable?

Yep, disk5 read failure. Here’s hoping disk1 is able to pass

13 hours ago, JorgeB said:

197 Current_Pending_Sector -O---K 001 001 000 - 65535

65535 is a suspicious number, the largest 16-bit number, might even represent -1 like if it decremented from zero.

On 4/11/2026 at 1:50 PM, The Boys Box said:

ran xfs_repair with -v

Did you do this from the webUI or the command line? Several ways to get the command line wrong.

2 hours ago, trurl said:

65535 is a suspicious number, the largest 16-bit number, might even represent -1 like if it decremented from zero.

Did you do this from the webUI or the command line? Several ways to get the command line wrong.

Since for some reason the webUI didn’t have the option thing that allowed for the modifier, I used command line. And the exact command I used was “xfs_repair -v /dev/md1p1” and the same thing for disk5.

Didn’t do -L since I read that I shouldn’t use that unless I was absolutely certain I was doing the right thing

1 hour ago, The Boys Box said:

“xfs_repair -v /dev/md1p1” and the same thing for disk5.

Didn’t do -L

That is the correct command for disk1 assuming you aren't using encryption. Did it ask you to do -L?

32 minutes ago, trurl said:

That is the correct command for disk1 assuming you aren't using encryption. Did it ask you to do -L?

Actually, not sure if I ran the command correctly at first, just did it again to get the exact message and it actually ran this time. This is what I got for Disk1

Phase 1 - find and verify superblock...
        - block cache size set to 1399136 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 0 tail block 0
        - scan filesystem freespace and inode maps...
        - 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
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - 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 = 5
        - agno = 4
        - agno = 3
        - agno = 7
        - agno = 9
        - agno = 10
        - agno = 8
        - agno = 6
        - agno = 2
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
Phase 5 - rebuild AG headers and trees...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem ...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - agno = 4
        - agno = 5
        - agno = 6
        - agno = 7
        - agno = 8
        - agno = 9
        - agno = 10
        - agno = 11
        - agno = 12
        - agno = 13
        - agno = 14
        - agno = 15
        - agno = 16
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...

        XFS_REPAIR Summary    Sun Apr 12 19:06:19 2026

Phase           Start           End             Duration
Phase 1:        04/12 19:05:13  04/12 19:05:14  1 second
Phase 2:        04/12 19:05:14  04/12 19:05:15  1 second
Phase 3:        04/12 19:05:15  04/12 19:05:49  34 seconds
Phase 4:        04/12 19:05:49  04/12 19:05:50  1 second
Phase 5:        04/12 19:05:50  04/12 19:05:52  2 seconds
Phase 6:        04/12 19:05:52  04/12 19:06:18  26 seconds
Phase 7:        04/12 19:06:18  04/12 19:06:18

Total run time: 1 minute, 5 seconds
done

Edited April 13Apr 13 by The Boys Box
To add more clarity for which disk I ran a command for

That doesn't look bad. What about disk5?

30 minutes ago, trurl said:

That doesn't look bad. What about disk5?

Still got the same input/output error

xfs_repair -v /dev/md5p1
Phase 1 - find and verify superblock...
superblock read failed, offset 2199023247360, size 131072, ag 2, rval -1

fatal error -- Input/output error

Edited April 13Apr 13 by The Boys Box

Xfs_repair cannot complete with an i/o error. My suggestion would be to try and clone that disk with ddrescue, then run xfs_repair on the clone.

If old disk1 has really failed and there are no backups, you can then also try to use the clone to rebuild disk1, but some data loss can still occur, mostly depending on how bad disk5 is.

You should check for lost+found folder at the top of disk1, to see what repair had to put there.

8 hours ago, JorgeB said:

Xfs_repair cannot complete with an i/o error. My suggestion would be to try and clone that disk with ddrescue, then run xfs_repair on the clone.

If old disk1 has really failed and there are no backups, you can then also try to use the clone to rebuild disk1, but some data loss can still occur, mostly depending on how bad disk5 is.

If disk1 does pass the SMART extended test, do you think it would be okay to try and rebuild using the old disk? Or should I just replace both? Also, if I can rebuild disk1, should I wait till I try and clone disk5 and do xfs_repair to rebuild both at the same time? Or can I just try it as soon as the smart test finishes if it passes.

There are several possible ways to proceed, depending on test results and other things we might do to get more information about possible ways to proceed. For example, what more can we learn about the contents of repaired emulated disk1? Can we find out anything about the contents of physical disk1? Maybe try different approaches and see which give best results.

Do you have backups of anything important and irreplaceable?

You can also try to rebuild disk1 with the current disk5 as is (unmountable), and depending on the amount of read errors, the rebuild may be mostly successful, and then replace only disk5, by cloning it, or rebuilding it. Cloning with ddrescue may recover a little more data since it is especially made to try and recover as much as possible from a disk with bad sectors.

3 minutes ago, JorgeB said:

You can also try to rebuild disk1 with the current disk5 as is (unmountable)

Since you were able to repair emulated disk1, that is exactly what rebuild would give you. But we don't know how successful that repair really was since we haven't seen your filesystems since that repair.

When you are ready, start the array in normal (not maintenance) mode with nothing assigned as disk1, and post new diagnostics.

1 minute ago, trurl said:

Since you were able to repair emulated disk1, that is exactly what rebuild would give you. But we don't know how successful that repair really was since we haven't seen your filesystems since that repair.

When you are ready, start the array in normal (not maintenance) mode with nothing assigned as disk1, and post new diagnostics.

Gotcha, just waiting for the smart test to finish (at 90%), then I’ll turn off maintenance mode, start it normally, then post the diagnostics

1 hour ago, trurl said:

Since you were able to repair emulated disk1, that is exactly what rebuild would give you. But we don't know how successful that repair really was since we haven't seen your filesystems since that repair.

When you are ready, start the array in normal (not maintenance) mode with nothing assigned as disk1, and post new diagnostics.

So the SMART test passed with no errors, when I get home I’ll post the new diagnostics! Thank you guys so much for all the help

4 hours ago, trurl said:

Since you were able to repair emulated disk1, that is exactly what rebuild would give you. But we don't know how successful that repair really was since we haven't seen your filesystems since that repair.

When you are ready, start the array in normal (not maintenance) mode with nothing assigned as disk1, and post new diagnostics.

Alright, here are the diagnostics with nothing assigned to disk1

theboysbox-diagnostics-20260413-1801.zip

Your drives are very full. Better if you don't let them get so full, xfs_repair needs some room to work in.

Emulated disk1 looks good (and full), and nothing in lost+found after the repair, so it should be OK to rebuild assuming no other problems. You do have other problems, disk5 seems to have failed. But disk5 is part of the emulation of disk1.

Not clear there is really anything wrong with physical disk1, though it does have perhaps the largest UDMA_CRC_Error_Count I have ever seen. These are connection problems, not disk problems. But how did you get so many? You should probably replace cables for that disk.

See if you can mount physical disk1 as an Unassigned Device. If it is OK, it might give another approach to recovering disk5.

12 hours ago, trurl said:

Your drives are very full. Better if you don't let them get so full, xfs_repair needs some room to work in.

Emulated disk1 looks good (and full), and nothing in lost+found after the repair, so it should be OK to rebuild assuming no other problems. You do have other problems, disk5 seems to have failed. But disk5 is part of the emulation of disk1.

Not clear there is really anything wrong with physical disk1, though it does have perhaps the largest UDMA_CRC_Error_Count I have ever seen. These are connection problems, not disk problems. But how did you get so many? You should probably replace cables for that disk.

See if you can mount physical disk1 as an Unassigned Device. If it is OK, it might give another approach to recovering disk5.

So I've actually wanted to replace the cables for a while now, unfortunately the server is at my friends house a couple hours away, I just manage it virtually. I'll definitely get him to replace those as soon as possible. And yeah I know we shouldn't keep the drives so full lol, we planned on buying a couple more drives when the prices of drives went down.

I mounted disk1 in unassigned devices and it worked fine!

How much do you think might have been written to your server, by users, dockers, mover, whatever, after disk1 became disabled?

3 minutes ago, trurl said:

How much do you think might have been written to your server, by users, dockers, mover, whatever, after disk1 became disabled?

Honestly, quite a bit. It's a media server mainly so it's constantly downloading new things through sonarr and such. I'm not too worried about losing that data though since it's literally just media that can be re-downloaded and it's all indexed on stuff like sonarr. I'm just trying to limit the amount that needs to be redownloaded since it would literally be terabytes of stuff.