Selection Guide · Storage and Backup
NAS Access: Choosing SMB Multichannel or NFS
SMB Multichannel can use multiple connections for a session when supported by both sides. NFS integrates naturally with Linux/Unix workloads; versions, identity and mount settings change…
Technical review:
Architecture and operating model
SMB Multichannel can use multiple connections for a session when supported by both sides. NFS integrates naturally with Linux/Unix workloads; versions, identity and mount settings change behavior. Choose by file semantics and authorization, not only aggregate bandwidth.
Verify client, NIC and service versions on TrueNAS, Samba-based or other NAS products. LACP and SMB Multichannel are different mechanisms; do not assume one flow exceeds a link limit. Test NFS UID/GID or Kerberos mapping and SMB ACL/AD integration separately.
- 1Client capability
- 2Protocol/identity
- 3Network and NAS disk path
- 4Real file workload test
Design parameters
- Workload
- Use separate large-file, small-file and metadata-heavy tests.
- Identity model
- Verify application users/service identities see the intended file permissions.
- Version support
- Check Multichannel/NFS features against the installed version and vendor support.
Platform implementation
Service names are reference points. Scope, defaults, region availability and operating requirements differ; they are not interchangeable guarantees.
| Criterion | SMB Multichannel | NFS |
|---|---|---|
| Client | SMB3 and compatible NIC/service | Version/mount compatibility |
| Identity | AD/ACL model | UID/GID or Kerberos |
| Measurement | Channels + disk + metadata | Mount + disk + metadata |
Worked example
Two 10 GbE ports offer theoretical 20 Gbit/s line rate, but an 800 MB/s disk path prevents a guaranteed 2.5 GB/s file transfer. Benchmark single-channel SMB, Multichannel and NFS using the same data, including p95 metadata latency and negative authorization tests.
Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Multichannel brings no improvement | Disk, CPU or client support limit. | Measure connection counts, NIC load and disk latency together. |
| NFS ownership differs | UID/GID or idmap mismatch. | Compare numeric identities on client and server. |
Acceptance checks
- Record protocol versions.
- Verify actual multiple connections.
- Measure the disk limit.
- Complete ACL/identity tests.
- Test file-locking behavior.
- Measure reconnection after interruption.
Related concepts
Bandwidth and useful throughput
Link capacity differs from useful application throughput. Protocol headers, encryption, retransmissions, small files and storage waits reduce net transfer speed. Keep bits and bytes distinct: 1 Gbit/s corresponds to a theoretical 125 MB/s, not an application performance guarantee. Estimate transfer time as data size divided by measured useful throughput. Observe the network, source reads and destination writes together to locate the bottleneck. Consider temporary slowdowns and competing workloads as well as average speed.
Latency distribution
Latency is the time between starting an operation and receiving its result. An average can hide a small number of very slow operations; medians and p95/p99 percentiles answer different questions. Network RTT, storage waits, processor queues and application processing contribute to end-to-end time. State whether measurements come from the client or server. Check whether increases coincide with traffic growth, maintenance or capacity limits. Record normal and peak-hour baselines before selecting an alert threshold.
File permissions and service identities
File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the actual runtime user, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.
Filesystem and storage layers
An application directory, mount point, logical volume and physical device belong to different layers. Inode exhaustion, read-only mounts and filesystem errors can stop writes even when space appears available. A snapshot often shares the same storage failure domain and is not an independent backup. Mount options and expansion methods depend on the filesystem. Verify mounts after reboot: writing to an unmounted directory can fill the wrong device.
Layer 2 and Layer 3 boundaries
A VLAN creates a separate broadcast domain; routing and access policies govern communication between VLANs. Review trunk allowed lists, access-port assignment and gateway placement together. A network diagram should show where packets are routed and filtered, not merely which cables connect devices. Sharing a switch does not require sharing privileges. When access fails, confirm VLAN and addressing first, then gateway, route and policy matching.
Application consistency
A copy that boots does not prove application-data consistency. Operating-system caches, database logs and write ordering across disks or services affect the result. A crash-consistent copy resembles recovery after an unexpected shutdown; an application-consistent copy follows supported application preparation and write coordination. Validate transaction integrity, relationships between records and application behaviour after recovery, rather than only counting files. Confirm backup integration, application version and reported errors before assuming that consistency was achieved.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.