I am very new to UnRaid - it seems to be everything I need.  I am hoping someone can help me.

 

I have a cache drive, a parity drive and then five disks.  I had been moving data from my NAS to unRaid.  When a NAS drive was empty, I would pop it in the unRaid, pre-clear it and assign it.

 

Yesterday, I did this with two drives (disk5 and disk6).  I took the array offline and added these two new drives.  I noticed my parity drive was UNASSIGNED, but I could not see SDC (parity drive) in the drop down.  So, I rebooted and sure enough it appeared in the drop down for me to assign.  But it I had to rebuild the parity.  When I woke up this morning I saw the parity drive had an orange ball next to it and disk5 (one of the new drives I added) had a red ball with NO DEVICE / missing.  So I stopped the array and went to the drive5 drop down and there were no drives shown (similar to what happened to the parity drive the day before).  So, I rebooted. 

 

Now, I can see the missing drive for Disk5 and I can assign it.  It shows as UNFORMATTED and gives me the option to FORMAT.  I format it, but it never formats - it always says unformatted. 

 

I don't know if the raid is safe to use while I work out this issue, because I don't know if the parity is rebuilt.  I also don't understand why disk5 disappeared, or what I ought to do now.  I am concerned that the data I have already moved is in jeopardy of being lost. 

 

I am attaching my latest syslog, hopefully someone can help. 

 

A little more info from the syslog:  The particular drive that I can't get to format is WDC_WD20EARS-00MVWB0_WD-WCAZA1996462 / SDG which ought to be Disk5.

Am I right to assumed the /dev/md# = disk#?  I see this in the log:

 

Sep 25 09:51:55 Babel kernel: REISERFS warning (device md5): sh-2006 read_super_block: bread failed (dev md5, block 2, size 4096) (Minor Issues)

Sep 25 09:51:55 Babel kernel: REISERFS warning (device md5): sh-2006 read_super_block: bread failed (dev md5, block 16, size 4096) (Minor Issues)

Sep 25 09:51:55 Babel kernel: REISERFS warning (device md5): sh-2021 reiserfs_fill_super: can not find reiserfs on md5 (Minor Issues)

Sep 25 09:51:55 Babel logger: mount: wrong fs type, bad option, bad superblock on /dev/md5,

 

Sep 25 09:52:03 Babel emhttp: shcmd (142): set -o pipefail ; mkreiserfs -q /dev/md5 |$stuff$ logger (Other emhttp)

Sep 25 09:52:03 Babel logger: mkreiserfs 3.6.21 (2009 www.namesys.com)

Sep 25 09:52:03 Babel logger:

Sep 25 09:52:03 Babel logger:

Sep 25 09:52:03 Babel logger: The problem has occurred looks like a hardware problem. If you have

Sep 25 09:52:03 Babel logger: bad blocks, we advise you to get a new hard drive, because once you

Sep 25 09:52:03 Babel logger: get one bad block  that the disk  drive internals  cannot hide from

Sep 25 09:52:03 Babel logger: your sight,the chances of getting more are generally said to become

Sep 25 09:52:03 Babel logger: much higher  (precise statistics are unknown to us), and  this disk

Sep 25 09:52:03 Babel logger: drive is probably not expensive enough  for you to you to risk your

Sep 25 09:52:03 Babel logger: time and  data on it.  If you don't want to follow that follow that

Sep 25 09:52:03 Babel logger: advice then  if you have just a few bad blocks,  try writing to the

Sep 25 09:52:03 Babel logger: bad blocks  and see if the drive remaps  the bad blocks (that means

Sep 25 09:52:03 Babel logger: it takes a block  it has  in reserve  and allocates  it for use for

Sep 25 09:52:03 Babel logger: of that block number).  If it cannot remap the block,  use badblock

Sep 25 09:52:03 Babel logger: option (-B) with  reiserfs utils to handle this block correctly.

Sep 25 09:52:03 Babel logger:

Sep 25 09:52:03 Babel logger: bread: Cannot read the block (0): (Input/output error). (Errors)

Sep 25 09:52:03 Babel logger:

Sep 25 09:52:03 Babel emhttp: _shcmd: shcmd (142): exit status: -122 (Other emhttp)

Sep 25 09:52:03 Babel kernel: Buffer I/O error on device md5, logical block 0 (Errors)

Sep 25 09:52:03 Babel kernel: Buffer I/O error on device md5, logical block 1 (Errors)

Sep 25 09:52:03 Babel kernel: Buffer I/O error on device md5, logical block 2 (Errors)

Sep 25 09:52:03 Babel kernel: Buffer I/O error on device md5, logical block 3 (Errors)

Sep 25 09:52:03 Babel kernel: Buffer I/O error on device md5, logical block 4 (Errors)

Sep 25 09:52:03 Babel kernel: Buffer I/O error on device md5, logical block 5 (Errors)

Sep 25 09:52:03 Babel kernel: Buffer I/O error on device md5, logical block 6 (Errors)

Sep 25 09:52:03 Babel kernel: Buffer I/O error on device md5, logical block 7 (Errors)

Sep 25 09:52:03 Babel kernel: Buffer I/O error on device md5, logical block 8 (Errors)

Sep 25 09:52:03 Babel kernel: Buffer I/O error on device md5, logical block 9 (Errors)

 

 

If this is a bad drive, do I have to replace it before writing to the array?  I have never written anything on the array to this drive.  I want to know if I can move more from the NAS and take an empty drive from there and replace this one. 

 

Help! Thanks!

syslog-2012-09-25.txt

Well, I did some googling and decided to try and stop the array, assign disk5 to no device then run an initconfig and re-assign all my drives eliminating the troublesome drive and moving disk 5 to disk 6. 

 

I started the array and it appears to be working fine, it says Parity-Sync in progress. 

 

I tested a few shares to make sure things were working and so far so good.

 

Can anyone confirm (or console) that this was the right thing to do?

 

The disk looks bad. I'd run pre-clear on it again. Reports the the last pre-clear should be on the flash. Attach the reports for that drive.

I re-ran pre-clear on it.  I am attaching the three reports that I got.  One appears to be a smart report.

 

I saw Disk /dev/sdg has been successfully precleared

 

So, I stopped the array and it hung at unmounting /mnt/user0 (cache drive doing something?) - well eventually the web gui died.  I rebooted.

 

I added /sdg .. but now it looks like unraid is trying to pre-clear it on its own :

 

emhttp: clearing disk6...

 

 

 

preclear_finish__WD-WCAZA1996462_2012-09-26.txt

preclear_rpt__WD-WCAZA1996462_2012-09-26.txt

preclear_start__WD-WCAZA1996462_2012-09-26.txt

it did not finish the pre-cycle.

 

== Using :Read block size =  Bytes
== Last Cycle's Pre Read Time  : 7:23:06 (75 MB/s)
== Last Cycle's Zeroing time   : 0:00:26 ( MB/s)
== Last Cycle's Post Read Time :  ( MB/s)
== Last Cycle's Total Time     : 
==
== Total Elapsed Time 7:23:34

I used screen to run the pre-clear, so when I toggled over to that screen - after it had finished - and I scrolled up, I saw a ton of errors about integers.  It looked like it was coming from the script, but I rebooted and its lost.  I am re-running pre-clear on it right now and will let you know what happens.  I am also running a preclear on a different drive I just added, so I supposed if preclear fails a third time on that drive - I'll call it bad and replace it.

 

 

Okay, so I added another drive and pre-cleared both of them.  The new drive, pre-cleared fine and I saw a succesful message in unMenu.  The drive that has been problematic disappeared again from unMenu at the end.  Did unMenu detected a failed pre-clear and remove it?

 

 

 

Okay, so I added another drive and pre-cleared both of them.  The new drive, pre-cleared fine and I saw a succesful message in unMenu.  The drive that has been problematic disappeared again from unMenu at the end.  Did unMenu detected a failed pre-clear and remove it?

 

No.

 

Switch he physical locations of the 2 drives and pre-clear again. This will confirm the disk is bad and not another component.

I will do that.  I had tried last night to pre-clear /dev/sdg again (problematic one) - but I got this message:

 

Sorry: Device /dev/sdg is not responding to an fdisk -l /dev/sdg command.  You might try power-cycling it to see if it will start responding.

 

Perhaps that is why it dropped from unMenu and is not available in unRaid menus - this would be the third time it did this after pre-clearing finished.

 

The last preclear that finished on /dev/sdg gave this:  SORRY: Disk /dev/sdg MBR could NOT be precleared

I will do that.  I had tried last night to pre-clear /dev/sdg again (problematic one) - but I got this message:

 

Sorry: Device /dev/sdg is not responding to an fdisk -l /dev/sdg command.  You might try power-cycling it to see if it will start responding.

 

Perhaps that is why it dropped from unMenu and is not available in unRaid menus - this would be the third time it did this after pre-clearing finished.

 

The last preclear that finished on /dev/sdg gave this:  SORRY: Disk /dev/sdg MBR could NOT be precleared

And all of those are symptoms of a disk that simply stoped responding.

 

when you reboot, does it even show up in the BIOS? 

 

The disk could have died, or, a SATA cable, or power splitter, or drive cage connection might be loose or intermittent.  Have you re-seated them? 

 

Since this is your sixth or seventh disk, are you overloading your power supply? What specific make/model  power supply are you using?

 

Joe L.

Thanks so much for the replies and help. I very much appreciate it!

 

I took the troubled drive out and swapped it into a new bay (norco 4224)

I added a fresh 2TB WD drive into the bay where the troubled drive was previously.

 

I pre-cleared both overnight.  This morning the fresh new drive pre-cleared fine and the troubled drive exhibited the same behavior - message that it could not MBR could NOT be precleared and it disappeared from uuMenu / UnRaid GUI. 

 

I stopped array.  Rebooted.  Stopped array.  Added fresh new drive.  Started array.  Formated fresh drive.  All is well.

 

To answer your question Joe - the power supply is a SeaSonic x750 gold and I have two MV8s.

 

There definitately seems to be something wrong with this drive.  Although it doesn't exhibit any problems in a windows box, but that is what pre-clear is for right?  Find out ahead of time the disk is not trustworthy.