I have my network drives mapped to my desktopand normally can drag and drop my files. I have recently placed a 3TB  Seagate drive on line as my parity drive. I did not do anything to the drive such as preclear since I have read that when a new drive is placed on line UnRaid will format the drive. What are your suggestion. I tried to acess the tower with "tower" command and "tower:8080" no help.

Can you connect with telnet? Attach a keyboard and screen to the server.

Telnet, No I cannot since I don't see it on the Network. I can as you suggested view it on a monitor and use the keyboard. I tried to capture a sys. log. However, since I had to manually power down the system I was unable to capture this. Thanks for your help. Since I have removed the Flash drive. Can you tell me what folder the Sys.Log will be written to?

The syslog is not saved. Attach the current syslog and use the telnet-tail method to capture the syslog during a crash. The telnet-tail session needs to be left open until the system crashes. See here: http://lime-technology.com/forum/index.php?topic=9880.0

Here is the sys.log as it up and running.

syslog-2012-12-27.txt

I have the server on-line for the past several hours. I removed the partiy drive and all is stable so far. I guess I need to find out what is wrong with the parity drive. Perhaps I should have run the preclear as was advised to me. I did notice when I took the array off line "unmounting drive" was repeated for several lines  as if it was stuck. That's when the server timed out and was not accessable. Any thought?

 

A disk will not unmount if there is a file or working directory open on the disk.

I will go ahead and Preclear the (ST3000DM001) Segate 3TB drive and see if this fixes my problem. Thanks so much for you help.

This issue is now solved.The Preclear needed to be compleated prior to assigning the Parity drive. Lots of wasted time on my part. Thanks to all the helped me out.

This is getting OLD. I took the Parity drive off line for the week and had no issues. I placed it back (added) it back and the problem is still their. I have had my system up and running with no parity drive for well over a year and had no problem whatsoever. I guess I will takes all services out of the equation and leave the parity dive in active in the array to narrow it down. I am still using RC5 and not upgraded until I can solve this. Will keep you posted...

My guess would be that the parity drive is having some sort of issue that is messing with the server. Try running a telnet session with the log tailing so that you capture what happens. Make sure to set the telnet window so it stores lots of the previous lines of data.

Can you clarify what you did here, as I'm a little confused.  Your syslog above was captured at about 5pm on the 27th of December, and shows no problems at all, with a parity drive online and apparently working fine.  The syslog does show that the previous session had crashed, and so a parity check is running, which will slow all access to the server, but as of 4:54pm there were no errors at all.  Then what confuses me is that the next morning (Dec 28 9:55am) you posted and indicated that you had "removed the parity drive" and wondered "what is wrong with the parity drive"?  What errors did you see that caused you to feel it was not working correctly?

 

Can you try to capture a syslog during a session where the parity drive is causing trouble?  Then we may be able to help you better.

I removed the Parity drive because everytime I try to move any data to the server from any P.C. on the network. The data would either not transfer or stop and I would lose my connection to the server. If I take the Parity drive off line and place the array unprotected back on line . I can move data any which way and not lock-up the server at all. So my question is this? The way I understand it is any time data is added to the server the parity drive starts to write and I lose my connection. Is this the way it's suppose to work?

The way I understand it is any time data is added to the server the parity drive starts to write and I lose my connection. Is this the way it's suppose to work?

 

Parity drive gets written with a data transfer to server = yes.

Server loses the connection during writes to the server = no.

Here is the attached txt from the tail session. Seems lke the server is not seen on the network for some reason. Any help would be appreciated.

1262013.txt

What are the hardware specifications? How are the drive connected?

Please see the link for the hardware: http://lime-technology.com/forum/index.php?topic=20886.msg185504#msg185504

Here is the attached txt from the tail session. Seems lke the server is not seen on the network for some reason. Any help would be appreciated.

 

Collect the entire syslog by copying it to the flash using the attached keyboard.

The server came back after a few hours without me re-booting. I have attached the sys.log file.

syslog-2013-01-26.txt

The server came back after a few hours without me re-booting. I have attached the sys.log file.

 

Your syslog is showing link up messages without corresponding link down messages.  Seems like I remember there was a bug in a certain network driver that did that, some time ago. Since you are still using RC5, and have a server that disappears and reappears, which sounds like a network problem, I recommend upgrading to RC10, with its newer Realtek support.  Hopefully that will fix the issue.

10-4, I guess I have nothing to lose at this point. I will make the upgrade and report back. However, if this was a network problem as you mentioned. Why am I able to remove that parity drive (from the array) and have no further issues with any of the drives once they are placed back on line?

Here is the new sys log after I upgraded to 5.0 rc10.

syslog-2013-01-27.txt

Here is the new sys log after I upgraded to 5.0 rc10.

 

Syslog looks pretty good, no apparent issues with the network or the array, including the parity drive.  Maybe it's time to test those parity-protected transfers again?

 

The network did begin with one extra link up message, a very minor oddity.  You will know pretty quickly if it's working correctly, of course.

 

I'll note one other oddity, very minor and not really an issue, but something I've never seen before.  In your RC5 syslog, XOR speed (using pIII_sse method) was 8724.400 MB/sec.  In your RC10 syslog, XOR speed (using same pIII_sse method) was 3855.600 MB/sec!  That is less than half the speed of RC5.  It really does not matter, since UnRAID systems are not CPU bound, they are I/O bound, but it *is* rather curious!  There was no corresponding change in your CPU performance.

Yes, So far for the past 2 week all has worked out pretty good. I am able to see the server when I post files and not drop off line as before. I now am in the same boat with some of the other member when I say it is very slow to transfer files. I think this will be a driver issue and will work itself out with more future updates of unRaid.  Rob not sure about what to do with the error's. I have not seen anything lock up or strange going on. Last Syslog posted with RC10.Thanks for all the help everyone.

syslog-2013-02-09.txt