ExpeDat and SyncDat software can target any filesystem path, including those hosted by Network Attached Storage (NAS) devices.  However, such devices use their own protocols for transporting data to and from ExpeDat and SyncDat.  NAS protocols such as CIFS, SMB, NFS, and AFP are not optimized for high performance and have limited throughput compared to direct attached storage.  Below are guidelines for tuning NAS devices to achieve the best performance possible.

Network Attached Storage (NAS) performance will vary greatly depending on the environment, configuration, and use.  These guidelines only address a few commonly available options.  Consult your storage vendor for more specific tuning advice, and see Tech Note 0023 for general hardware recommendations.

Tuning takes place at two points: in the operating system that is hosting the ExpeDat or SyncDat software, and in the NAS device mounted by that host.  The following sections focus on optimizing the communication between those nodes.

General

ExpeDat and SyncDat software must be located as close as possible to the NAS device.  NAS protocols are not suitable for communicating over WANs.  A common mistake for novice users is to type the path of a remote NAS into their ExpeDat or SyncDat client, or specify a local NAS to an ExpeDat or SyncDat server.  Such loops transfer data across the WAN multiple times and result in very poor performance.  When creating NAS workflows, think carefully about where the data is located to ensure it takes the shortest path and that the WAN portion is handled entirely by ExpeDat or SyncDat.

NAS devices, and the networks which connect them, are often shared by multiple users.  Like all storage devices, concurrent use may exponentially decrease performance.  Ensure that the NAS device and its network are properly sized and configured for the number of users.

Do not use ethernet flow control (pause frames) with network attached storage as it may cause hangs and loss of connectivity.

NAS devices may have their own authentication mechanisms which can sometimes conflict with those used by an ExpeDat or SyncDat server.  See Tech Note 0031 for more about how NAS authentication interacts with other systems.

Windows

Windows NAS typically uses the SMB protocol.  For best performance, make sure that the Windows machine and NAS device support the latest SMB version (SMB3 as of this writing).  On the Windows system hosting the ExpeDat or SyncDat software, open a command prompt using "Run as Administrator" and type the following commands:

netsh interface tcp set global rss=disabled netsh interface tcp set global chimney=disabled netsh interface tcp set global autotuning=normal netsh interface tcp set global congestionprovider=ctcp

The commands above disable Receive-Side Scaling, disable TCP Chimney Offload, enable TCP window autotuning, and enable Compound TCP congestion control.  It is recommended that you experiment with different settings to find the combination that provides maximum performance in your environment.

macOS

macOS 10.10 and later typically use the SMB3 protocol.  SMB2, which was the default under macOS 10.9, contained a bug which could cause file corruption.  To ensure maximum reliability and performance, avoid using SMB2.  To see which SMB versions are currently be used, type the following command in a Terminal window:

smbutil statshares -a

To prevent macOS 10.10 or later from accidentally using the SMB2 protocol, and avoid an unrelated SMB3 signing bug, make sure the NAS device supports SMB3 and on the macOS machine create or edit the file /etc/nsmb.conf by placing the following text at the end:

[default] client_signing=no smb_neg=smb3_only

Also avoid macOS 10.14.5 whose SMB implementation suffered from frequent hangs and poor performance.

Unix

Unix NAS typically uses the NFS protocol, which may be based on either TCP/IP or UDP/IP.  Tuning NFS performance while maintaining reliability can be a complex endeavor.  Following are general guidelines.

Ensure that the UDP/IP network buffers are adequate.  See Tech Note 0024 for details.

Update to the most recent operating system and NFS versions available.  Legacy NFS implementations may contain serious performance and file integrity bugs.  Verify that all systems are running an adequate number of biod and nfsd processes.

Use NFS over UDP when possible.  Use the following mount options:

async,rsize=32K,wsize=32K,soft,intr

Older systems may limit rsize and wsize to 8K.  Use the largest value available, up to 32K.  For some NFS servers, adding the no_wdelay option may further improve performance.

NAS Device

Performance tuning options vary greatly by vendor and model.  Make sure your device's software and firmware are up-to-date and consult its documentation for specific tuning instructions.

Enable caching and streaming features such as "read-ahead", "write-behind", "write-back", "audio-video", or "streaming".

Disable database features such as "write-through", "synchronized", or "atomic".  If the device is using RAID storage, see Tech Note 0018 for more RAID suggestions.

If possible, perform TCP/IP tuning on the NAS device.  For example, NetApp devices allow you to increase the TCP/IP window size for CIFS mounts by setting cifs.tcp_window_size.  A value of 2097152 is suitable for most LAN environments.

If possible, avoid mixing different NAS protocols in the same filesystem.  For example, allowing both NFS and CIFS mounts on the same filesystem may create performance or integrity issues.

SAN vs NAS

Storage Area Network devices (SANs) typically use much more efficient protocols such as iSCSI or FiberChannel.  As such, SANs usually provide filesystem performance which is much faster than NAS.  However, SANs can also exhibit contention and integrity issues when a single SAN device is used with multiple high-performance clients.

Feedback

Because storage options and environments are constantly changing, we welcome any observations and feedback you may have.