Hardware:

• Motherboard: Gigabyte B550 AORUS ELITE AX

• CPU: AMD Ryzen 3600

• HBA: LSI SAS3224 (Broadcom 9305-24i) — 24 ports SAS/SATA

• Additional SATA controller: ASMedia ASM1064 (Moonqkuses PCIe card) — 4 ports

• Onboard SATA: AMD B550 chipset — 4 ports

• Boot: USB flash drive

• Unraid version: 7.2.4

• Array: 30 disks total, dual parity
  

Disk layout:

• Parity 1 & 2: 2x 20TB Seagate

• Disk 1-26: mix of 10TB and 18-20TB drives on LSI HBA and ASMedia card

• Disk 27-28: 2x 20TB WD (newly added)

• Disk 12: ST10000VN0004-2GS11L * (sdac) — 10TB on LSI HBA phy21

• Disk 13: ST10000VN0004-2GS11L * (sdae) — 10TB on LSI HBA phy23
  

What happened: I had a working 28-disk array. I added 2 new WD 20TB drives (disk 27 and 28). I stopped the array, physically connected the 2 new drives, and rebooted. After reboot, disk 12 and 13 appeared with red X (disabled). I checked cables, rebooted again, but the problem persisted.

What I tried:

• Verified SMART on both disks: PASSED, no errors, 0 reallocated sectors

• Confirmed XFS data is intact: mount -t xfs -o ro /dev/sdac1 /mnt/tmp shows data correctly

• Checked dmesg — disks are detected correctly by kernel on sdac/sdae

• Tried New Config with Preserve All assignments — did not fix the issue
  

Key finding in dmesg: Healthy disks import like this:

md: import disk1: (sdu) ST18000NM000J-2TV103_* size: 17578328012

Disk 12 and 13 import with a trailing 0 flag:

md: import disk12: (sdac) ST10000VN0004-2GS11L_* size: 9766436812 0
md: import disk13: (sdae) ST10000VN0004-2GS11L_* size: 9766436812 0

This trailing 0 causes them to be marked DISK_DSBL immediately.

Current state:

• rdevStatus.12=DISK_DSBL

• rdevStatus.13=DISK_DSBL

• sbSyncErrs=0 — parity is valid

• sbSyncExit=0

• XFS data readable directly on physical devices
  

Question: What does the trailing 0 flag mean in the md import line, and how can I clear it to allow these disks to rejoin the array without rebuilding from parity?

sphinx-diagnostics-20260410-2159.zip

Edited June 1Jun 1 by Arturia

I don't see a new config on the diags, or the disks getting disabled; they were already disabled at aboot.

Start the array in normal mode, not maintenance mode, and post new diags.

7 minutes ago, JorgeB said:

don't see a new config

Probably clicked DONE instead of APPLY.

Common mistake, maybe the DONE button on that page should say CANCEL instead.

Thanks for the reply. The disks were working fine before tonight — they got disabled after I added 2 new drives which caused a SATA enumeration issue (devices shifted from sdac/sdae to other letters).

sphinx-diagnostics-20260410-2342.zip

Started array in normal mode, new diagnostics attached.

Additional info: while in maintenance mode, I ran filesystem check and fix on both disk 12 and 13 via the WebGUI. Both disks now show "filesystem OK" after the fix.

sphinx-diagnostics-20260411-0004.zip

4 hours ago, Arturia said:

they got disabled after I added 2 new drives which caused a SATA enumeration issue (devices shifted from sdac/sdae to other letters).

Do you mean you plugged in the new disks while the array was started?

No, array was stopped before adding the drives. The problem was enumeration shifting when starting the array: after adding the 2 new drives, every time I started the array, disk 12 and 13 shifted from sdac/sdae to sdag/sdaf. This happened consistently on array start, not on reboot. I tried recabling 3 times with different SATA ports. Eventually the enumeration stabilized with the current cabling and sdac/sdae are now stable and pointing to the correct disks by serial number. But disk 12 and 13 remain DISK_DSBL despite diskState=4.

Disk ID should never change on array start, unless the disks are dropping and reconnecting.

Both emulated disks are mounting and showing a lot of data. Assuming the contents look correct, start rebuilding both and post new diags if there are any errors during the rebuild:

https://docs.unraid.net/unraid-os/using-unraid-to/manage-storage/array/replacing-disks-in-array/#re-enabling-a-disabled-disk-rebuilding-onto-itself

Thank you. Before proceeding with the rebuild, I want to flag a discrepancy I noticed:

When I mount the physical disks directly (array stopped):

• /dev/sdac1 shows tv/P/ tv/Q/ tv/R/ (correct structure)

• /dev/sdae1 shows tv/P/ tv/Q/ tv/R/ (correct structure)

When I start the array and check the emulated content:

• /mnt/disk12 shows P/ Q/ R/ directly at root (missing the tv/ parent folder)

• /mnt/disk13 shows P/ Q/ R/ directly at root (missing the tv/ parent folder)

The emulated content does not match the physical content. I ran xfs_repair on disk 13 which had reinitializing root directory and inodes moved to lost+found.

I am currently backing up both physical disks before proceeding. Should I still rebuild, or is there a way to sync parity from the physical disks instead?

If the emulated disks are not showing the expected content, and since SMART looks OK for both, it may be better to do a new config and resync parity instead of rebuilding.

Tools - New Config - Keep all - Apply

Then on Main confirm all assignments look good, and if yes check "parity is already valid", start the array and run a parity check, a few syn errors are expected.

Thanks Jorge. Following your advice, we'll do the New Config + resync parity approach.

Before proceeding, I'm currently doing a precautionary backup of both disk 12 and disk 13 to external drives (rsync in progress, ~10-12h remaining). This is because the emulated content (P/Q/R/ at root) doesn't match the physical content (tv/P/Q/R/), so I want a safety net before any config changes.

Once the backup is complete I'll proceed with:

1. New Config - Keep All - Apply

2. Verify all assignments

3. Check "parity is already valid"

4. Start array + run parity check

Will post new diags if any issues arise. Thank you.

Hi Jorge,

Update: backup is done and I followed the steps as planned.

• New Config - Keep All - Apply ✓

• Verified all assignments ✓

• Checked "parity is already valid" ✓

• Started array ✓

• Parity check running

Results so far:

• Disk 12 and 13 are back online, no longer DISK_DSBL ✓

• Data on both disks looks correct (tv/ folder structure intact) ✓

• 74 sync errors corrected so far, estimated finish in ~2 days 9 hours at ~97 MB/s

Assuming this is expected behavior, I'll let the parity check complete. Please let me know if the error count looks concerning or if there's anything else to watch out for.

Thanks again for your help, really appreciated!

7 hours ago, Arturia said:

Assuming this is expected behavior,

That looks good and expected, any read or write errors during the parity sync post the diagnostics before rebooting.

Hi Jorge,

Current parity check status:

• Position: 3081 GB (15.4%)

• Speed: 106.6 MB/s

• Sync errors corrected: 412

• Estimated finish: ~1 day 20 hours

• No read or write errors so far

One concern: I have a planned power outage coming up. Is it safe to pause the parity check, shut down properly, and resume after power is restored? Will Unraid pick up where it left off or restart from the beginning?

Thanks again!

It's safe to cancel and power down, but you will need to restart the check from the beginning.

I believe the party check tuning plugin allows you to resume a check after a reboot.

This Option ?

Yep

Hi Jorge,

Parity check completed with 528,049 sync errors corrected. Is that number concerning or still within acceptable range given the situation we had with disk 12 and 13?

A few follow-up questions:

1. Should I run another parity check now to confirm everything is clean, or is one pass sufficient?

2. Would you recommend periodically running XFS filesystem checks on the array disks via maintenance mode? If so, how often?

3. Regarding your comment "Disk ID should never change on array start, unless the disks are dropping and reconnecting" — do you have any insight into what actually happened in my case? The disks were on an LSI SAS3224 HBA and their device names shifted on array start (not on reboot). Could this indicate a hardware issue with the HBA or cabling, or is it more likely related to the 3 storage controllers I have (LSI HBA + ASMedia ASM1064 + AMD B550 onboard)?

Thanks again for all your help throughout this!

2 hours ago, Arturia said:

Is that number concerning or still within acceptable range given the situation we had with disk 12 and 13?

I say it's within expectations. You can run another check in a few days to confirm errors.

2 hours ago, Arturia said:

Would you recommend periodically running XFS filesystem checks on the array disks via maintenance mode? If so, how often?

Not unless there are any issues detected or an unclean shutdown

2 hours ago, Arturia said:

do you have any insight into what actually happened in my case? The disks were on an LSI SAS3224 HBA and their device names shifted on array start (not on reboot).

Most likely the disks dropped offline and then reconnected with another identifier. This is typically a power/connection issue; if it happens again, grab the diags before rebooting

Thank you for the clarification!

I'll run another parity check in a few days to confirm everything is clean.

Regarding the disk dropout — I'll check the SAS cables on the HBA ports for disk 12 and 13. Good to know about grabbing diags before rebooting if it happens again.

Thanks again for all your support, this community is great!

Update — June 1st, same issue recurring

Disk 12 and 13 disabled again tonight with no changes made to the system since the last fix.

Syslog shows clear physical SAS link dropouts this time:

mpt3sas_cm0: mpt3sas_transport_port_remove: removed: sas_addr(0x300062b202991677)  [phy23 / disk13]
mpt3sas_cm0: mpt3sas_transport_port_remove: removed: sas_addr(0x300062b202991675)  [phy21 / disk12]

Both disks show Power-on or device reset occurred immediately after removal. Disk 12 (phy21) attempted 3 reconnections in a loop before being disabled. log_info(0x31110d00) reported on each event.

Both affected PHYs (21 and 23) are on the same LSI 9305-24i HBA. The NAS has not been moved or physically touched since the last incident.

Given that the dropouts are clearly at the SAS/PHY layer, what would you recommend as next steps? Should I replace the SAS breakout cable serving these ports, suspect the HBA itself, or could the disks be the cause despite clean SMART data?
New diagnostics attached.

sphinx-diagnostics-20260601-0641.zip

Edited June 1Jun 1 by Arturia

I would start by replacing the miniSAS cablw, since it's the cheaper option.

Thanks Jorge!

I've already ordered a replacement SAS cable (SFF-8643 to 4x SATA, 1m), should arrive in a few days.

In the meantime, to get disk 12 and 13 back online, should I proceed with a New Config + Keep All like last time, or something else ?

If no data was written to the emulated disks, i.e., after they got disabled, you can do a new config, check parity is already valid, and then run a correcting parity check.