Server unresponsive

[DrPrimo]

So if I understand correctly you built the server and copied all your data onto it using TeraCopy before calculating parity.  Then after you had copied all your data you assigned a parity drive and established parity.  Now you are trying to write files to your parity protected array and you are getting crashes.  Is that correct?

 

Correct. I copied ~1.1TB to the server with parity unassigned.

 

You mentioned very slow write speeds. What were the write speeds that you saw without parity?  They should probably be ~60MB/sec (or more) if you have a gigabit network.  It sounds to me like you've had slow transfer speeds from the beginning which means that your server (or something else) may not have been running properly all along.  How about copying data from the server?  Does it crash when you do that?

 

Write speeds without parity were ~35MB/s using Teracopy. Initially with parity assigned I was getting ~7-10MB/s using Teracopy. I have not tried copying files off the server, only watched video files that are stored on it which never caused a crash. I will try to copy a file off later tonight.

 

Are the low write speeds significant? Is there anything specific that may indicate?

 

Did you preclear all of your drives before adding them to the array.  If so, how many preclear cycles did you perform?  Did you preclear multiple drives at the same time?

 

The assigned data drive and the parity drive with both precleared with 3 cycles. They both were precleared at the same time. One averaged 25:45 per cycle, the other 28:30.

 

Have you made any changes to your network other than adding your server?  You might consider connecting your server to another port on your switch/router.

 

No other changes have been made to the network since adding the server. I have changed the servers port on the switch (just did now).

 

If I were you my strategy would be to verify the server is stable on its own first - i.e. disconnected from the network - that way you can narrow down the number of variables you're working with.  I feel like you've established that your RAM is not faulty so my next suggestion would be to run simultaneous preclears on all the disks you have or as many as you can without losing data.  FYI-I'm assuming that the data you wrote to your server is still intact somewhere else.  Running multiple preclears is a good way to stress some of the key components in your server.  I have no experience with StressLinux but it sounds like it's trying to do the same thing that multiple preclears would do - stress the system to find weak components.

 

How many simultaneous preclears are an ideal test? ~95% of the data is still on other drives. I built the server to house rips of my DVDs/BRs, and I deleted the extra copies of some of those (about 50) to make room for more (I have about 800 out of 1200 done, then on to box sets....). I can always (hopefully) copy those off the server to re-preclear the drives, or worst case scenario I just re-rip.

[DrPrimo]

OK, was able to copy off a 1.5GB, 1.8GB and 7.85GB file with no crashes.

[wsume99]

Your write speeds with and without parity are slower than I would expect.  I have all WD Green drives and I get 25-30 MB/sec writes with parity on my gigabit network.  Many other users report similar speeds. The fact that you were able to complete three preclear cycles on two drives simultaneously is an indication that your server itself is healthy.  Obviously the more drives you do at the same time the better - it would just load the server heavier and give you more confidence that everything is ok.

 

What happens if you unassign the parity drive?  Does the server crash then when writing files to it with no parity drive?

 

Also you need to be running tail via telnet so you can capture the syslog activity just prior to any crash.  That might help to better describe exactly what is going on. Read about how to do that here

[unraided]

I have never tried StressLinux. Can it be run with the data drive unattached? Or would that give inaccurate results?

 

I believe you can, having said that, you'd want to remove all currently attached disks from your unRAID server BEFORE running a Stress test using StressLinux! It'll allow you to run tests on most componemts on your server, including disks, which it might need to read/write data to your disks too, potentially destroying your unRAID array to the point of no return!

 

To be on the safe side, if you plan to boot into StressLinux, download the latest ISO from their site "http://www.stresslinux.org/sl/", use MultiBootISOs utilitiy "http://www.pendrivelinux.com/yumi-multiboot-usb-creator/" and create a bootable USB drive to boot from the downloaded StressLinux ISO, detach all of your currently attached unRAID disks, and attached a few old disks which you don't care about loosing any data from, boot from your newly created USB drive, run StressLinux and test all attached hardware components to see what (or hopefully) fails to pin point the defective hardware component.

 

You can use MultiBootISOs to apend or create another bootable USB drive to test Ubuntu as well. Given it is a full OS, it'll try to initialize all hardware components it detects (You'll hopefully see this whislt it booting up/pre GUI) and if it tries to load a driver for part XYZ and fails, crashes, etc... other then loading the driver normally, you'll then know what the dud component is.

I can't guarantee it will sus out the fault component, but worth a try. If Ubuntu starts sucessfully, try creating a Samba server and share all individual disks, and write some large files to each one and see it this causes it to fail too.

 

You could finally recrete another unRAID server from a spare USB drive (unlicensed edition), install three spare disks, build a test server and see if that crashes too. If it doesn't, it could be a dud or corrupt file on your existing unRAID USB drive or the USB drive itself is a dud.

 

Hope the above helps,

 

Cheers