Device IDs changed suddenly

[Mh0]

I went out of town and came back to find one of my disks was in an error state. I took a diagnostic log at this stage, but I couldn't tell why the disk failed from the log (attached).

 

I thought the system needed to go through a "data shuffle dance" (Stop/Unassign/Start-in-Maintenance-Mode/Stop/Re-assign/Start) - but to my surprise, I found the disk/device IDs had changed on me, in the form of the very last "suffix" - screenshot of the ID change below:

 

 

I have two questions:

a. Why did this suffix change?

b. What can I do now to re-start the array? Is there a way to solemnly promise to unraid that these are the exact same devices inspite of this (involuntary) name change that I didn't even trigger?

 

I have a strong suspicion/hope that a reboot may set that last :suffix back to it's original value, but I don't want to do that yet, as I'd rather understand why this happened first, as well as because I don't want to lose any possible diagnostic logs that may still exist on the system.

 

Note: The drives are attached via a media-sonic bay over a USB connection - is it possible the system is randomly attributing these suffixes to devices in the bay?

 

maadi-diagnostics-20240908-1748.zip

[JorgeB]

7 hours ago, Mh0 said:

Why did this suffix change?

Are you using USB?

[Mh0]

Yes I am indeed! Does that cause this sort of behaviour?

[JorgeB]

Yep, one of the reasons we don't recommend USB, you can do a new config to correct the issue, but it may happen again.

[Mh0]

Just to be sure, New Config does not necessarily imply the data will be wiped? "New Config" can be expected to expose the data already on the devices being used, right?

[JorgeB]

38 minutes ago, Mh0 said:

Just to be sure, New Config does not necessarily imply the data will be wiped?

Correct, it just resets the assignments, as long as you assign the devices as they were before the existing data will be kept.

[Mh0]

So I tried to do this, and was greeted with an unpleasant surprise, my main media drive (Disk 1) is being reported as "unmountable". What is the recommended procedure for recovery here - given that there is almost nothing else on the other two disks?

a. Should I wait for the parity to build, or is that pointless now?

b. What recovery avenues should I pursue? 

c. Is there a recovery path from within unraid, or should I mount the disk on an external Linux OS and try to search for xfs salvaging tools?

 

Edited September 11, 2024 by Mh0

[itimpi]

You should follow the process for handling unmountable drives as documented here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.  In addition every forum page has a DOCS link at the top and a Documentation link at the bottom.

 

You may get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread.  It is always a good idea to do this to allow us to see the current state of your system and so we can see logs.

[JorgeB]

4 hours ago, Mh0 said:

my main media drive (Disk 1) is being reported as "unmountable"

Are you sure you didn't swap disk1 with parity? They both show the same serial because of USB, so you need to be extra careful when assigning them

[Mh0]

That's an excellent question - I will double check and confirm. If I had done that, then of course the data on the media would now be toast of course.

 

BTW, I have one more follow up on the counsel against using UnRAID with USB - given that I did not know this (or at least it was not abundantly clear to me when I started getting in to unraid) - does the same counsel hold against the following connections:

 

* eSATA? (Already supported by my existing bay)

* USB-C? (Asking for my education)

* Thunderbolt? (Asking for my education)

 

[itimpi]

eSata is the same as SATA just with a slightly different connector.

 

regarding the other two I suspect it will (like with USB) be dependent on the enclosure used and how the drives are presented to the host.