I have a problem trying to replace a broken HDD in my array, given a quirk in my bay configuration - here are the details:

• My array is configured using a 4 slot disk bay.
• I made a mistake of configuring the array with slot #2 in "disabled" mode initially, as it happened to be empty at the time.
• now that I am trying to re-enable it, Unraid is telling me that that the disk in slot #3 is "wrong" - possibly because it's ID has changed now that slot enabling slot #2 has taken it's place.

 

Given that my system is already emulating one of it's disks that has failed, is there anyway I can ask Unraid to continue correctly identifying the disk in slot #3 even after I have enabled slot #2?

Unraid doesn't care (or know) which bay a disk is in. It tracks disk assignments by disk serial number. 

 

Attach Diagnostics to your NEXT post in this thread so we can get a better understanding of your situation. 

Updates:

• Since the post above, I managed to get over the initial problem with an emulated disk somehow
• The system was green momentarily, before I re-enabled slot 2 in the bay again
• Curiously now it is reporting that the disk in Slot #1 is Disabled.

After getting in to this error state again - I did the following:

• Enabled the disabled slot in my Mediasonic bay (4 Bay Dock for 2.5" / 3.5" SATA HDD / SSD - USB 3.0 & eSATA) - just by pressing the slot's on/off button
• Booted the system afresh
• Re-configured the disks in the exact right configuration they were in the last time it was all green:
  • Parity    ST16000N_E000-3UN101_152D00539000-0:0 - 16 TB (sdb)
  • Disk 1    ST16000N_E000-3UN101_152D00539000-0:2 - 16 TB (sdd)
  • Disk 2    Hitachi_HDS721010CLA632_152D00539000-0:1 - 1 TB (sdc)
  • Disk 3    SSD512GBS800_9806A234501707 - 512 GB (sdf)
• It refused to start in this condition because "Too many disks in wrong or missing state"
• I captured a diagnostic bundle: 20240727-1339
• I disabled the slot in the bay that includes a disk that is not even part of the config listed above, and waited for the disks to get recognized.
• I then found out that I could start the disk array again - in the exact same configuration above
• After starting it, I captured this diag bundle: 20240727-1342

My problems are the following:

• I don't know why disabling slot 2 in the bay has this effect on starting the array. Why does UnRAID care about an additional disk that appears if it I am not asking for it to be part of the array config? Why doesn't it allow the array to start with the SAME disk layout that it allows later when slot #2 is disabled? I would love to be able to resolve this mystery.
• Invariably when I do this, the system state is corrupted, and I end up having to re-build parity for a disk - which takes ~25 hours or so, except...
• ... Right now, I don't even have the option to re-build parity as it tells me that Disk 1 is "Disabled, Content emulated", and spinning it up doesn't seem to fix the issue.

I hope the diag bundle submission is proper (I assumed that attaching to this, next post in this very thread is the right thing to do)

CrazyMediaSonicBay-diagnostics-20240727-1342.zip CrazyMediaSonicBay-diagnostics-20240727-1339.zip

USB not recommended for assigned disks for many reasons. Probably this is the main source of your problems, since USB may disconnect, which causes the disk to become out-of-sync, and so disabled until rebuilt.

 

Also, SSDs in the array cannot be trimmed, and can only be written at parity speed. Better to assign those to cache or some other pool outside the array.

 

The diagnostics were taken without the array started. so no disks are mounted. Don't know if any are unmountable..

 

You can't change disk assignments however you want, parity is in sync with the assignments it was built with and you can't change them without New Config/Rebuild parity.

 

Probably the way forward is going to be New Config to assign disks as they should be, then let it rebuild parity. Then if there are any unmountable disks, try to repair the filesystem.

 

But you are likely to continue to have problems due to USB connections.

 

 

 

 

You have explained many things to me - thank you! Including:
* That I can't change disk positions at will, and
* I will eventually take the SSD out of this array (that was clearly a mistake).

For the record though, I typically do not have issues with USB disconnections - just when I switch the slot on the bay on/off - for example - here is the very same Hitachi HDD showing up with a different ID when I had changed its slot on the bay. Why is it being identified with a different id? Is this an artifact of the bay changing the disk id or something else?

 

 

Also are you saying that using a disk bay is okay, just connect it via an eSATA port instead of USB?

 

Lastly, if I need to rebuild this config, can I take a back up of the stuff that was on it from the individual volumes (since I can't easily get the array back up in it's original config again)?

 

Thanks!

Update: I couldn't restore the drive to healthy state given that the drive was reported as "disabled" - until I learned that I have to:
a/ stop the array b/ unassign the disk c/ start the array in maintenance mode d/ stop the array again e/ re-assign previous drive to same slot as before, and finally f/ start the array again - it is now re-building data on the re-enabled drive.

After this is done, I hope I can back it up, then reconfigure from scratch.

21 hours ago, Mh0 said:

For the record though, I typically do not have issues with USB disconnections - just when I switch the slot on the bay on/off - for example - here is the very same Hitachi HDD showing up with a different ID when I had changed its slot on the bay. Why is it being identified with a different id? Is this an artifact of the bay changing the disk id or something else?

This is common problem when using multiple bay USB enclosure, ID will change if disk have change.

 

A correct and simple procedure to refresh the ID is new config and mark parity valid. If you need rebuild disk ( still have valid parity and remain data disk), you need manual invalid the target rebuild disk.

 

*BUT* after all previous operation, this is in question does your parity still valid.

 

 

Edited July 28, 20241 yr by Vr2Io