Re: [Samba] 32 seconds vs 72 minutes -- expected performance difference?
- Date: Thu, 14 Feb 2019 23:23:53 +0530
- From: Saurabh Nanda via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] 32 seconds vs 72 minutes -- expected performance difference?
> When you provide an exact vers= then no auto-negotiation happens (unless
> you pass "vers=3" which essentially means 3.x: use 3.0 or above). You
> either get the connection or mount fails. None the less, you can dump
> the current SMB ressources managed by the kernel by looking at
> /proc/fs/cifs/DebugData if your kernel is recent enough it should show
> the SMB version.
There is something going horribly wrong with my configuration. Notice that
CIFS version in the debug output below --
Display Internal CIFS Data Structures for Debugging
CIFS Version 2.10
Features: dfs fscache lanman posix spnego xattr acl
Active VFS Requests: 0
Number of credits: 510
1) Name: [REDACTED] Uses: 1 Capability: 0x300047 Session Status: 1
TCP status: 1
Local Users To Server: 1 SecMode: 0x1 Req On Wire: 0
0) IPC: \\[REDACTED]\IPC$ Mounts: 1 DevInfo: 0x0 Attributes: 0x0
PathComponentMax: 0 Status: 1 type: 0
Share Capabilities: None Share Flags: 0x8000
1) \\[REDACTED]\uploaded_files Mounts: 1 DevInfo: 0x20 Attributes:
PathComponentMax: 255 Status: 1 type: DISK
Share Capabilities: None Aligned, Partition Aligned, Share
Flags: 0x8000 Optimal sector size: 0x200
> * nounix means the server doesn't support unix extensions. These
> extensions are only
> supported by samba and for SMB1 only at the moment. Work is in progress
> to add them to SMB2+.
Will this in any way interfere with "case sensitive = yes" -
> * mapposix has been default for a while, it maps reserved characters (: ?
> \ " etc) to reserved unicode characters to/from the servers so you can
> use those characters in file names transparently from linux, without
> needing to rely on protocol extensions.
Again, this sounds like it directly conflicts with `nounix`!
> If you provide a trace we could see if any unecesarry packets are
> exchanged or if something goes in loop, or if due to some error, the
> kernel close and reopens the connection often and looses time, ...
I have a 1.3 GB capture.pcap from the command you shared earlier. `ls -lR`
ran only for a few minutes, and ended up generating so much network
Btw, I have `smb encrypt = required` on the server config. Ideally, I would
hope, the network capture would be useless!
Apart from network capture, is there any debug logging that I can enable to
give similar insights?
To unsubscribe from this list go to the following URL and read the