[UPDATE] Request Help with Accessing v4.7 & v5.b14 servers

[One2go]

The problem with accessing from Win7 machines have been discussed ad nausea in the following threads and just serve as background info.

 

It takes FOREVER to manipulate data on the unRAID server

Problems accessing unRAID from windows 7 x64 machine(s)

 

For the past few days I have monitored my v4.7 server as well as a newly built HP N40L micro server running v5.b14 on my network and would like someones help and opinion using this updated information in solving the weird problem that I have experienced.

 

The UnRaid server running version 4.7 and the strange behavior of waiting and timing out before it starts copying is still there even after trying different suggestions from the different links posted above and other threads here in the forum. However I believe with my most recent experience and with some help from the community here, this idiosyncrasy may actually get solved.

 

I decided to build a new server around the HP N40L micro server and run the latest Beta software v5b14. After putting the server together with 4 Gig of memory and connecting four 3TB Hitachi drives to the bays in the HP server I was busy for the past few days trying to get the array setup and configure the server. Here is where I am standing now with HP server:

 

• Successful precleared all the 3 TB drives with no errors
  
• Successful parity check having 9TB of free space
  
• Server log indicates only minor issues
  
• Drives spin down automatically and spin up manually using the Web GUI
  
• Writing speed to the array of the HP server with v5b14 from my UnRaid server version 4.7 is between 16 to 32 MB/s
  
• Finished copying 4.42 TB of content to the HP micro server
  

 

Copying of 1TB using TeraCopy takes many hours. I read where some complained about the Parity Sync speed & writing to the array speed for the b13 & b14 versions while the older Beta versions did excellent. So I know this will eventually be sorted.

 

Now here is the good news all the weird problems accessing v4.7 from Win 7 64bit machines I do not experience with the HP Micro Server running the latest beta. Solid accessing User as well as disk shares, no problems with copy delays and other delays, just not lightning fast.

 

This makes me tend to believe that it is not network hardware but could be v4.7 server hardware but more likely setup & configuration differences. For example the user root on v4.7 server has a password, on the v5b14 server user root has no password, does that matter? Also I do not recollect that there was for v4.7 an exporting of SMB Security Settings with v5b14 I am exporting security = Public. In addition I just noticed that the permission for the disk shares on v4.7 server is 700 while on the v5b14 HP server it is 770.

 

Please assist me with the following questions?

1. Could it be that not having permissions for the group on v4.7 server could be causing the weird problems?

2. If including group permissions is needed, How do I safely change the permissions on the v4.7 server from 700 to 770? The server has 8 disks (2TB Samsung drives) with about 10TB of content.

3. If the exporting SMB Security Settings matter, where do I check this &  possibly change it in v4.7?

 

I have a gut feeling that I am getting closer to a solution with some help from the community. So far I am pleased with the experience of v5.b14 on the HP N40L micro server, just not the performance of writing to the array. Doing a parity check for 4.47TB on that server was overly annoying starting of at 110MB/s and finishing with 47MB/s. Parity Check finished in less then 10 hours with no errors. As a very last ditch effort I may upgrade the v4.7 server with a Beta version but really would not like to do so as I have plenty of space and no 3TB drives in that server.

 

Attached are system logs for the two servers.

 

Thanks

O2G

V4.7-syslog-2011-12-09.txt

V5.b14-syslog-2011-12-09.txt

[Johnm]

on the HP N40L micro server, just not the performance of writing to the array. Doing a parity check for 4.47TB on that server was overly annoying starting of at 110MB/s and finishing with 47MB/s. Parity Check finished in less then 10 hours with no errors

 

I didn't really read through the whole post as i am at work. I will tell you that those speeds are not to far off for the Hitachi 3TB drives.

I am getting about 125MB/s at start and 65ish MB/s at the tail end of the drive with 9 Hitachi 3TB drives spread across 2 M1015's.

 

About 8 hours for a full check or rebuild.

 

Also, it makes no difference how much data is on a drive for a parity check. it checks every byte across the the entire drive for a 1 or 0.

 

I am going to guess that that is about the limit of those drives in unraid. They defiantly do get slow at the tail end of the drive.

I would love to replace my Parity with a 7200 RPM drive to test  performance. that wont happen with drive prices as they are.

[Joe L.]

I would love to replace my Parity with a 7200 RPM drive to test  performance. that wont happen with drive prices as they are.

Parity calc speed is dictated by the slowest drive involved.  Unless you are writing to multiple data disks concurrently, a faster parity disk will probably not change the parity calc speed.  (not unless all the data disks are 7200 RPM already)

[dgaschk]

32 MB/s is not bad without a cache drive.

[Johnm]

I would love to replace my Parity with a 7200 RPM drive to test  performance. that wont happen with drive prices as they are.

Parity calc speed is dictated by the slowest drive involved.  Unless you are writing to multiple data disks concurrently, a faster parity disk will probably not change the parity calc speed.  (not unless all the data disks are 7200 RPM already)

 

It is to help with multiple simultaneous writes..

[One2go]

Thanks with the confirmation of the write speed as well as the parity check. I still need some help with the following that I raised earlier:

 

Setup & configuration differences between v4.7 & V5B14. Exporting of SMB Security Settings with v5b14 I am exporting security = Public is this needed for v4.7? In addition I just noticed that the permission for the disk shares on v4.7 server is 700 while on the v5b14 HP server it is 770.

 

Please assist me with the following questions?

1. Could it be that not having permissions for the group on v4.7 server could be causing the weird problems?

2. If including group permissions is needed, How do I safely change the permissions on the v4.7 server from 700 to 770? The server has 8 disks (2TB Samsung drives) with about 10TB of content.

3. If the exporting SMB Security Settings matter, where do I check this &  possibly change it in v4.7?

 

I don't know if a brute force of chmod command from 700 to 770 on the disc shares is required for correcting the v4.7 annoyances.

 

So far I am pleased with the v5b14 the way it works on the HP micro server.

 

Thanks

O2G

[lionelhutz]

The security model was changed from 4.7 to the 5.0 beta series. Don't expect them to be the same.

[One2go]

Thanks for the info, is that because SMB2 is now available in v5Beta?

[prostuff1]

Thanks for the info, is that because SMB2 is now available in v5Beta?

No, it was not for the SMB2 reason.

 

The permissions setup was changed to better support AFP and NFS.