I revert my go file to the default. That way if I need to go back to 12a I could re-enable the disabled programs by adding their go script commands back. If you comment them then you don't even have to delete them, just place a # in front of any edited go script command.

 

 

Sent from my iPad using Tapatalk

One other question: Do I risk, simply by upgrading, losing everything on the cache drive if I do not move all of it into the array? I do understand that because it isn't a part of the array, that the drive could fail between upgrading.

 

But really what I mean is, does upgrading the unraid server software do anything to the cache drive, or would I have to do something extraordinarily wrong to lose all of the data on the cache drive?

 

I also see a lot of people with NFS problems. How do I know if I'm running NFS? I think I'm using only SMB and AFP, but I'm not positive.

Here's a question. If I add a 3TB drive, but it's only as a cache drive and not in the array, do I need to upgrade to 5.0x or will 4.7 mount a 3TB cache drive?

Here's a question. If I add a 3TB drive, but it's only as a cache drive and not in the array, do I need to upgrade to 5.0x or will 4.7 mount a 3TB cache drive?

You will need 5.0 beta6+

Here's a question. If I add a 3TB drive, but it's only as a cache drive and not in the array, do I need to upgrade to 5.0x or will 4.7 mount a 3TB cache drive?

You will need 5.0 beta6+

 

Thanks. This may have already been covered, but is anyone running 5.0x on an HP MicroServer without issues? I should be getting a 3TB soon.

 

Cheers.

Well I upgraded to beta 14 and it started up okay. If I were to receive the BLK_EH_NOT_HANDLED, it will happen in the next few days.

 

I will say that the instructions, with regards to updating from beta6+ -> beta14, say to reboot then check the parity of each drive then start the array, however my server automatically started the array, and I was not able to check parity as instructed.

I've been running on a MicroServer for almost a year now.  No problems.

 

I've been running on a MicroServer for almost a year now.  No problems.

 

 

5.0x Beta? It's been out that long? Limetech need to get it fixed up and released if that's the case!

5.0x Beta? It's been out that long? Limetech need to get it fixed up and released if that's the case!

 

It's been in beta since at least summer of 2010, if not earlier, so that makes it at least 18 months in beta mode and counting.

 

But hopefully we are seeing the light at the end of the tunnel....

 

But hopefully we are seeing the light at the end of the tunnel....

 

We're at the mercy of the linux core - although I'd feel more comfortable moving to the beta if the only "bug" left was NFS related.  (Since I don't use NFS)  I'm just not sure at this point if that is the case though - but I do think we're getting close.

Honestly, I have been running beta14 for a week with no problems. Seems rock solid to me. ASUS M4A78LT-M, Supermicro SASLP, Rosewill RC212. So I'm not using any hardware that is known to cause problems..

 

I have rebuild the parity. Precleared three drives. Added 5TB to the server and run a parity check. Everything went smoothly.

I wish I could say the same. I've tried betas going back to 9 my 3TB drive reballs after a parity check every time. Even on beta14.

 

Other than short stroking the hardrive I'm not running anything that doesn't work perfectly on v4.7.

That could very well be your drive. I'm running 6 3Tb drives at work no worries at all.

I now have 5 3TBs, but there was one that kept red-balling. I performed a SMART test and it consistently showed a read error (yet no reallocated blocks; strange).  I eventually RMA'd it back to WD and just got its replacement.  So far, so good...

I now have 5 3TBs, but there was one that kept red-balling. I performed a SMART test and it consistently showed a read error (yet no reallocated blocks; strange).  I eventually RMA'd it back to WD and just got its replacement.  So far, so good...

 

Read Error would show as Pending Sectors not reallocated sectors... Until the sector is written to and reassigned.]

That could very well be your drive. I'm running 6 3Tb drives at work no worries at all.

 

At first I thought the drive was as fault as well. Just all testing seems to indicate the drive is fine. I run the seagate tools and drive passes. smart wouldn't work on the drive with the beta. I could even reboot unRaid and rebuilt the parity and all would be fine until the parity check ran. Once I downgraded to 4.7 all the issue disappeared. Same drive, same cable, same port, same power supply..I've run 3 parity checks..no redball..

 

How could it be the drive? Let me know I'm willing to test. I'd love to upgrade.

After a few spinups and spindowns, the web interface freezes when stopping it

 

telnet remains operational

 

can't stop array via:

 

echo "stop" > /proc/mdcmd

-bash: echo: write error: Device or resource busy

 

sync command freezes

 

syslog attached

 

syslog-2011-12-29.zip

 

 

  As of a couple minutes ago, my system is at 30 days, 22 hours, 17 minutes. I am running 5.0-beta14  (SF: 0.9f), everything is very fast and responsive. Web interface refreshes the up-time regularly and it no longer freezes or takes minutes to change from one page to another. Four of us will be using unRAID to watch movies/TV shows at the same time and there have been no issues whatsoever.

I now have 5 3TBs, but there was one that kept red-balling. I performed a SMART test and it consistently showed a read error (yet no reallocated blocks; strange).  I eventually RMA'd it back to WD and just got its replacement.  So far, so good...

 

Read Error would show as Pending Sectors not reallocated sectors... Until the sector is written to and reassigned.]

 

But that's just from the SMART test; I've had it red-ball on me about 4 times, and every time leading up to it the log would show several hundred errors attempting to write to the drive (that's the only time it would red-ball).  I would take the drive out, format it in another host machine and seems to perform just fine, reinstall into unRAID and rebuilt data and it would work for a day or so after everything was completed and error free, then when I start transferring to the same drive as a disk share, it would red-ball.

 

New 3TB drive in same slot, same cables, so far so good.  Slot is the bottom of a 3-drive sled that has a 90mm pusher directly in front of it.  And this assembly is in line of 2 80mm pullers behind it, exhausting air out of the case.  Average temp of the drive was in the mid-30's to very low 40 C's during constant access.  Again, as I said, I RMA'd the suspect drive back to WD and got the replacement in two days ago (different slot).  So far so good...

I now have 5 3TBs, but there was one that kept red-balling. I performed a SMART test and it consistently showed a read error (yet no reallocated blocks; strange).  I eventually RMA'd it back to WD and just got its replacement.  So far, so good...

 

Read Error would show as Pending Sectors not reallocated sectors... Until the sector is written to and reassigned.]

 

But that's just from the SMART test; I've had it red-ball on me about 4 times, and every time leading up to it the log would show several hundred errors attempting to write to the drive (that's the only time it would red-ball).  I would take the drive out, format it in another host machine and seems to perform just fine, reinstall into unRAID and rebuilt data and it would work for a day or so after everything was completed and error free, then when I start transferring to the same drive as a disk share, it would red-ball.

 

New 3TB drive in same slot, same cables, so far so good.  Slot is the bottom of a 3-drive sled that has a 90mm pusher directly in front of it.  And this assembly is in line of 2 80mm pullers behind it, exhausting air out of the case.  Average temp of the drive was in the mid-30's to very low 40 C's during constant access.  Again, as I said, I RMA'd the suspect drive back to WD and got the replacement in two days ago (different slot).  So far so good...

All your symptoms would take is for your drive to time-out when being read (perhaps taking longer than the driver expected in spinning up) and an entire "read" of a "stripe" of data would fail.  That would show as several hundred errors.

 

There would be nothing physically wrong with the drive.  Just the driver not waiting long enough.    Your whole exercise of re-formatting it, and re-installing it just set it up for another time-out.

 

Until the Linux kernel in the 5.X series matures, and the disk driver does not time-out, your errors are not likely to go away... but the physical disk is probably not the issue.

 

Joe L.

All your symptoms would take is for your drive to time-out when being read (perhaps taking longer than the driver expected in spinning up) and an entire "read" of a "stripe" of data would fail.   That would show as several hundred errors.

 

There would be nothing physically wrong with the drive.   Just the driver not waiting long enough.    Your whole exercise of re-formatting it, and re-installing it just set it up for another time-out.

 

Until the Linux kernel in the 5.X series matures, and the disk driver does not time-out, your errors are not likely to go away... but the physical disk is probably not the issue.

 

Joe L.

 

Sounds like what was happening to me. Due to it's size are the 3TB drives more likely to time out than it's smaller brothers? While I was using the beta my smaller drives never redballed. Is there a way to confirm timing to be the real issue?

All your symptoms would take is for your drive to time-out when being read (perhaps taking longer than the driver expected in spinning up) and an entire "read" of a "stripe" of data would fail.   That would show as several hundred errors.

 

There would be nothing physically wrong with the drive.   Just the driver not waiting long enough.    Your whole exercise of re-formatting it, and re-installing it just set it up for another time-out.

 

Until the Linux kernel in the 5.X series matures, and the disk driver does not time-out, your errors are not likely to go away... but the physical disk is probably not the issue.

 

Joe L.

 

Hmm.  I can see that point if it wasn't for the fact that I have 5 3TB drives in there now but only had one of them constantly red-ball.  Replacing just that one drive appears to have resolved the issue... so far.  I will continue to monitor the situation.  It could be that one drive was not within the tolerance of access times but still be physically "ok."  Regardless, the drive is now back at WD and a new (refurb'd most likely) installed.

All your symptoms would take is for your drive to time-out when being read (perhaps taking longer than the driver expected in spinning up) and an entire "read" of a "stripe" of data would fail.   That would show as several hundred errors.

 

There would be nothing physically wrong with the drive.   Just the driver not waiting long enough.    Your whole exercise of re-formatting it, and re-installing it just set it up for another time-out.

 

Until the Linux kernel in the 5.X series matures, and the disk driver does not time-out, your errors are not likely to go away... but the physical disk is probably not the issue.

 

Joe L.

 

Hmm.  I can see that point if it wasn't for the fact that I have 5 3TB drives in there now but only had one of them constantly red-ball.  Replacing just that one drive appears to have resolved the issue... so far.  I will continue to monitor the situation.  It could be that one drive was not within the tolerance of access times but still be physically "ok."  Regardless, the drive is now back at WD and a new (refurb'd most likely) installed.

 

If the drive showing a read error during a smartctl short or long test, then the drive needs to be tested really hard or RMA'ed.

 

By tested really hard, I mean a bad blocks non destructive read/write test (which takes a week) and then a bad blocks 4 pass destructive write test.Which takes about 2-3 days.

 

Then do a smart long test and check the stats. If you still get a read error, then the drive is useless to you.

 

Frankly, there are very few people willing to go through those lengths.

 

However I did have a drive with a smart read error recover it's ability to be used after the 4 pass destructive write test.

It caused the sectors to be reallocated or marked uncorrectable and the drive functioned fine after that.

 

Point is, if there is any kind of read error, the drive will stop responding to the bus until it gets past the error or decides to give up.

 

There was also a time in past kernels, where the timeout was low and by time the drive was at full spin, the kernel marked the drive bad. limetech had to patch the SATA driver. I'm not sure where that situation stands today.

This is something I have also been experiencing with my 3TB Hitachi Greens. The only issue is, i am on Beta12.

I am not sure if that kernel is also effected by this.

 

It was happening whenever my mover would kick off. the mover is pushing data before the drive is awake it looks like.

 

With beta 14, I had the LSI bug where the drives would redball when you woke them up 100% of the time.

 

If the drive showing a read error during a smartctl short or long test, then the drive needs to be tested really hard or RMA'ed.

 

By tested really hard, I mean a bad blocks non destructive read/write test (which takes a week) and then a bad blocks 4 pass destructive write test.Which takes about 2-3 days.

 

Then do a smart long test and check the stats. If you still get a read error, then the drive is useless to you.

 

Frankly, there are very few people willing to go through those lengths.

 

Which is why after it appeared I was having issues just with this one drive, and swapping a new drive into the same slot was error-free, I simply RMA'd the drive instead of wasting even more countless days stressing out a humongous 3TB drive.

 

Hoping, however, that it truly is not a timing issue that could reveal itself with another drive eventually.  Keeping my fingers crossed...