[Samba] 32 seconds vs 72 minutes -- expected performance difference?

[Aurélien Aptel]

Saurabh Nanda via samba <samba at lists.samba.org> writes:
> Which implies that the server & client auto-negotiated a protocol version
> greater than SMB2.1, right? However, to be sure, I manually specified vers=
> in fstab, but something strange happened. While `man mount.cifs` claims
> that the following are allowed -- 1.0, 2.0, 2.1, 3.0, 3.1.1 (or 3.11) --
> few of them failed with strange errors:
>
> # mount -t cifs -o
> rw,username=myuser,password=[REDACTED],uid=myuser,gid=myuser,vers=3.11
> //[REDACTED]/uploaded_files /home/myuser/shared
>
> mount error(11): Resource temporarily unavailable
> Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

That's normal. You need a very recent kernel to be able to use
3.1.1. Note that 3.11 and 3.1.1 are aliased to the same thing, and 3.1
doesn't exist hence why you get invalid parameter.

> # mount -t cifs -o
> rw,username=myuser,password=[REDACTED],uid=myuser,gid=myuser,vers=3.0
> //[REDACTED]/uploaded_files /home/myuser/shared
>
> [ finally worked! ]
>
> It seems that vers=3.0 worked, but how do I confirm that the mount ACTUALLY
> happened with vers=3.0?

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.

Alternatively looking at the network trace will also tell you. After
having made the trace you can open it in wireshark [0], filter for
'smb||smb2' and look for Negotiate protocol request/response. The
response will tell you what was picked. More info on how to use
wireshark here [1]. It's a bit old and only covers SMB1 but it's a good
ressource.

> Further, `mount` is showing a LOT of options that I did not specify. I do
> not fully understand their impact:
> [...]
> Namely: forceuid, forcegid, nouinx, serverino, & mapposix

Note that some of this option string is generated at runtime by the
kernel, so what you see is the current running state, which might differ
from what you provided as some options are deduced/tried during connection.

* forceuid/forcegid are sort of internal options to say use mount-provided
  uid in all cases and ignore what the server returns.

* 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+.

* serverino makes the client use the server-provided unique file id as
  inode numbers. Without it the local inode numbers are generated and not
  persistent and your local apps can run into all sorts of issues.

*  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.

> Could any of these be causing the problems that I'm observing?

I don't think so.

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, ...

And from the time between request and response on listing queries we can
see if it's just the server that takes an abnormal amount of time to
respond.

You can look at my instructions in a previous email. The resulting .pcap
file might be quite large.

You could open a bug on the samba bugzilla and upload the trace there,
this will require an account and I don't know the file size limit on
attachements.

Otherwise you could encrypt the trace [2] and upload it on one of many
file sharing websites out there (dropbox, google drive, mega, ...).

0: https://www.wireshark.org/
1: https://wiki.wireshark.org/Presentations?action=AttachFile&do=view&target=RonnieSahlberg_UsingWireshark.pdf
2: gpg --output mycapture.pcap.enc --symmetric --cipher-algo AES256 mycapture.pcap
   type a passphrase and share it with whoever you feel comfortable

Cheers,
-- 
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)