[Samba] 32 seconds vs 72 minutes -- expected performance difference?
aaptel at suse.com
Fri Feb 15 11:05:20 UTC 2019
Saurabh Nanda <saurabhnanda at gmail.com> writes:
> 1) Why is the log saying `SMB2` everywhere? Shouldn't it be saying
"SMB3" is mostly marketing, it inherits almost everything from SMB2 hence
why it's often handled by SMB2 code. You will see this in Samba,
Wireshark, Linux, and even Microsoft specification "MS-SMB2" which
actually covers both versions.
> 2) Is this normal -- fs/cifs/smb2misc.c: Calculated size 157 length 156
> mismatch mid 11907
Could be a bug or miscalculated length + non critical warning, I also
see this on master kernel. Either way I doubt it's slowing everything down.
> 3) Is this normal -- fs/cifs/misc.c: Null buffer passed to
That can be ignored
> 4) Is this normal --
> fs/cifs/readdir.c: index not in buffer - could not findnext into
> fs/cifs/readdir.c: could not find entry
> 5) This definitely seems like some error, right? -- fs/cifs/smb2maperror.c:
> Mapping SMB2 status code 0x80000006 to POSIX err -61
0x80000006 is STATUS_NO_MORE_FILES, returned by the server at the end of
a listing. Can be ignored, its not added to the stats as it's the
expected "error" for the last listing packet.
> There is also another data point which _might_ be relevant. It _seems_ that
> "systemd-resolved" is randomly crashing on the server , possibly because of
> the mounted samba share. Caveat: I am not completely sure about the
> correlation between samba mount and systemd-resolved crashes. Nevertheless,
> I had already asked this question on StackExchange at
> if you feel that this might be relevant. Further, I can confirm that
> systemd-resolved had NOT crashed when the following logs were obtained:
> ## OPERATION 1 - `ls debug.log` -- simply listing a single file. Does
> anything seem wrong with this?
This is going to be disapointing but we don't see the error that gets
added in the stats in this log extract. Have you checked your samba logs
as well? There might be useful information in there (might have to
increase "log level" in smb.conf, it can go up to 10 but that will
generate a *lot* of data).
If you still don't want to share the network capture you should at least
try to open it yourself in wireshark, it would save everyone time.
You can find out the protocol negotiated by filtering for
smb2.cmd == 0
And looking at the Response SMB2 > Negotiate Protocol Response > Dialect
in the lower panel.
Note that if you re-mounted during the capture or if some error happened
the kernel might have tried to reconnect automatically and you will see
You can filter for packets with errors like so:
smb2 && smb2.nt_status != 0x80000006 && smb2.nt_status != 0
You can ignore "MORE_PROCESSING_REQUIRED" and ioctl error
"FS_DRIVER_REQUIRED" as well. They will show up on every reconnection.
Also, please attach files or disable word-wrapping when you send logs in
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)
More information about the samba