Started a file copy to my array last night and went to bed.

This morning I had a red ball on the parity disk.

 

What I've done so far:

1 - captured the syslog ("v1" attached - it was 300k so I deleted a lot of repeated errors so it would fit)

2 - tried to do get a SMART report but it would not work (disk off-line?)

3 - stopped the array

4 - rebooted

5 - captured the syslog ("v2" attached in next post)

6 - got a SMART report (attached in next post)

 

Now the unRAID menu shows the parity disk with a blue ball. The array is stopped and it says "New parity disk installed".

 

I stopped there to ask for help - I don't want to screw something up.

 

For the most part, the machine has been running (flawlessly) undisturbed since putting it in a rack and upgrading to 4.5.3 two or three weeks ago.

 

What should I do next?

 

Thanks,

Kyle

syslog-2010-03-24-v1.txt

Here's the syslog after the reboot ("v2") and the SMART report (also after the reboot).

syslog-2010-03-24-v2.txt

SMART-2010-03-24.txt

It appears as if the disk timed-out on a write request

 

Mar 23 22:58:59 HunRAID01 kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen

Mar 23 22:58:59 HunRAID01 kernel: ata3.00: failed command: READ DMA EXT

Mar 23 22:58:59 HunRAID01 kernel: ata3.00: cmd 25/00:00:67:2f:7e/00:04:4b:00:00/e0 tag 0 dma 524288 in

Mar 23 22:58:59 HunRAID01 kernel:          res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

Mar 23 22:58:59 HunRAID01 kernel: ata3.00: status: { DRDY }

Mar 23 22:58:59 HunRAID01 kernel: ata3: hard resetting link

Mar 23 22:58:59 HunRAID01 kernel: ata3: nv: skipping hardreset on occupied port

Mar 23 22:59:05 HunRAID01 kernel: ata3: link is slow to respond, please be patient (ready=0)

Mar 23 22:59:09 HunRAID01 kernel: ata3: SRST failed (errno=-16)

Mar 23 22:59:09 HunRAID01 kernel: ata3: hard resetting link

Mar 23 22:59:09 HunRAID01 kernel: ata3: nv: skipping hardreset on occupied port

Mar 23 22:59:15 HunRAID01 kernel: ata3: link is slow to respond, please be patient (ready=0)

Mar 23 22:59:19 HunRAID01 kernel: ata3: SRST failed (errno=-16)

Mar 23 22:59:19 HunRAID01 kernel: ata3: hard resetting link

Mar 23 22:59:19 HunRAID01 kernel: ata3: nv: skipping hardreset on occupied port

Mar 23 22:59:25 HunRAID01 kernel: ata3: link is slow to respond, please be patient (ready=0)

Mar 23 22:59:54 HunRAID01 kernel: ata3: SRST failed (errno=-16)

Mar 23 22:59:54 HunRAID01 kernel: ata3: limiting SATA link speed to 1.5 Gbps

Mar 23 22:59:54 HunRAID01 kernel: ata3: hard resetting link

Mar 23 22:59:54 HunRAID01 kernel: ata3: nv: skipping hardreset on occupied port

Mar 23 22:59:59 HunRAID01 kernel: ata3: SRST failed (errno=-16)

Mar 23 22:59:59 HunRAID01 kernel: ata3: reset failed, giving up

Mar 23 22:59:59 HunRAID01 kernel: ata3.00: disabled

Mar 23 22:59:59 HunRAID01 kernel: ata3.00: device reported invalid CHS sector 0

Mar 23 22:59:59 HunRAID01 kernel: ata3: EH complete

Mar 23 22:59:59 HunRAID01 kernel: sd 3:0:0:0: [sdb] Unhandled error code

Mar 23 22:59:59 HunRAID01 kernel: sd 3:0:0:0: [sdb] Result: hostbyte=0x04 driverbyte=0x00

Mar 23 22:59:59 HunRAID01 kernel: sd 3:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 4b 7e 2f 67 00 04 00 00

Mar 23 22:59:59 HunRAID01 kernel: end_request: I/O error, dev sdb, sector 1266560871

Mar 23 22:59:59 HunRAID01 kernel: sd 3:0:0:0: [sdb] Unhandled error code

Mar 23 22:59:59 HunRAID01 kernel: sd 3:0:0:0: [sdb] Result: hostbyte=0x04 driverbyte=0x00

Mar 23 22:59:59 HunRAID01 kernel: sd 3:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 4b 7e 33 67 00 04 00 00

Mar 23 22:59:59 HunRAID01 kernel: end_request: I/O error, dev sdb, sector 1266561895

Mar 23 22:59:59 HunRAID01 kernel: sd 3:0:0:0: [sdb] Unhandled error code

Mar 23 22:59:59 HunRAID01 kernel: sd 3:0:0:0: [sdb] Result: hostbyte=0x04 driverbyte=0x00

Mar 23 22:59:59 HunRAID01 kernel: sd 3:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 4b 7e 37 67 00 04 00 00

 

It was disabled by the OS, and subsequently by unRAID once writes to it failed.

You are a candidate for the trust-my-parity prodcedure.  http://lime-technology.com/wiki/index.php?title=Make_unRAID_Trust_the_Parity_Drive,_Avoid_Rebuilding_Parity_Unnecessarily

 

Keep an eye on the drive.  You have no idea why the disk froze.  It might be a loose power or data cable.

Joe,

Thanks so much for the quick response.

 

I've read the "trust-my-parity" procedure (a few times) and would like to clarify:

 

It sounds like the main point of that to save time. In other words, is the check/correct process faster than re-writing the entire parity drive (is it faster by a whole bunch)?

 

Is there any advantage to just rebuilding the parity drive (I'm patient)? I'm asking because I was thinking the exercise of re-writing the whole drive may expose something else - just a thought - I probably won't trust that drive for a while.

Joe,

Thanks so much for the quick response.

 

I've read the "trust-my-parity" procedure (a few times) and would like to clarify:

 

It sounds like the main point of that to save time. In other words, is the check/correct process faster than re-writing the entire parity drive (is it faster by a whole bunch)?

 

Is there any advantage to just rebuilding the parity drive (I'm patient)? I'm asking because I was thinking the exercise of re-writing the whole drive may expose something else - just a thought - I probably won't trust that drive for a while.

The "trust" procedure has one other benefit.  While it is progressing you still are protected by parity.  If, by some chance another disk were to fail, you could still recover its contents (assuming, of course, that the parity disk did not go off-line during the rebuild of the replacement drive.)

 

The "trust" procedure is almost exactly the same as pressing the "Check" button when all the drives are online.

 

If you don't mind not having parity protection for a few hours, don't worry about the "trust" procedure, just start the array. It will completely rebuild parity. 

 

Then make certain you press the "Check" button once it is built.  (Calculating parity initially writes it to the drive.  Until you "Check" it, you 'll not know if it can be read back.)

 

Joe L.

Thanks.

I will do the "trust" procedure tonight. If anything is corrected I will follow that with a normal check parity.

I performed the "trust" procedure. During the check it corrected around 124,000 errors (don't know if that's bits or sectors or what).

Now the SMART report shows:

  reallocated sectors = 2

  multi-zone error rate = 136

  raw read error rate = 49

SMART report attached. These are just a couple things that jumped out at me. I have no idea if these are good or bad.

 

After the initial check/correct following the "Trust" procedure, I immediately did another parity check. That one came back with zero errors and the SMART report did not change. I also did a short SMART test and a long SMART test. After each, the SMART report was the same.

 

What do you think? Do I trust this drive or do I get an RMA (I'm 1 year into a 5-year warranty)?

 

I was also thinking that all the activity since the initial error has been reading. What if I hit the disk hard with a bunch of writes or some sort of write/read test. Could that expose some "weak" sectors or is that worth anything? And how would I go about doing that? Since it's the parity disk I could take it out of the array and hammer it with some utility but I'm not familiar with anything like that and am not exactly sure of the steps required to put it back into the array and rebuild parity when I'm done. Any ideas on that (if it's even worth it)?

 

 

I performed the "trust" procedure. During the check it corrected around 124,000 errors (don't know if that's bits or sectors or what).

I think it is bits. Never tried forcing two bits in a word to see if it counts it as 1 word, or 2 bits.

Now the SMART report shows:

 reallocated sectors = 2

 multi-zone error rate = 136

 raw read error rate = 49

SMART report attached. These are just a couple things that jumped out at me. I have no idea if these are good or bad.

 

After the initial check/correct following the "Trust" procedure, I immediately did another parity check. That one came back with zero errors and the SMART report did not change. I also did a short SMART test and a long SMART test. After each, the SMART report was the same.

 

What do you think? Do I trust this drive or do I get an RMA (I'm 1 year into a 5-year warranty)?

 

I was also thinking that all the activity since the initial error has been reading. What if I hit the disk hard with a bunch of writes or some sort of write/read test. Could that expose some "weak" sectors or is that worth anything? And how would I go about doing that? Since it's the parity disk I could take it out of the array and hammer it with some utility but I'm not familiar with anything like that and am not exactly sure of the steps required to put it back into the array and rebuild parity when I'm done. Any ideas on that (if it's even worth it)?

I'd keep an eye on the drive and watch for more sectors being re-allocated.  They'll never agree that 2 re-allocated sectors represents a failed drive when they supply several thousand in the spare pool.  If you see a trend of it being taken out of service again because of a "write" failure then I'd RMA it.

 

As far as 124000 errors... I'd expect that if the "write" of a "stripe" of data failed. (and that is the only way a disk will be taken out of service (DISK_DSBL))  When you performed the first parity check (as part of the trust procedure) it fixed them.  

 

To exercise the entire parity disk by writing to it you will need to go without parity while it is being re-calculated (press the button labeled as "restore" but do not use the "trust" process, then Start the array),

or substitute a different equal or larger sized disk as parity while you un-assign the old parity drive to test it.  

 

Normal writes to the array should be enough to get it to fail if it is a bad disk, so I would just keep an eye on the disk status.

 

As far as the report:

 multi-zone error rate = 136

 raw read error rate = 49

They mean nothing except to the manufacturer.  You can only look at the current normalized value compared to the threshold for those attributes.

 

Joe L.

Joe,

Thanks again for the good info.

 

Based on that, here's my plan:

- Limp along and keep an eye on it while I wait for UPS to deliver a new 2TB drive.

- Replace the parity drive with a new 2 TB (I've been wanting to do that anyway and I can't add a 2 TB data drive until I do that).

- After I get the current 1 TB out of the array, just hammer the pooh out of it (figuratively speaking) and see if I can make it fail again. At that point, I can do that on Ubuntu or Mac or anywhere I have a utility for that. If it fails, RMA. If it checks out OK, put it back in the array as a new data drive.

 

 

Joe,

Thanks again for the good info.

 

Based on that, here's my plan:

- Limp along and keep an eye on it while I wait for UPS to deliver a new 2TB drive.

- Replace the parity drive with a new 2 TB (I've been wanting to do that anyway and I can't add a 2 TB data drive until I do that).

- After I get the current 1 TB out of the array, just hammer the pooh out of it (figuratively speaking) and see if I can make it fail again. At that point, I can do that on Ubuntu or Mac or anywhere I have a utility for that. If it fails, RMA. If it checks out OK, put it back in the array as a new data drive.

 

 

Once the existing parity disk is out of the array the preclear_disk.sh script is as good as anything to hammer away at it.  Find it here: http://lime-technology.com/forum/index.php?topic=2817.msg23246#msg23246

One of its purposes is to burn in/exercise a drive by using it in a way that is much harder physically on it than usual.

 

I think your plan is a good one.  Only change I would make is to use the preclear_disk.sh script on the new 2TB drive before assigning it to the array as the replacement parity drive.  That way, you at least weed out any early failures and can send it back before you assign it in your array.

 

Joe L.

Thanks for the tip, Joe. I'll definately do that when the new drive comes in.

And thanks again for all your help.

Kyle

It looks like it happened again. Only this time it's disk1 (last time was disk0). I haven't got the new drive in there yet so these are the same 3 drives in the same 3 positions as before.

 

Since I got hard drive errors on disk0 last time (reallocated sectors on the SMART report) I'm hesitant to blame memory or controller just yet. But 2 drives in as many weeks is a little worrisome.

 

I've attached the syslog (before reboot - shows errors Apr. 2 around 18:00)

 

I'm thinking about rebuilding disk1 as-is and seeing if the errors go away like they did on disk0. I understand the procedure for that is:

1 - stop the array

2 - remove disk1 (the failed drive) from the array by un-assigning it

3 - start the array (so it will forget the serial number for disk1)

4 - stop the array

5 - assign disk1

6 - start the array (now it thinks disk1 is the replacement)

7 - let it re-build disk1 by using disk2+parity

 

Is that correct?

 

<EDIT: If you read the first version of this post, forget it. It was the lazy version from someone who doesn't want to help themselves. I did a little research on the forum and wiki and I think I have a plan now (It really wasn't that hard - everyone should do it). At this point I just want to validate that I understand the procedure from what I read in other posts because I'm a little scared. Screwing up would lose 1TB of data that would take me a lot longer to recover from backup.>

syslog-2010-04-03.txt

It looks like it happened again. Only this time it's disk1 (last time was disk0). I haven't got the new drive in there yet so these are the same 3 drives in the same 3 positions as before.

 

Since I got hard drive errors on disk0 last time (reallocated sectors on the SMART report) I'm hesitant to blame memory or controller just yet. But 2 drives in as many weeks is a little worrisome.

 

I've attached the syslog (before reboot - shows errors Apr. 2 around 18:00)

 

I'm thinking about rebuilding disk1 as-is and seeing if the errors go away like they did on disk0. I understand the procedure for that is:

1 - stop the array

2 - remove disk1 (the failed drive) from the array by un-assigning it

3 - start the array (so it will forget the serial number for disk1)

4 - stop the array

5 - assign disk1

6 - start the array (now it thinks disk1 is the replacement)

7 - let it re-build disk1 by using disk2+parity

 

Is that correct?

 

<EDIT: If you read the first version of this post, forget it. It was the lazy version from someone who doesn't want to help themselves. I did a little research on the forum and wiki and I think I have a plan now (It really wasn't that hard - everyone should do it). At this point I just want to validate that I understand the procedure from what I read in other posts because I'm a little scared. Screwing up would lose 1TB of data that would take me a lot longer to recover from backup.>

It looks correct.   Remember to use "Start" to begin the reconstruction.  

 

Pretend the button labeled "restore" does not exist.  It does not have anything to do with re-constructing a replaced disk.

 

Joe L.

Thanks Joe.

 

The rebuild of data on disk1 is underway.

 

It's running at about 8 MB/sec. Does a data rebuild always run that slow? (parity checks run between 35-60 MB/sec for me).

 

EDIT: Scratch that. It's starting to pick up now (currently in the teens and climbing).

 

Thanks,

Kyle

Well, that didn't help. 15 hours into rebuilding disk1, I got these errors:

Apr 4 08:57:35 HunRAID01 kernel: md: disk1 write error
Apr 4 08:57:35 HunRAID01 kernel: handle_stripe write error: 886839320/1, count: 1
Apr 4 08:57:35 HunRAID01 kernel: md: disk1 write error
Apr 4 08:57:35 HunRAID01 kernel: handle_stripe write error: 886839328/1, count: 1
...on and on for a few pages...

 

Which is the same errors I got when this disk went offline the first time - except in a different place.

 

SMART doesn't show any thing unusual (no reallocated sectors, everything else looks good as far as I can tell).

 

Is this an RMA candidate? Is there any way to "make" the sectors get reallocated to see if it's just a bad spot?

 

Thanks.

Well, that didn't help. 15 hours into rebuilding disk1, I got these errors:

Apr 4 08:57:35 HunRAID01 kernel: md: disk1 write error
Apr 4 08:57:35 HunRAID01 kernel: handle_stripe write error: 886839320/1, count: 1
Apr 4 08:57:35 HunRAID01 kernel: md: disk1 write error
Apr 4 08:57:35 HunRAID01 kernel: handle_stripe write error: 886839328/1, count: 1
...on and on for a few pages...

 

Which is the same errors I got when this disk went offline the first time - except in a different place.

 

SMART doesn't show any thing unusual (no reallocated sectors, everything else looks good as far as I can tell).

 

Is this an RMA candidate? Is there any way to "make" the sectors get reallocated to see if it's just a bad spot?

 

Thanks.

Write errors are not a "bad spot"  Unless it is a loose power cable, or a loose sata cable, it sure looks like your drive is failing.

 

Joe L.

OK - I have no reason to believe it's a cable problem because the case hasn't been open or moved in weeks.

 

Having said that, I will open it up and re-seat the cables to see if it behaves any differently (stranger things have happened).

 

Thanks for the clarification.

 

Kyle

 

Joe wrote this elsewhere, but I'm fairly sure it was intended for you:

 

The drive went off-line because a write to it failed.  It went off-line a second time during the reconstruction.  You did not show the actual disk error preceding all the write_stripe errors,  but unless you find a loose cable (either SATA or POWER), you really need to think it is the drive, or the disk controller port.  The drive is most likely.  As far as the cables not being touched in months...  It gives it months to vibrate loose, or for the temperature to heat/cool enough for it to work itself loose.    It can happen.  It is at least worth a check.

 

Joe L.

Thanks, Rajahal.

 

Joe, Do you mean these errors?

 

Apr 4 08:57:31 HunRAID01 kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x400000 action 0x6
Apr 4 08:57:31 HunRAID01 kernel: ata4.00: BMDMA stat 0x5
Apr 4 08:57:31 HunRAID01 kernel: ata4: SError: { Handshk }
Apr 4 08:57:31 HunRAID01 kernel: ata4.00: failed command: WRITE DMA EXT
Apr 4 08:57:31 HunRAID01 kernel: ata4.00: cmd 35/00:00:57:18:dc/00:01:34:00:00/e0 tag 0 dma 131072 out
Apr 4 08:57:31 HunRAID01 kernel: res 51/84:90:c7:18:dc/84:00:34:00:00/e0 Emask 0x10 (ATA bus error)
Apr 4 08:57:31 HunRAID01 kernel: ata4.00: status: { DRDY ERR }
Apr 4 08:57:31 HunRAID01 kernel: ata4.00: error: { ICRC ABRT }
Apr 4 08:57:31 HunRAID01 kernel: ata4: hard resetting link
Apr 4 08:57:31 HunRAID01 kernel: ata4: nv: skipping hardreset on occupied port
Apr 4 08:57:32 HunRAID01 kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Apr 4 08:57:32 HunRAID01 kernel: ata4.00: configured for UDMA/133
Apr 4 08:57:32 HunRAID01 kernel: ata4: EH complete
<these also repeat several times prior to the write_stripe errors>

 

If not, I've attached the syslog.

 

On the vibrate/heat/cool thing - understood. I never was very impressed with the SATA connectors. I'll re-seat and try a rebuild again.

 

I have an available controller port and another controller. Is it worth switching this cable to see if that changes anything (I'd hate to RMA a drive only to find out that wasn't the problem)?

 

Thanks everyone,

Kyle

syslog-2010-04-05.txt

I've looked at all 4 syslogs and your one SMART report, and I have to be honest, I don't think you have had any physical drive problems, just communications and loss contact issues.  I don't believe you needed to rebuild parity or the data drive, just run the Trust My Array procedure each time.

 

You have had 3 serious events.  The first in the first syslog, was a sudden loss of contact with the parity drive (sdb, 3rd motherboard port).  The second was a sudden loss of contact with Disk 1 (sdc, 4th motherboard port).  The third was a series of communications issues with Disk 1 again, but this one was not fatal, and this one includes several instances of ICRC, which could very well be an issue with its current SATA cable.  Replacing it is strongly recommended, but there was no evidence of a cable problem before this last syslog.

 

The first 2 issues are almost certainly not data cable-related, but it's hard to say what could have caused this loss of contact with both drives.  The drive firmware may have frozen up (they all appear to be the same model and firmware), or there was a power issue with both, or they over-heated (a remote possibility), or ...

 

I had never seen the message "nv: skipping hardreset on occupied port", so I checked Google and found it is a new message as of very recent kernels.  Here are some related comments, from one of the foremost authorities, and author of much of the drive-related kernel code.  In other words, because of compatibility issues with some nVidia chipsets, a patch was introduced to avoid hard resets.  It really does not invite a lot of confidence in the nForce line of chipsets.  Two things therefore that you could try, is either move the drives to your PCI controller card (appears to be SiI3114-based), or revert to an older version of unRAID using an older version of the kernel.  Your system might have been able to recover if a hard reset had been tried, but that of course does not explain why it was necessary in the first place.

 

A small issue, the following was found at the end of the last syslog.  Since it refers to drives and shares you don't have, it indicates you may have inadvertently run something configured for someone else.

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(sdf, share, parity drive) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md3, share, Movies [A-D]<br>Movies [E-J]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md4, share, Movies [E-J]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md5, share, Movies [E-J]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md6, share, Movies [E-J]<br>Movies [K-O]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md7, share, Movies [K-O]<br>Movies [P-S]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md8, share, Movies [P-S]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md10, share, Movies [P-S]<br>Movies [T-Z]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md11, share, Movies [T-Z]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(hdi, usage, "Unprotected" temp files) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md11, usage, Usage note disk11) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md10, usage, Usage note disk10) - No drive found

A small issue, the following was found at the end of the last syslog.  Since it refers to drives and shares you don't have, it indicates you may have inadvertently run something configured for someone else.

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(sdf, share, parity drive) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md3, share, Movies [A-D]<br>Movies [E-J]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md4, share, Movies [E-J]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md5, share, Movies [E-J]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md6, share, Movies [E-J]<br>Movies [K-O]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md7, share, Movies [K-O]<br>Movies [P-S]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md8, share, Movies [P-S]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md10, share, Movies [P-S]<br>Movies [T-Z]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md11, share, Movies [T-Z]) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(hdi, usage, "Unprotected" temp files) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md11, usage, Usage note disk11) - No drive found

Apr  4 21:44:07 HunRAID01 unmenu[11385]: WARNING: SetDriveValue(md10, usage, Usage note disk10) - No drive found

He needs to edit the myMain_local.conf file in the unmenu folder to contain the names for his shares, or delete the file entirely if he does not want to document the contents of the disks on the MyMain unMENU plugin.

 

The messages are harmless, but a warning in case of a typo.

The invalid share names are from a file I copied trying to fix an unrelated issue - that's on the shelf for now.

 

I'm questioning the controller/port(s)/cable(s) myself based on these observations:

After re-seating all the power & data cables, I tried to rebuild disk1. That time the data transfer went very fast but didn't run very long before it crashed.

 

I moved disk1 from port 4 to port 2 on the controller and started over. This time the process is very, VERY slow (3 MB/s - currently 44% complete after 20 hours). But it has made it past the point where it crashed the last time. I can't explain why sometimes the data transfer is fast and sometimes it's slow. Nor can I explain why it crashed on port 4 but is still going on port 2. It stands to reason that there's a good chance it's not a disk problem.

 

I'm asking for suggestions. A source for good quality SATA cables would be appreciated. I'd also like to try using the SIL-based controller but I don't know how to go about moving the disks over there without losing the data (will unRAID remember the disks based on their serial number or do I have to move them one at a time with a rebuild after each move?).

 

Thanks again for your help on this. I'd be lost without it.

 

Kyle

 

I moved disk1 from port 4 to port 2 on the controller and started over. This time the process is very, VERY slow (3 MB/s - currently 44% complete after 20 hours). But it has made it past the point where it crashed the last time. I can't explain why sometimes the data transfer is fast and sometimes it's slow. Nor can I explain why it crashed on port 4 but is still going on port 2. It stands to reason that there's a good chance it's not a disk problem.

When it runs that slow, there are usually lots of error messages in the syslog, with messages about the speed being dropped, either or both "limiting SATA link speed to 1.5 Gbps" and a variation of "limiting speed to UDMA/33:PIO4".  Check the syslog, and/or post it here.

 

A source for good quality SATA cables would be appreciated.

If you are in America, MonoPrice is recommended by many, and Newegg is also good.  I just bought several from Newegg that claim the new SATA spec of 6Mbps.  Get the best you can find.

 

I'd also like to try using the SIL-based controller but I don't know how to go about moving the disks over there without losing the data (will unRAID remember the disks based on their serial number or do I have to move them one at a time with a rebuild after each move?).

Super easy, just reconnect the SATA cable from the old port to the new port.  It is always best to note the current drive assignments from the Devices page first, so that if by chance unRAID is confused about the change, you can easily re-assign the drive to its correct slot.  No rebuilding or parity checking needed.

There's nothing in the syslog. The only entries since the beginning of the rebuild are the invalid share names (mentioned before) and a telnet connection.

Prior to these errors I noticed the write speed was getting really slow on just a normal file copy. On a big file transfer it would go fast, slow way down, speed up, slow down, etc. I first wrote it off to the drives being nearly full and it searching for free blocks. I deleted a bunch of stuff and got >25% free on both drives but it didn't change that behavior. Then these issues started so I never drilled down on that one - maybe related to whatever is causing these errors & the slow rebuild.

 

I found a post on the forum here and ordered some cables from MonoPrice.

 

I think I'll ride out the slow rebuild and just see what happens. It's nearly half done now and I want to wait for the new cables anyway.

 

I'll check back in when the rebuild finishes and I replace the data cables.

 

Thanks a lot for your help on this.

 

Kyle

 

The rebuild of disk1 completed - it was very slow. I have some interesting timings to show here and was wondering if someone could take a guess as to why I am experiencing such a slow-down in performance. Here's the history:

 

Date

| Action

| unRAID version

| Controller

| Time

| Speed

03/24/2010 | Parity check/correct when disk0 failed | 4.5.3 | NF4 | 8.3 hours | 31.8 MB/sec

03/25/2010 | Parity check | 4.5.3 | NF4 | 8.6 hours | 30.8 MB/sec

04/05/2010 | Parity check following rebuild of disk1 | 4.5.3 | NF4 | 10.6 hours | 24.9 MB/sec

04/11/2010 | Parity check | 4.5.3 | NF4 | 23.3 hours | 11.3 MB/sec

04/12/2010 | Parity check with new cables | 4.5.3 | NF4 | 16.2 hours | 16.3 MB/sec

04/12/2010 | Parity check with new cables | 4.5.3 | SIL | 14.8 hours | 17.5 MB/sec

04/13/2010 | Parity check with new cables | 4.4.2 | SIL | 15.5 hours | 17.1 MB/sec

04/15/2010 | Parity check with new cables | 4.4.2 | NF4 | 26.2 hours | 10.1 MB/sec

 

Note that the SIL controller is a SATA-1 controller (1.5 Gb/sec) so I expected it to be slower regardless of the version of unRAID I was on.

Historically, my parity check speeds have been in the low 30 MB/sec range like you see on 03/24 and 03/25 several months ago I remember getting one in the 38 MB/sec range but I've never seen that before or since.

In all cases, I left the box alone and was not reading or writing to the array during the parity checks.

 

Looks like there's something going on with the NF4 controller that is not related to the version of unRAID or the data cables. Is 17 MB/sec what I should expect from a 1.5 Gbs controller? What are others seeing?