This has probably already been said, but Motherboards are cheap nowdays. I fought a AMD Gigabyte board for over a year. It did weird things & would lockup every few days. I changed memory, controller cards, cables & even changed out hard drives nothing helped. I chucked the board & tried one of my old Intel boards I had laying around. All of my troubles went away. That was about 3 or 4 months ago. I've now been up 68 days & it's running like I just booted up fresh. Major difference.

 

Believe me It's just not worth tracking down that major of a problem.

 

Phil

 

P.S. Hard drive corruption that may be fixed by utilities is one thing but random read errors or sync errors that happen out of the blue can be caused by the motherboard..

What motherboard & controllers are you using?

http://www.asrock.com/MB/overview.asp?Model=P4i65GV

 

Post a syslog so we can see a picture of your hardware.

Will do; but can't until I get home from work.

 

Also the quality of SATA cables can be an issue of reliability.

I only use the best 

 

Your power supply can also be an issue.

Thermaltake ToughPower 650W; not an issue.

 

Thanks for the tips!  I'm guessing (yes, guessing) it's gonna boil down to the cheap controller headers on this board.  Hoping a PCI card will resolve it.  If not, I'll definitely have to look at a motherboard  ...

 

I hope that's not the case... I want this to be a cheap build 

WeeboTech's message made me look a LITTLE closer at the motherboard, and I just realized it only has 1.5 gbit headers...

 

My drives are all 3 gbit, and the controller (aka drive 2 in my unraid array) is 3 gbit.

 

Could this discrepancy in drive speed affect my parity?  If yes... adding another controller should indeed fix this.

 

Thanks,

Robbie

 

WeeboTech's message made me look a LITTLE closer at the motherboard, and I just realized it only has 1.5 gbit headers...

 

My drives are all 3 gbit, and the controller (aka drive 2 in my unraid array) is 3 gbit.

 

Could this discrepancy in drive speed affect my parity?  If yes... adding another controller should indeed fix this.

 

Thanks,

Robbie

 

It will affect it, but probably not as much as you might think.  It would have nothing to do with the parity errors... they are not speed related, but some random bit errors occurring somewhere. (MB chipset most likely)

 

A PCI bus is limited to 133 MB/s... you can saturate that with only two disks at 60-70 MB/s and be limited by PCI bus speed from there on.

 

Reading an SATA drive at 3 Gb/s vs. 1.5Gb/s will have little difference, as that is the burst rate to the disk controller, not the overall rate of the read or write to the disk.    Depending on the chipset and the controller, you'll probably get somewhere between 70 and 125 MB/s for your SATA drives. 

 

If you look in the syslog, (and know where to look  )  you will see the SATA connection speeds reported for each SATA drive.  You can be certain your on-board SATA-1 controllers are just negotiating the lower speed rate from your drives.

 

Joe L.

So what you're also saying here is that by using a PCI based card as opposed to on-board, I'm going to be greatly reducing the performance of my array?

 

Robbie

When doing parity calcs yes.  Parity calc and check are very bandwidth intensive and a PCI card with more then 2 drives on it can't get to the full speed of all the drives on it, no matter whether the card supports SATA2 or not.  If the board is the problem, you are probably just better off trying to find a new board that has 6 SATA headers or so on it and using it.

WeeboTech's message made me look a LITTLE closer at the motherboard, and I just realized it only has 1.5 gbit headers...

 

My drives are all 3 gbit, and the controller (aka drive 2 in my unraid array) is 3 gbit.

 

Could this discrepancy in drive speed affect my parity?  If yes... adding another controller should indeed fix this.

 

It should only affect parity speed (reads/writes to parity drive), not parity errors. constant parity errors are a problem in communication somewhere.

One board was known to have a heat issue on the southbridge and a fan helped it.

 

Usually the drives have a jumper switch that can limit drive speed too.

In any case it should auto-negotiate.

 

 

That board is pretty old too.  Hmmm.. what would I do...

I might switch and put the parity drive on the PCI card (for this particular motherboard). and see if the problem moves.

 

The Promise TX4 is a reliable PCI SATA 300 Card. But you will still be limited to the 133mb/s PCI bus.

If that board supports 66MHZ PCI, then you will get 266Mb/s but chances are it doesn't.

 

If I had a spare PCI SATA card I would toss it in to see, however, I would not spend the $60 on it brand new.

I might put that towards a Mobo with better bus architecture.

 

This is going out on a limb here, but I've had issues with a ABIT VP6 after it started aging.

The capacitors started drying up. The only way I found the problem was by a specific memtest.

Strange, but only test #7 failed at a very specific memory location. (no matter what I did).

I looked at the hardware very closely for bulging/leaking caps and found one right by the memory sockets.

 

 

The pre-clear and smartctl tests (-t long) would reveal any problems on the drives themselves.

 

 

So what you're also saying here is that by using a PCI based card as opposed to on-board, I'm going to be greatly reducing the performance of my array?

 

Robbie

 

Your on board controllers (on that motherboard) are most likely communicating at the same PCI bus speed.

So what you're also saying here is that by using a PCI based card as opposed to on-board, I'm going to be greatly reducing the performance of my array?

 

Robbie

I don't know if it is "greatly" reduced... but yes, PCI is slower than PCI-e, and the chipsets on a given MB could hang off of almost anywhere.  You will know for sure when you see the overall "speed" of your parity calculation.  Parity check speed depends on a lot of factors, but you can see some benchmarks here in the wiki: http://lime-technology.com/wiki/index.php/User_Benchmarks  In general, the more drives, the slower it will be.

 

A lot of us run PCI based servers.  Mine is one of those with mostly PATA drives.  I have 10 drives in the protected array.  My MB had 2 onboard SATA-1 ports, but I have no idea where they attach.  I don't get the parity check speeds reported by the newest MB using SATA-2, and PCI-e. I average 12-13 MB/s.  My array is easily able to serve multiple concurrent ISO images of DVDs to multiple clients on my home LAN.  A parity check is far more demanding.

The sync errors means that it found a discrepancy between the parity info and what it calculated this time through the disks.  When these keep happening and you have not changed any data then something is probably wrong with your setup.  We have seen memory timing be the cause (check the BIOS to make sure the board got it right), and bad controllers on the board itself, among a few other things.

 

The Errors column for the drives is for Read errors, so the fact that nothing is popping up there is good.

 

It seems like your drives are OK, but running a smart long test on the drives would probably be a good thing to do, to make sure they are good and get a baseline of how the drives are.

 

Yes, you can move the array to a new motherboard entirely and not have a problem restarting the array.  Just take a screen shot of what drives are assigned to what positions in the array and assign them back to the same spot when you set the array back up on a new motherboard/controller.

 

The one you want to make sure to get in the correct position is the parity drive; if you assign a data drive to the parity slot you will wipe out all data that is on the data drive.

Thanks prostuff1, joe & WeeboTech.

 

So, if I run my parity check over night while nobody is using the array, I should not have any trouble?  And if someone DOES try to use it at that time, it'll just be slower than normal, but still accessible?

 

I am okay with that, if that's the case.

 

I have two PCI cards which have 2 ports each ... One is already in the system, and is a cheap SIS board.  The second is in my other server, but is being prepared to be moved over to the unRAID box (as we're migrating our old RAID 1 onto the unRAID system).  This controller is a "better quality" 3-ware card.  Again, 2 ports... so if I went with the two cards I have, I'll have 4 ports to start, and then could add a 3rd card (there are 3 pci slots) to add more hard drives.

 

Is this okay to do?

 

Thanks!!

This is going out on a limb here, but I've had issues with a ABIT VP6 after it started aging.

The capacitors started drying up. The only way I found the problem was by a specific memtest.

Strange, but only test #7 failed at a very specific memory location. (no matter what I did).

I looked at the hardware very closely for bulging/leaking caps and found one right by the memory sockets.

While assessing if this motherboard would work for me, I checked all the caps, ran memtest, etc.  I was very thorough.  The board is good, and no errors reported by memtest 86+.

The 3ware card will probably not be supported.

 

unRAID supports the most basic SATA controllers as of now.

I have not tested a 3ware card in my array yet.

 

It is possible to compile in the 3Ware driver and it it reports the drives as ATA-xxxx in the /dev/disk/by-id directory they may work.

 

There are the cheaper SIL 3114 based cards that are reported to work.

 

 

 

 

Hmmm, that's no good... that 3-Ware card is my only in-stock sata controller 

 

I guess I'll have to buy one... argh. 

I'll have 4 ports to start, and then could add a 3rd card (there are 3 pci slots) to add more hard drives.

 

The promise TX4 is reported to work with two cards. which would yeild 8 ports.

There were reports of issues with 3 TX4 cards, and reports of success with 3 TX4 cards.

 

The SUPERMICRO AOC-SAT2-MV8 64-bit PCI-X133MHz SATA Controller Card is reported to work in PCI slots and works with unRAID.

http://www.newegg.com/Product/Product.aspx?Item=N82E16815121009

 

This yields 8 ports and up to 16 with two.

(but your parity speeds will be slow on the PCI bus with 16 drives).

 

Joe's assessment of speed would be a basis for many drives on the PCI bus.

Thanks prostuff1, joe & WeeboTech.

 

So, if I run my parity check over night while nobody is using the array, I should not have any trouble?  And if someone DOES try to use it at that time, it'll just be slower than normal, but still accessible?

Sounds perfect.  Many of us have automated the monthly parity checks...  They ensure that an error such as the one you are fighting does not go un-detected.  The array is still fully accessible during a parity check... and depending on what you are doing, you probably will not notice any change.  It does not affect the playing of a DVD... It might affect the "write" speed to the array, but will you notice if a file-save takes 20 seconds vs 25?  Or, when ripping a DVD over the LAN a few more minutes time? 

I am okay with that, if that's the case.

 

I have two PCI cards which have 2 ports each ... One is already in the system, and is a cheap SIS board.  The second is in my other server, but is being prepared to be moved over to the unRAID box (as we're migrating our old RAID 1 onto the unRAID system).  This controller is a "better quality" 3-ware card.  Again, 2 ports... so if I went with the two cards I have, I'll have 4 ports to start, and then could add a 3rd card (there are 3 pci slots) to add more hard drives.

 

Is this okay to do?

Sounds perfect.  You'll probably need to use the "devices" page to re-assign the parity drive once you install the newer card, as it is new hardware.  Make a screen-shot of the "devices page before you install the new controller as it is as likely as anything it might re-assign the devices in Linux (because the hardware is scanned in a different order) and all the drives might need to be re-assigned to their respective slots.  It won't hurt anything, as unRAID will refuse to start until it sees all the drives it expects.

Thanks!!

You are welcome.

 

Joe L.

Cool, thanks for all the info, everyone.  Much appreciated.

 

WeeboTech - thanks for the card ideas.  I wish I had 64-bit bus on that mobo... but I guess I'll look at the T4 in the meantime.

 

Joe L. - Yeah, I don't think I'd notice the speed difference... it's really just for redundant data storage.  Any "production" stuff is happening on my PC and then being TRANSFERRED to the unRAID.

 

Also, I'll be installing a cache drive as soon as I bump off the old 160 GB drive with a bigger replacement... the 160 GB will become my cache... so write speeds should be okay.

 

That makes me think... I suppose the cache drive could still be on the mobo's bus right?  Because it will never be involved in the parity process, as the parity is built when the files are transferred onto the array (not the cache).  Correcto?

WeeboTech - thanks for the card ideas.  I wish I had 64-bit bus on that mobo... but I guess I'll look at the T4 in the meantime.

 

The Supermicro card also works in a regular PCI slot if you have the clearance on the motherboard for the extended length.

I.E. no caps, cables or memory in the way.

 

Limetech uses the TX4 for extended ports past the motherboard, so you are sure it will be compatible.

 

Also, I'll be installing a cache drive as soon as I bump off the old 160 GB drive with a bigger replacement... the 160 GB will become my cache... so write speeds should be okay.

 

That makes me think... I suppose the cache drive could still be on the mobo's bus right?  Because it will never be involved in the parity process, as the parity is built when the files are transferred onto the array (not the cache).  Correcto?

 

Yes, as long as you purchase the PRO version of unRAID. The PLUS version does not have cache support.

Yes, as long as you purchase the PRO version of unRAID. The PLUS version does not have cache support.

 

Yes, I'm on pro.

Okay; so here's something interesting...

 

I just got home from work to review the parity check I left running when I left, and the final sync error count was only 2.

 

What could this mean?

 

Let me explain a wee bit about what I've done so far, and my experience with parity...

 

1) I built the array, as per the video I posted here: http://lime-technology.com/forum/index.php?topic=4322.0

2) I telnet'd in and copied about 200 GB of files directly to disk2 from an external EXT3 drive using cp -R

3) I ran parity check to make sure all was well, and I got well over 1,000 parity errors, so I figured using cp is a bad thing and have not done it since; instead, I'm using User Shares and going through my network.

4) I've copied a bunch of things via User Shares

5) Ran parity and got 102 (i think it was) errors

6) have copied a little bit more files (not much) and run parity again, got 2 errors (this morning).

 

Does this mean, I'm getting more parity errors when I copy more data?  Am I right in thinking cp is bad for unRAID, or is it actually just my previous problem CAUSING this behavior?

 

Thanks again everyone for all your help.  I picked up a 2nd 2-port Silicon Image card today after my last post... so I'm good to play around with this over the weekend.

 

Robbie

You should never get any parity errors AT ALL, unless you have a power outage during a write, or if something goes seriously wrong.  There is probably little that is so basic as a file copy, so if you can't trust cp to work, then you can't trust the machine, at all.  Something is seriously wrong.  It really may be helpful to see your syslog.

K cool.  Now that I'm home, where do I grab the syslog.  I'm familiar with terminal, so I have no problem navigating the linux telnet session; just let me know the location.

 

Thanks 

 

Robbie

Okay; so here's something interesting...

 

I just got home from work to review the parity check I left running when I left, and the final sync error count was only 2.

 

What could this mean?

 

Let me explain a wee bit about what I've done so far, and my experience with parity...

 

1) I built the array, as per the video I posted here: http://lime-technology.com/forum/index.php?topic=4322.0

2) I telnet'd in and copied about 200 GB of files directly to disk2 from an external EXT3 drive using cp -R

As long as you copied to /mnt/disk2, or to /mnt/user/whatever, you are fine no matter how you did the copy.

3) I ran parity check to make sure all was well, and I got well over 1,000 parity errors, so I figured using cp is a bad thing and have not done it since; instead, I'm using User Shares and going through my network.

Only difference is the speed of the copy and how much it stresses your MB (heat, etc)

4) I've copied a bunch of things via User Shares

5) Ran parity and got 102 (i think it was) errors

6) have copied a little bit more files (not much) and run parity again, got 2 errors (this morning).

It indicates your MB (or disk controller) is dropping bits somewhere.

Does this mean, I'm getting more parity errors when I copy more data?

Yes...

  Am I right in thinking cp is bad for unRAID, or is it actually just my previous problem CAUSING this behavior?

It is your previous problem.  It has nothing to do with how the data is being copied.  unRAID works at the "bit" level, in between the file-system driver and you.  It has no knowledge of the data itself, or how you did the copy. 

Thanks again everyone for all your help.  I picked up a 2nd 2-port Silicon Image card today after my last post... so I'm good to play around with this over the weekend.

 

Robbie

Keep us informed on how it goes...  I'd move the disks off of the MB controller entirely as a start. 

 

Syslog is in

/var/log/syslog

 

Copy it to the flash drive first

cp /var/log/syslog /boot/syslog.txt

 

Then you can get to it from windows (in file-explorer) at

\\tower\flash\syslog.txt

Joe L.

K cool.  Now that I'm home, where do I grab the syslog.  I'm familiar with terminal, so I have no problem navigating the linux telnet session; just let me know the location.

 

Thanks 

 

Robbie

 

/var/log/syslog.

 

do a

 

todos < /var/log/syslog > /boot/syslog.txt

 

then if you are using windows,

navigate to \\tower\flash (or whatever your machine's name) attach it.

PS you might want to zip it first to save space.

 

Thanks all!!

 

My syslog is attached.  If you notice something, can you please tell me the line number(s) so I can kinda learn what it is that's happening here (so I can inevitably help others).

 

Thank you!!

 

Robbie