Searched everything I could before posting.  I'm using 4.7

 

Had drive 6 fail, then replaced it with the same size drive.  After starting the Array it also listed drive 10 as unformatted.  I stopped the array, unassigned drive 10 then rebooted and reassigned it, same problem.  Took out the drive, plugged it into my desktop and was able to read the contents, so I know it's not unformatted.

 

Any suggestions to keep me from losing two drives worth of Data (4TB)?

syslog.txt

Searched everything I could before posting.  I'm using 4.7

 

Had drive 6 fail, then replaced it with the same size drive.  After starting the Array it also listed drive 10 as unformatted.  I stopped the array, unassigned drive 10 then rebooted and reassigned it, same problem.  Took out the drive, plugged it into my desktop and was able to read the contents, so I know it's not unformatted.

 

Any suggestions to keep me from losing two drives worth of Data (4TB)?

Whatever you do, do not press the format button.

(you probably knew that, but just in case...)

 

First step... determine why the disk cannot be mounted. (a disk that cannot be mounted will show as unformatted)

 

I'm off to find an old post to link to... please wait...

 

Joe L.

Here is the other thread:

http://lime-technology.com/forum/index.php?topic=15385.0

 

According to your syslog, unRAID cannot find the file-system superblock on two disks  (md6, and md10).

 

Those are:

Feb 17 14:59:37 TheHub kernel: md: import disk6: [8,112] (sdh) ST2000DL003-9VT1 5YD24P3S size: 1953514552

Feb 17 14:59:37 TheHub kernel: md: import disk7: [8,80] (sdf) WDC WD20EADS-00R WD-WCAVY6713758 size: 1953514552

Feb 17 14:59:37 TheHub kernel: md: import disk8: [8,176] (sdl) WD My Book      WD-WCAVU0133214 size: 1465138552

Feb 17 14:59:37 TheHub kernel: md: import disk9: [8,64] (sde) ST9500420AS      5VJ0Q98D size: 488386552

Feb 17 14:59:37 TheHub kernel: md: import disk10: [8,48] (sdd) WDC WD20EADS-00S WD-WCAVY3286828 size: 1953514552

(but it might be looking in the wrong spot...)

Feb 17 14:59:38 TheHub logger: mount: wrong fs type, bad option, bad superblock on /dev/md6,
Feb 17 14:59:38 TheHub logger:        missing codepage or helper program, or other error
Feb 17 14:59:38 TheHub logger:        In some cases useful info is found in syslog - try
Feb 17 14:59:38 TheHub logger:        dmesg | tail  or so
Feb 17 14:59:38 TheHub logger: 
Feb 17 14:59:38 TheHub emhttp: _shcmd: shcmd (30): exit status: 32
Feb 17 14:59:38 TheHub emhttp: disk6 mount error: 32
Feb 17 14:59:38 TheHub emhttp: shcmd (31): rmdir /mnt/disk6
Feb 17 14:59:38 TheHub logger: mount: wrong fs type, bad option, bad superblock on /dev/md10,
Feb 17 14:59:38 TheHub logger:        missing codepage or helper program, or other error
Feb 17 14:59:38 TheHub logger:        In some cases useful info is found in syslog - try
Feb 17 14:59:38 TheHub logger:        dmesg | tail  or so
Feb 17 14:59:38 TheHub logger: 
Feb 17 14:59:38 TheHub emhttp: _shcmd: shcmd (31): exit status: 32
Feb 17 14:59:38 TheHub emhttp: disk10 mount error: 32
Feb 17 14:59:38 TheHub emhttp: shcmd (32): rmdir /mnt/disk10
Feb 17 14:59:38 TheHub kernel: REISERFS warning (device md6): sh-2006 read_super_block: bread failed (dev md6, block 2, size 4096)
Feb 17 14:59:38 TheHub kernel: REISERFS warning (device md6): sh-2006 read_super_block: bread failed (dev md6, block 16, size 4096)
Feb 17 14:59:38 TheHub kernel: REISERFS warning (device md6): sh-2021 reiserfs_fill_super: can not find reiserfs on md6
Feb 17 14:59:38 TheHub kernel: REISERFS warning (device md10): sh-2006 read_super_block: bread failed (dev md10, block 2, size 4096)
Feb 17 14:59:38 TheHub kernel: REISERFS warning (device md10): sh-2006 read_super_block: bread failed (dev md10, block 16, size 4096)
Feb 17 14:59:38 TheHub kernel: REISERFS warning (device md10): sh-2021 reiserfs_fill_super: can not find reiserfs on md10

 

Do you know if you specified a starting sector of 63? or of 64 when you initially added those drives?

 

OK, let's try something to see if we can figure out where the file-system actually starts

type:

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

and

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

 

The output should look a lot like this...  Note where the  string "R  e  I  s  E  r  2  F  s" appears....

Let's see if yours is at the same address, or one sector further.

 

Output on one of my drives looks like this  (it has a file-system starting on sector 63):

195+0 records in

195+0 records out

99840 bytes (100 kB) copied, 0.00169403 s, 58.9 MB/s

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

*

0000448  \0  \0 203  \0  \0  \0  ?  \0  \0  \0 361  _  8  :  \0  \0

0000464  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

*

0000496  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  U 252

0000512  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

*

0097792 376  \v  G  \a  e  \a  -  \0  \a 212 267 001 022  \0  \0  \0

0097808  \0  \0  \0  \0  \0      \0  \0  \0 004  \0  \0  % 254 227  \

0097824 204 003  \0  \0 036  \0  \0  \0  \0  \0  \0  \0  \0 020 314 003

0097840 220  \0 002  \0  R  e  I  s  E  r  2  F  s  \0  \0  \0

0097856 003  \0  \0  \0 005  \0 217 016 002  \0  \0  \0 204  ]  \0  \0

0097872 001  \0  \0  \0 353 300 256 263 242 347  N 347 264 362 315 364

0097888 345  V 253 366  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

0097904  \0  \0  \0  \0  \a  \0 036  \0 255 262 303  M  \0  N 355  \0

0097920  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0

 

Here is the thread where I asked another unRAID user to perform the same steps. 

http://lime-technology.com/forum/index.php?topic=15385.msg144723#msg144723 

Apparently, 4.7 has a bug where it will overwrite the MBR of a disk with what it thinks it should be.    We'll soon see if you hit that bug.    It is not a terrible one, as it will take just a few seconds to fix the MBR once more, and no data will be lost, but it could be terrible if you accidentally pressed the format button.  (even then you could probably recover most, if not all the files)

 

Let's see what the two "dd" commands give.  If the partition pointer is pointing to the wrong sector, it will cause the exact error you are getting. 

If pointing to the wrong sector, the fix is given in the above thread... using unraid_partition_disk.sh

If pointing to the right sector, then a reiserfsck command requesting the superblock be rebuilt is the fix.

 

Joe L.

Thanks a ton Joe for your help!

 

So I ran it on the replacement drive sdh (disk 6) and it was virtually the same except following 0097840 it had a comma instead of 220

 

On the unformatted but working drive sdd (disk 10) it was pretty much the exact same as yours.

 

So I'm guessing that now I need to run reiserfsck to get it back up and working again?

 

sdh (disk 6)

 

sdd (disk 10)

Thanks a ton Joe for your help!

 

So I ran it on the replacement drive sdh (disk 6) and it was virtually the same except following 0097840 it had a comma instead of 220

 

On the unformatted but working drive sdd (disk 10) it was pretty much the exact same as yours.

 

So I'm guessing that now I need to run reiserfsck to get it back up and working again?

 

sdh (disk 6)

 

sdd (disk 10)

First, make sure the partition start points to sector 63 on both disks.

 

fdisk -lu /dev/sdh

 

fdisk -lu /dev/sdd

 

If not, point it to sector 63 with the utility script I mentioned in the other thread.

 

 

Joe Please check your PM's for some reason it won't let me post that in this thread.

Ok I ran reiserfsck --check /dev/sdd1 and no errrors were found

 

Then I ran fdisk -lu /dev/sdd and this is what I got.

 

Ok I ran reiserfsck --check /dev/sdd1 and no errrors were found

 

Then I ran fdisk -lu /dev/sdd and this is what I got.

 

Looks fine to me.

 

About the only other reason a drive would not mount I can think of is if one of your add-ons is creating a directory on the disk mount-point, before the disk is mounted. 

 

Are you running any add-ons?  If so, disable them.

If anybody ever runs into a similar issue like I had, PM me.

 

This problem is still unresolved.  Eventually I just threw in the towel as Tom/Lime Support only made my problem worse.  Once I have a buddy of mine examine the commands I was instructed to input, I may either have an actual fix to this issue or a NEVER EVER DO THIS (for risk of corruption/data loss), or hopefully both.