Vynce Posted January 14, 2016 Share Posted January 14, 2016 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 Link to comment
JorgeB Posted January 14, 2016 Share Posted January 14, 2016 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. Link to comment
itimpi Posted January 14, 2016 Share Posted January 14, 2016 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. Link to comment
JorgeB Posted January 14, 2016 Share Posted January 14, 2016 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. Link to comment
itimpi Posted January 14, 2016 Share Posted January 14, 2016 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! Link to comment
JorgeB Posted January 14, 2016 Share Posted January 14, 2016 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 Link to comment
Vynce Posted January 14, 2016 Author Share Posted January 14, 2016 Thanks guys! Back up and running again Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.