Obviously, they are tools you are comfortable with.  I just hope they are not writing to your disks.

It does not write to the disks (unless told to do so by zeroing it)

 

It will be no different than the ones in unRAID, but again, if it makes you happy, fine.

If they both pass I may run the unraid test SMART test too for piece of mind. I know in the past I have had a WD drive fail and before they would issue an RMA I had to give them the error code which is the only reason I am running the tests using their tools.

 

I would have preferred you fix the one drive and then proceed with fixing the second.  Obviously, you are more comfortable with just re-doing everything.  Your choice, but I feel like I am losing a chance to learn how to help others in your situation...  I would at least like you to try to change the one byte I researched and duplicated here... It might save you a lot of aggravation and save you a lot of time re-loading everything...  I'm pretty sure the disk will mount once you fix that one byte.

I will gladly give that a shot. I don't think I can runt hat command on MD3 until MD4 is fixed though. (I guess it will all depend on how these tests come out).

 

Just be careful when you put the disks back in the unRAID server in case the device names change if you install the disks on different ports.  It will not matter, but you need to run the command on the correct disk.  Now, it will not do anything to fix the drive making funny noises... that sounds like a mechanical issue...

This I am aware of. It has always been a noisey drive for a WD Green.

 

Yes.  or in the plugins folder (if you have one)

Ah yes that. I knew there was another place I was forgetting

 

I will gladly give that a shot. I don't think I can runt hat command on MD3 until MD4 is fixed though. (I guess it will all depend on how these tests come out).

You  can do it on the physical drive  (/dev/sde I think it was)  Very worst case is you'll get a parity error at that same address if you do.  It will not affect your data and it is easy to let it fix it if it does)  I think it will let you mount the drive and then you'll be able to start the array. 

 

Just don't press "Format" on anything... (You probably knew that)

 

Very Important... The ADDRESS to fix is different on /dev/sde vs. /dev/md3.  md3 is the first partition.  We would need to run the original "dd" command on /dev/md3, find the "R eIs E r 2 F s " and then calculate the address following the end of it + 3.

 

like this:

root@Tower:~# dd if=/dev/md3 count=195 | od -c -A d |  sed  30q

195+0 records in

195+0 records out

99840 bytes (100 kB) copied, 24.1886 s, 4.1 kB/s

0000000  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

*

0065536 376  \v  G  \a  ( 270 033  \0 023  p  \b 005 022  \0  \0  \0

0065552  \0  \0  \0  \0  \0      \0  \0  \0 004  \0  \0 253 001 357  E

0065568 204 003  \0  \0 036  \0  \0  \0  \0  \0  \0  \0  \0 020 314 003

0065584  "  \0 002  \0  R  e  I  s  E  r  2  F  s  \0  \0  \0

0065600 [glow=red,2,300]003[/glow]  \0  \0  \0 005  \0 217 016 002  \0  \0  \0 325  Y  \0  \0

0065616 001  \0  \0  \0  3 214 357  D 373 256  A 360 256  K  v 006

0065632 020 206 321  j  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

0065648  \0  \0  \0  \0 020  \0 036  \0  m 262 303  M  \0  N 355  \0

0065664  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

*

 

Looks like it is at address 65600 on the /dev/mdX partition.  (Note the value on my array's disk is a 003.  On your drive that will not mount, that byte is a 000.  Once changes to a 003, since there are no other reiserfs errors, it should mount)

 

 

Joe L.

Oh my what a day. I ran the diagnostics. Every drive passed. (good news I guess).

 

I went ahead and found a "config" folder backup from 10/2/12 of my unraid drive. I like to back it up every so often.

 

I removed all unraid plugins from my flash drive, and restored the Super.dat which had the old drive configs. (I am sure this isn't the best way to do it, but it go rid of the redball on MD4 and let my use my original 2TB drive for MD3).

 

Now I that I had a "working config" I was still seeing MD3 as unformatted.

 

This is where I screwed up I think.

 

I ran: dd if=/dev/md3 count=195 | od -c -A d |  sed  30q

 

echo -ne "\0003" | dd bs=1 count=1 seek=98368 of=/dev/md3

 

I think that command might have only been for /sde vs /md3

 

Now when I run dd if=/dev/md3 count=195 | od -c -A d |  sed  30q it looks completely wrong.

 

Screenshots attached.

 

1st screenshot is before

2nd is the command I ran

3rd screenshot is after

You are correct... those commands are for use on the /dev/sde device, not the /dev/md3 device.

 

You overwrote one byte, somewhere... with a 3.  Did you run the prior command I supplied to see the initial contents at that same address?  If you did, we can just put it back.

 

I did post the correct offset for the /dev/md3 device...

Looks like it is at address 65600 on the /dev/mdX partition.  (Note the value on my array's disk is a 003.  On your drive that will not mount, that byte is a 000.  Once changed to a 003, since there are no other reiserfs errors, it should mount)

 

However, since the disk is attached to the /dev/md3 device, you can just run

reiserfsck --rebuild-tree /dev/md3

and it will fix it too.  (no need to just fix the one byte, since parity will be in sync if the /dev/md3 device is used for the --rebuild-tree)

Something still looks odd.

 

Your "R e I s E r 2 F s" string is at a different offset than I predicted.  I would have expected it to the at the same relative position in the /dev/mdX devices, regardless of the starting sector of 63 vs. 64.

First I ran:

dd if=/dev/sde count=1 bs=1 skip=98368 | od -c -A d |  sed  30q

Then I ran:

echo -ne "\0003" | dd bs=1 count=1 seek=98368 of=/dev/sde

Then I ran again:

dd if=/dev/sde count=1 bs=1 skip=98368 | od -c -A d |  sed  30q

 

After that I stopped the array and restarted it. The drive showed unformatted still. I stopped the array and restarted the computer. I then started the array and still had no luck

 

Then I ran dd if=/dev/md3 count=195 | od -c -A d |  sed  30q

then

echo -ne "\0003" | dd bs=1 count=1 seek=98368 of=/dev/md3

then

dd if=/dev/md3 count=195 | od -c -A d |  sed  30q

 

-----------------------

 

So I should only need to run

 

reiserfsck --rebuild-tree /dev/md3 and that's it correct? I am not typing anything else until I hear from you again My impatience is my own undoing at times I swear.

Something still looks odd.

 

Your "R e I s E r 2 F s" string is at a different offset than I predicted.  I would have expected it to the at the same relative position in the /dev/mdX devices, regardless of the starting sector of 63 vs. 64.

Its odd, I thought when I setup my array for my WD EARX drives I precleared them with -a vs -A. So I'd assume it *should be* on 63? I think for some reason it's thinking its on 64?