CIFS mounts performance issues on overlay network

[amitripshtos]

---

BUG REPORT INFORMATION

Description

When deploying a container which mounts a autofs/cifs folder - using the overlay network gives slow read/write for the mount while using bridge network the performance is fine.

Steps to reproduce the issue:

1. Create a cifs mount and use autofs to mount that mount on the physical host in the path: /mnt/cifs
2. On a swarm, create a container that mounts /mnt/cifs from host
3. Use dd to benchmark the read and write for this folder.
4. Do the same with a container in bridge networking.

Describe the results you received: Write:

Overlay networking
root@56ddcb00dbd6:/mnt/cifs# dd if=/dev/zero of=./testfile bs=512 count=5000 oflag=direct
5000+0 records in
5000+0 records out
2560000 bytes (2.6 MB) copied, 5.28352 s, 485 kB/s

Bridge networking
root@2ae617953580:/mnt/cifs# dd if=/dev/zero of=./testfile bs=512 count=5000 oflag=direct
5000+0 records in
5000+0 records out
2560000 bytes (2.6 MB) copied, 0.342981 s, 7.5 MB/s

Read:

Overlay network
8430+1 records in
8430+1 records out
8632365 bytes (8.6 MB) copied, 0.196636 s, 43.9 MB/s

Brdge network
556+1 records in
556+1 records out
569731 bytes (570 kB) copied, 0.0588529 s, 9.7 MB/s

Describe the results you expected: I expected the results for bridge and overlay networking to be the same.

Additional information you deem important (e.g. issue happens only occasionally):

Output of docker version:

Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:25:13 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:27:37 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker info:

Containers: 3
 Running: 3
 Paused: 0
 Stopped: 0
Images: 33
Server Version: 18.06.1-ce
Storage Driver: devicemapper
 Pool Name: docker-thinpool
 Pool Blocksize: 524.3kB
 Base Device Size: 37.58GB
 Backing Filesystem: xfs
 Udev Sync Supported: true
 Data Space Used: 10.15GB
 Data Space Total: 510.1GB
 Data Space Available: 499.9GB
 Metadata Space Used: 3.813MB
 Metadata Space Total: 12GB
 Metadata Space Available: 12GB
 Thin Pool Minimum Free Space: 51.01GB
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: true
 Deferred Deleted Device Count: 0
 Library Version: 1.02.144 (2017-10-06)
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.18.10-100.fc27.x86_64
Operating System: Fedora 27 (Twenty Seven)
OSType: linux
Architecture: x86_64
CPUs: 24
Total Memory: 23.52GiB
Name: vntapp-prd-el04
ID: AHKK:H2VO:UKLQ:3M2U:6SNM:AQMB:QKS4:5STM:NIFO:PC2W:O6PX:23L6
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

Physical servers

[thaJeztah]

@ctelfer @fcrisciani ptal

[bizmate]

Any update on this? Just interested to know how if CIFS are well supported