September 2, 20178 yr I had a failed drive and just bought another drive and let the array rebuild onto it. after rebooting, unraid claims the new drive is the wrong drive, even though its not. To make matters worse, another drive has since failed. Is there someway I can force it to recognize this new drive so I can deal with the new failed drive?
September 2, 20178 yr The disk has a different identifier, is it connect on a different controller? What controller are you using?
September 2, 20178 yr Author I know.. i dont know where that XCB0 came from. I don't remember if it was there or not before. I didn't change anything other than reboot. I don't remember what the controllers are, i'll see if i can find out
September 2, 20178 yr Author SUPERMICRO AOC-SASLP-MV8 are the controllers SUPERMICRO MBD-X10SAE-O is the motherboard
September 2, 20178 yr Strange, SASLP usually has no such issue, power down and try connecting that disk on the onboard controller
September 2, 20178 yr Author i powered down and moved the drive to a different bay, we'll see what happens
September 2, 20178 yr Author power off reset worked. array starts but now I get a Structure needs cleaning message when i try to access the files
September 2, 20178 yr 1 hour ago, jhanda said: i started xfs_repair on it, hopefully thats ok Yes, disk13 has fs corruption.
September 3, 20178 yr Author Phase 1 - find and verify superblock... couldn't verify primary superblock - not enough secondary superblocks with matching geometry !!! attempting to find secondary superblock... ......... Exiting now.
September 3, 20178 yr Probably you didn't run the correct command, with the array in maintenance mode type: xfs_repair -v /dev/md13
September 3, 20178 yr Author i did it in the gui put -v for the options i'll do command line again.. it took all night to run
September 3, 20178 yr Author running again.. seems to be doing the same thing, just searching for secondary superblocks
September 3, 20178 yr Then the problem is more serious, abort xfs_repair, start the array in normal mode and grab new diags.
September 3, 20178 yr Are you running xfs_repair on disk13 or the failed and unmountable disk4? PS: Disk1 needs a new SATA cable. There are also ATA errors for other disks, this could be the disk, cable or controller, SASLP has known issues with unRAID v6. There are a lot of call traces, apparently related to the SASLP Very difficult to solve problems with so many different issues.
September 3, 20178 yr Author xfs_repair on disk 13. disk 4 failed shortly after i rebuilt for the failed disk 13. I have a new drive on the way to replace 4 as well, but probably need to remedy this situation before attempting to rebuild 4?
September 3, 20178 yr 2 minutes ago, jhanda said: xfs_repair on disk 13. I find very odd that xfs_repair can't find the superblock in a filesystem that has issues but still mounts, first time I've ever seen this, can you access that disks data? It would also be best to get rid of both SASLP before trying anything else, if you don't have another controller at least disabe vt-d and update your board bios. 5 minutes ago, jhanda said: I have a new drive on the way to replace 4 as well, but probably need to remedy this situation before attempting to rebuild 4? You can do the rebuild anytime, but try to fix the filesystem first because there's no point in rebuilding if xfs_repair can't fix it.
September 3, 20178 yr Author some of it i can, some not.. most things say Structure needs cleaning I do not have any other controllers, which ones would be better?
September 4, 20178 yr 7 hours ago, jhanda said: which ones would be better? Any LSI SAS2008 based controller, e.g., 9201-8i, 9211-8i and clones (H310, M1015, etc)
Archived
This topic is now archived and is closed to further replies.