Missing/corrupt super.dat and failed disk

[Vynce]

• Running unRaid 6.1.6
  
• 6 disks total: 2TB parity, a couple more 2TB data drives, a couple of 500GB data drives, and a cache/app/docker drive.
  
• Some write failures occurred on disk1 (2TB), so unraid took it offline/redballed the drive.
  
• I bought a 4TB replacement and started preclearing it.
  
• Some data was written to the emulated disk1 after it was taken offline. Data was also written to disk2.
  
• At some point the USB flash drive glitched and became unmounted (I may have bumped it). Lots of FAT read errors like these in the syslog:
  

FAT-fs (sda): Directory bread(block 520) failed
FAT-fs (sda): Directory bread(block 521) failed
FAT-fs (sda): Directory bread(block 522) failed
FAT-fs (sda): Directory bread(block 523) failed
FAT-fs (sda): Directory bread(block 524) failed
FAT-fs (sda): Directory bread(block 525) failed
FAT-fs (sda): Directory bread(block 526) failed

• I rebooted the server and it came up without any assigned disks. super.dat is 0 bytes. There are super.old and super.prev files, but their last modification times are back in 2013. unRaid thinks it's creating an initial configuration. The syslog concurs:
  

md: unRAID driver 2.5.3 installed
md: could not read superblock from /boot/config/super.dat
md: initializing superblock
mdcmd (1): import 0 0,0
mdcmd (2): import 1 0,0
mdcmd (3): import 2 0,0
mdcmd (4): import 3 0,0
mdcmd (5): import 4 0,0

• I've reassigned all the disks to their previous slots. I think the parity disk is assigned correctly, but I'm not 100% sure. Is there an easy way to tell which disk doesn't have a filesystem?
  

 

I don't think I want to start the array now, because it looks like that's going to rebuild parity based on the incomplete contents of disk1. Telling it to trust parity doesn't seem quite right either since it's also going to trust the contents of disk1 (which it shouldn't). How do I tell unraid that disk1 is bad and should be rebuilt (preferably onto the new drive)?

 

Current syslog is attached. I was also able to save off all the dmesg output from my terminal that shows the flash drive errors before I rebooted. I can attach that as well if it could be helpful.

syslog.txt

[JorgeB]

Check “Parity is already valid” option next to the start button and start the array, now check if there is any unmountable disk, if there is you selected the wrong parity, if all looks good, stop array, unassign disk1, start array, you are now as you were before the usb drive failure.

 

You can now replace disk1, but from what you wrote you have a new 4tb disk but your parity is 2tb, in this case you have to do the parity swap procedure, proceed from step 4.

 

[itimpi]

If you are not sure which drive is parity then assign ALL disks as data disks.  Once you have identified the parity disk for certain (the one which is flagged as unmountable) then start again with Tools->New Config and this time assign the disks correctly.  You do not want to accidentally assign a data disk as parity as it will wipe the contents when the array is started.  The order of data disks is not critical, but getting the parity disk right is.

[JorgeB]

If he believes the parity is correct he can start the array, as long the “parity is already valid” option is checked, if there is an unmountable disk wrong parity was selected, stop array and select that one as parity, again “check parity is already valid” before starting array.

[itimpi]

If he believes the parity is correct he can start the array, as long the “parity is already valid” option is checked, if there is an unmountable disk wrong parity was selected, stop array and select that one as parity, again “check parity is already valid” before starting array.

True - but I guess I am used to the fact that if not on the latest release a parity sync is automatically started when the array starts thus potentially destroying the contents of a data disk.  I feel it is better to be safe than sorry!

[JorgeB]

If he believes the parity is correct he can start the array, as long the “parity is already valid” option is checked, if there is an unmountable disk wrong parity was selected, stop array and select that one as parity, again “check parity is already valid” before starting array.

True - but I guess I am used to the fact that if not on the latest release a parity sync is automatically started when the array starts thus potentially destroying the contents of a data disk.  I feel it is better to be safe than sorry!

 

I'm going from his post, but you're right, better safe than sorry.

 

 

• Running unRaid 6.1.6

[Vynce]

Thanks guys! Back up and running again