Lohkay

Wow... badblocks takes SOOO much time to run its insane! It only did 1/8 of the drive and it's been more than 12hrs.. so far it found the same error that was stopping reiserfsck: bread: End of file, cannot read the block (488378373). Whenever it's gonna be done checking the disk (4 days maybe?), if there's nothing else than that, is there any way to fix it?

Humm... so I ran smartctl long test on disk 2 and it didn't report any errors, I ran reiserfsck on all disks and it didn't find any error with the exception of disk 2 which it just won't run on... it gives me: "bread: End of file, cannot read the block (488378373)." What does that mean? when mounted I can access files on the drive np..

Well that's the thing, it had been a few days I hadn't written anything. If anything was written, it may be winamp writing out some meta data which I don't give a rats ass about. I'll run reiserfsck on both disk and a full smart scan on disk 2.. see if anything's wrong.

Parity check complete with 0 errors. I've also looked at the files on Disk1 and everything seems OK! Thanks a lot everyone! Especially you Peter, you rock!

Alright, its on its way.. I'll post back when its done.

I was using 4.6 but due to some mishap, had to upgrade to 4.7 while doing those commands. Alright, so I did start it, was a bit scared when I saw writes to the parity and was unable to stop it (refreshing was giving me "Starting...." with only a refresh button available) but I assume that was due to me putting in a bigger drive than the failed one. So anyway, after a few mins, it started the parity check and from then on, only wrote to the new drive, reading from the others. It completed a few mins ago and now it says the parity is valid. So at this point, I think to make sure everything is really good, I should do a full parity check?

Good to know. They haven't responded yet. I'll let you all know as soon as they do.

Yea that's what I did after posting, hoping they respond.

Humm.. yea running the command again didn't return a response but it showed up in the log again. No disrespect towards you Peter, you've been very helpful, but what are the chances of a developper/support of lime tech chimming in on the subject? I know we're in the weekend but I don't mind waiting till tomorow/tuesday before trying to start it.

Alright, so far so good... I did the temp key thing to partition the new drive. Then I booted up with the real key. Made sure every drive was assigned correctly and then did the "initconfig" command in telnet. All drives went blue. I then did "mdcmd set invalidslot 1" but that command didn't output anything, the instructions say it should output: cmdOper=set cmdResult=ok But it didn't. Did it execute correctly? Anyway I can check? syslog maybe? Just want to make sure before I start the array. Here's whats in my syslog from the initconfig and invalidslot commands: Feb 12 14:03:40 Tower login[1660]: ROOT LOGIN on `pts/0' from `10.0.0.250' Feb 12 14:04:22 Tower emhttp: shcmd (24): modprobe -rw md-mod 2>&1 | logger Feb 12 14:04:22 Tower emhttp: shcmd (25): modprobe md-mod super=/boot/config/super.dat slots=8,32,8,16,8,0,8,48,8,64,3,64 2>&1 | logger Feb 12 14:04:22 Tower kernel: md: unRAID driver removed Feb 12 14:04:22 Tower kernel: xor: automatically using best checksumming function: pIII_sse Feb 12 14:04:22 Tower kernel: pIII_sse : 5518.800 MB/sec Feb 12 14:04:22 Tower kernel: xor: using function: pIII_sse (5518.800 MB/sec) Feb 12 14:04:22 Tower kernel: md: unRAID driver 1.1.1 installed Feb 12 14:04:22 Tower kernel: read_file: error 2 opening /boot/config/super.dat Feb 12 14:04:22 Tower kernel: md: could not read superblock from /boot/config/super.dat Feb 12 14:04:22 Tower kernel: md: initializing superblock Feb 12 14:04:22 Tower kernel: md: import disk0: [8,32] (sdc) WDC WD20EARS-00M WD-WMAZA0621109 size: 1953514552 Feb 12 14:04:22 Tower kernel: md: disk0 new disk Feb 12 14:04:22 Tower kernel: md: import disk1: [8,16] (sdb) WDC WD20EARX-00P WD-WCAZAD229351 size: 1953514552 Feb 12 14:04:22 Tower kernel: md: disk1 new disk Feb 12 14:04:22 Tower kernel: md: import disk2: [8,0] (sda) WDC WD20EARS-00M WD-WMAZA0723835 size: 1953513492 Feb 12 14:04:22 Tower kernel: md: disk2 new disk Feb 12 14:04:22 Tower kernel: md: import disk3: [8,48] (sdd) WDC WD10EADS-00M WD-WCAV50196695 size: 976762552 Feb 12 14:04:22 Tower kernel: md: disk3 new disk Feb 12 14:04:22 Tower kernel: md: import disk4: [8,64] (sde) ST31000340AS 9QJ0J93X size: 976762552 Feb 12 14:04:22 Tower kernel: md: disk4 new disk Feb 12 14:04:22 Tower kernel: md: import disk5: [3,64] (hdb) ST3750640A 5QD4ZKA9 size: 732574552 Feb 12 14:04:22 Tower kernel: md: disk5 new disk Feb 12 14:04:22 Tower kernel: mdcmd (1): set md_num_stripes 1280 Feb 12 14:04:22 Tower kernel: mdcmd (2): set md_write_limit 768 Feb 12 14:04:22 Tower kernel: mdcmd (3): set md_sync_window 288 Feb 12 14:04:22 Tower kernel: mdcmd (4): set spinup_group 0 0 Feb 12 14:04:22 Tower kernel: mdcmd (5): set spinup_group 1 4 Feb 12 14:04:22 Tower kernel: mdcmd (6): set spinup_group 2 2 Feb 12 14:04:22 Tower kernel: mdcmd (7): set spinup_group 3 0 Feb 12 14:04:22 Tower kernel: mdcmd (: set spinup_group 4 0 Feb 12 14:04:22 Tower kernel: mdcmd (9): set spinup_group 5 0 Feb 12 14:05:22 Tower kernel: mdcmd (10): set invalidslot 1 Peter or somebody else, can you confirm that I'm good to go (or at least the best bet at recovering the array)

Thank you for the instructions, I know how to fiddle with linux but I'm far from an expert. The only thing I'm not sure about is the partitioning of the drive. I'll boot up with a seperate key to see what it does, maybe its gonna be more clear at that point but I'm a bit scared of starting the array from that temp usb key. Wouldn't there be a way through shell to partition the drive? Or is it a bit more complicated than that?

Well that is the thing, let me state the facts again: - Unraid sees two drives with errors - One of the drives completely failed and needs to be replaced - The other drive is actually fine and they were false errors. But since unraid still sees it as bad, I can't just rebuild the failed drive. - There MUST be a way for me to tell unraid that the drive with the false errors is fine. Then I could rebuild the drive that failed.

Can anyone confirm that my plan is going to work or not?

Can't start the array, Too many wrong and/or missing disks! So here's my plan: Change the failing hard drive Follow instructions at http://lime-technology.com/wiki/index.php?title=Make_unRAID_Trust_the_Parity_Drive,_Avoid_Rebuilding_Parity_Unnecessarily Start the array, this should rebuild the failing/new drive and leave the other hd untouched... unless I'm wrong and there was actual errors on the drive. What do you think?

Ok, so I shutdown the machine, removed power cord, waited and started it up again.. I heard one of the drive ticking (normally an HD Ticks once but here I'm talking multiple ticks). It stopped after ~10 ticks or so... I waited out but unraid never got online (couldn't ping the machine). So I decided to shut it down and unplug the ticking hard drive (of course it was one of the faulty drive, the one with the most errors). Now unraid gets online but of course its saying I'm missing a hard drive and the other one is still a red dot but now has a temperature reading. I attached the syslog from this bootup. I also attached the smart report of the drive that has a red dot now that it responds to it. I'm thinking the failing drive was messing up with the data from this drive, hence why unraid saw errors from it as well. So I'm thinking, is there a way to tell unraid that this drive is fine so I can swap out the failed drive and rebuild it? syslog.txt smart.txt