• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

testing SMB3.0 share for VM's

Joined
Apr 25, 2014
Messages
52
I went ahead and setup a windows file server with 2 ssd's for storing hyperv vhd's.

The specifics of the setup are
fileserver: DL380 G6 with 2 Seagate 600 480gb ssd's in raid 1(+0). Drives are most likely running at sata 3.0gb/s speeds because of SAS drives on same controller which is the integrated p410i. Running windows server 2012 r2 file server role. created the ntfs volume on the physical drive (raid volume) then shared it using file shares (no caching selected when creating share). 2 1gb nic's in team.

hyperv hosts: DL380 G5 2x L5330 procs, 8GB RAM. 2 1gb nic's in team.

I then created a windows server 2012 r2 vm and tested the vhd with crystalmark

smbvm%20disk%20bench.jpg


None of the values are so high that I would assume im maxing out the 2gbps teams, although I'm not sure how to test the max speed 1 direction on the link, because moving a large file is limited by the write speed of the physical drive on the other end, I would need a ssd attached to the hyperv host to write fast enough to test it.

The writes might be being helped by the raid cache (256mb) on the file server, not sure if the raid battery is charged well enough for the server to let the cache kick on.

In the end though, the values seem fairly decent especially for random access... probably fine to run basic servers from.
 
I replaced the smb share with iscsi volumes handled by different masters and a quorum which makes the cluster pass all storage checks.

Ran crystal disk mark and got

iscsi-vm%20disk%20bench.jpg


No more write caching? and roughly similar performance.
 
When I run crystal mark directly on the raid array that contains the csv vhd's I get this.

direct%20disk%20bench.jpg


So im loosing 10x the performance with the overhead of isci initiator/target or with smb3.0 or from the network, although it seems odd that it would be from the network since it affects random and sequential evenly and doesn't just cap them all at roughly the same speed. It will probably be easiest to test the network issue though since I can add another 2 pairs of gigabit links to each team, or as a separate team on a separate subnet.

Edit: Decided to run a larger test (1000mb instead of 100mb) and got these results.

direct%20disk%20bench2.jpg
 
Last edited:
Teaming is not supposed to increase the bandwidth of single links between hosts. If you want to use the SMB 3.0 features, the NICs should have separate IPs and not be teamed. ISCSI can only properly benefit from multiple links with Multipath IO. And even that cannot split a single request over multi links. And it is better that way, the defragmentation of the packets would probably introduce latency and cost more performance than it is worth it.

The proper way to get a high host-to-host throughput is to use 10 Gb Ethernet or Infiniband.
 
Back
Top