Original... We have a newly set-up unRaid system (2 x 1.5Tbyte disks, 2G RAM, half decent CPU), and I have undertaking some REALLY basic tests on it as regards performance and reliability.

 

I have set up a share and connected from my desktop Windows machine via a switch (100Mbit) to the unRaid box. At the most simple level I select a series of directories from the desktop machine (data files, word docs etc, not any open or OS files) and then attempt to copy to the share on the unRaid box. The windows dialogue shows the copy progressing well (subjectively looks as fast as a local disk copy), but then after maybe 30 seconds it all stops, the Windows File Explorer becomes unresponsive and then maybe 2 mins later the message "Cannot copy xxx.xx. The specified network name is no longer available".

 

The same thing happens with any random selection of source files, it isnt specific. The machine is currently (still) calculating parity - but same thing happens whether I stop that first or work through / over it.

 

The web interface into unRaid continues to work, and afterwards the files up to the 'jam' are in place on the unRaid box fine. A second attempt (with other random files) will result in the same 'jam' occurring again. The network share still works in another file explorer box is opened.

 

It is almost like something is 'filling up' somewhere and then not 'emptying' - are their options I havent set? Is there something on the Windows box that needs setting (Windows machine talks to other Windows shares fine).

 

Logfile attached.

 

Any help again most appreciated.

 

Day two, parity checking completed......

 

Can now use the unRaid without issue, and files are copying at 100Mbit/s (limited by network switch, next thing on shopping list).

 

It would seem that while calculating parity, performance was so degraded that the system was simply timing out - which is bad news as it means the array will need to go out of service for 20 hours every time I add a new hard drive. Considering one of the key attractions of unRaid is the ease of adding drives ad-hoc, this is disappointing, unless I'm wrong here - which I would love to be!

 

The strange thing is that I did previously try copying files after manually stopping the parity check, but had the same issue.

 

Thoughts anyone (please!).

 

 

 

file-copy-crash-log.txt

The array does not re-calculate parity every time you add a new hard drive. 

 

If the drive being added has been pre-cleared, it will only be off-line for a few minutes.  Parity will not be re-calculated as it is automatically maintained.

 

If the drive has not been pre-cleared then unRAID will keep the array off-line for the time it needs to clear the new drive.  For a 2TB drive this can be 5 or 6 hours or more.  Again, it does not e-compute parity, instead it zeros the new drive.

 

So, to minimize the down-time, pre-clear any new disks prior to assigning them to the array.  The pre-clear script can be found attached to the bottom of this post: http://lime-technology.com/forum/index.php?topic=2817.0

 

The pre-clearing process writes a special signature to the disk that is recognized by unRAID and allows it to skip its own clearing step.

 

Joe L.

When this last happened to me, restarting the WIndows machine fixed the issue. Did you do this between days 1 and 2 perhaps?

Havent tried it yet (array is at work) but I think Joe may have the problem 100% right. I wasn't preclearing the disks (indeed hadn't heard of the concept until his post), so at first switch on had an array of two uncleared 1.5Tbyte drives on moderately elderly hardware.

 

Using the script, presumably my options are either to run it from the command line on the unRaid machine and it will run alongside unRaid, or run it on a temporary spare box with just the one drive (the one being prepped) in?

 

Does either case make any difference? Presumably I may see performance issues if I'm trying to do the clearing on my 'main' unRaid machine whilst the clearing is going on?

 

Either way, Thanks Joe!