Add parser for CIFS client stats

[SuperQ]

The CIFS kernel module includes client stats in /proc/fs/cifs/Stats, but only if the kernel is configured with CONFIG_CIFS_STATS.

It includes per mountpoint info, so it should be pretty useful.

[SuperQ]

Here's a sample stats file: (Ubuntu 4.15.0-20-generic kernel)

Resources in use
CIFS Session: 2
Share (unique mount targets): 4
SMB Request/Response Buffer: 2 Pool size: 6
SMB Small Req/Resp Buffer: 2 Pool size: 30
Operations (MIDs): 0

0 session 0 share reconnects
Total vfs operations: 90 maximum at one time: 2

1) \\server\share1
SMBs: 20
Negotiates: 0 sent 0 failed
SessionSetups: 0 sent 0 failed
Logoffs: 0 sent 0 failed
TreeConnects: 0 sent 0 failed
TreeDisconnects: 0 sent 0 failed
Creates: 0 sent 2 failed
Closes: 0 sent 0 failed
Flushes: 0 sent 0 failed
Reads: 0 sent 0 failed
Writes: 0 sent 0 failed
Locks: 0 sent 0 failed
IOCTLs: 0 sent 0 failed
Cancels: 0 sent 0 failed
Echos: 0 sent 0 failed
QueryDirectories: 0 sent 0 failed
ChangeNotifies: 0 sent 0 failed
QueryInfos: 0 sent 0 failed
SetInfos: 0 sent 0 failed
OplockBreaks: 0 sent 0 failed
2) \\server\share2
SMBs: 285
Negotiates: 0 sent 0 failed
SessionSetups: 0 sent 0 failed
Logoffs: 0 sent 0 failed
TreeConnects: 0 sent 0 failed
TreeDisconnects: 0 sent 0 failed
Creates: 0 sent 2 failed
Closes: 0 sent 0 failed
Flushes: 0 sent 0 failed
Reads: 0 sent 0 failed
Writes: 0 sent 0 failed
Locks: 0 sent 0 failed
IOCTLs: 0 sent 0 failed
Cancels: 0 sent 0 failed
Echos: 0 sent 0 failed
QueryDirectories: 0 sent 6 failed
ChangeNotifies: 0 sent 0 failed
QueryInfos: 0 sent 0 failed
SetInfos: 0 sent 0 failed
OplockBreaks: 0 sent 0 failed

[shibumi]

This is what I get on CentOS7 (kernel: 3.10.0-862.3.3.el7.x86_64):

Resources in use
CIFS Session: 1
Share (unique mount targets): 1
SMB Request/Response Buffer: 1 Pool size: 5
SMB Small Req/Resp Buffer: 1 Pool size: 30
Operations (MIDs): 0

0 session 0 share reconnects
Total vfs operations: 21 maximum at one time: 2

1) \\server\\share
SMBs: 13 Oplocks breaks: 0
Reads:  0 Bytes: 0
Writes: 0 Bytes: 0
Flushes: 0
Locks: 0 HardLinks: 0 Symlinks: 0
Opens: 0 Closes: 0 Deletes: 0
Posix Opens: 0 Posix Mkdirs: 0
Mkdirs: 0 Rmdirs: 0
Renames: 0 T2 Renames 0
FindFirst: 2 FNext 0 FClose 0

@SuperQ which Distribution is this?

[shibumi]

@SuperQ any feedback to my first data model? https://github.com/shibumi/procfs/blob/cifs-support/cifs/cifs.go

I am unsure if I should add the key/value pairs of your output as well. I guess this would make sense, but what would I do with it when some kernels don't provide these pairs? Just initialize them as 0?

I am also thinking about the right parsing process. I thought about something similar like the NFS parser.. so reading it line by line, trying to get the key and regex the number out of it?

Problem here: The lines contain more multiple key/value pairs and I have blank lines and some keys consist of multiple words like for example: SMB Request/Response Buffer.

Another problem is that the lines are totally different. In your output we have sent/failed pairs.. I haven't.

So do we stick to the newer kernel? Or do we want to have downwards compatibility to older kernels?

[shibumi]

Ok now I am totally confused. I have tested this in a vagrant box with ubuntu 18.04 and kernel 4.15.0-22-generic. Here is the output what I get here:

Resources in use
CIFS Session: 1
Share (unique mount targets): 2
SMB Request/Response Buffer: 1 Pool size: 5
SMB Small Req/Resp Buffer: 1 Pool size: 30
Operations (MIDs): 0

0 session 0 share reconnects
Total vfs operations: 16 maximum at one time: 2

1) \\server\share
SMBs: 9 Oplocks breaks: 0
Reads:  0 Bytes: 0
Writes: 0 Bytes: 0
Flushes: 0
Locks: 0 HardLinks: 0 Symlinks: 0
Opens: 0 Closes: 0 Deletes: 0
Posix Opens: 0 Posix Mkdirs: 0
Mkdirs: 0 Rmdirs: 0
Renames: 0 T2 Renames 0
FindFirst: 1 FNext 0 FClose 0

As you can see is the output equal to the one from CentOS with kernel 3.15...

Why do you have a totally different output? Another kernel module? Or are you running in Server Mode with a Samba Server? Are you the Server or the Client? My both examples are for Clients.

[SuperQ]

Mine is a client example, but maybe it depends on what the CIFS server is. My CIFS server is Samba 4.4.16 on a QNAP NAS.

[SuperQ]

As for the struct, that's a good question. One option is we could create a struct of pointers, and return nil pointers for missing data. This makes using the functions more annoying, but solves the different versions.

[c-r-h]

Got yer note.

Regarding the per-tree-connect output (each \\server\share is a Tree Connect, which == a mount), all of the information being reported, in each format, is available to the client. It's not stuff that the client would have to query the server to retrieve.

Let me know what version of the CIFS tools are in use in each case. Eg.:
$ mount.cifs -V
mount.cifs version: 6.0

I'll ping the folks in charge and see what info they can give you regarding the formats you're getting back.

[shibumi]

@SuperQ possible that it's related to the used samba version. I have used the mount flag vers=1.0 for the CIFS mounts... I can try vers=2.0 tomorrow.. everything above is not supported by our storage cluster.

@c-r-h I will give you intel about the mount.cifs version tomorrow as well. Your help is welcome ;)

[SuperQ]

Thanks @c-r-h!

[c-r-h]

@shibumi: Right on track.

Steve says:

The short answer is pretty simple - CIFS mounts (RHEL defaults to CIFS/SMB1, ie "vers=1.0") vs. SMB3 mounts. They could probably make an easy parsing change by correlating the output with /proc/mounts (or equivalently /proc/fs/cifs/DebugData) - there is also a debug ioctl that can return some additional info on the mounts.

[c-r-h]

Oh... and it's not the Samba version, but the protocol version that makes a difference. The vers= parameter determines which protocol version should be used. (Basically, it sets the minimum version that the client will negotiate.)

[shibumi]

@c-r-h
On CentOS 7: mount.cifs version: 6.2
On Ubuntu 18.04: mount.cifs version: 6.8

Sadly I have no possibility to test the different versions.. seems like our storage cluster only supports version 1.0.

Btw this is what I get from /proc/fs/cifs/DebugData:

Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 2.09
Features: dfs lanman posix spnego xattr acl
Active VFS Requests: 0
Servers:
Number of credits: 50
1) Name: 139.174.2.4  Domain: workgroup Uses: 1 OS: Windows 5.0
	NOS: Windows 2000 LAN Manager	Capability: 0x8000d3fd
	SMB session status: 1	TCP status: 1
	Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0
	Shares:
	1) \\server\share Mounts: 1 Type: NTFS DevInfo: 0x20 Attributes: 0x4004f
	PathComponentMax: 255 Status: 1 type: DISK 

	MIDs:

No SMB Version.. so seems like we need to parse /proc/mounts/ for the SMB version, except you know another location for getting this value.

[shibumi]

@c-r-h One question. Is a mix out of SMB1 and SMB3 possible? so something like this?:

Resources in use
CIFS Session: 1
Share (unique mount targets): 2
SMB Request/Response Buffer: 1 Pool size: 5
SMB Small Req/Resp Buffer: 1 Pool size: 30
Operations (MIDs): 0

0 session 0 share reconnects
Total vfs operations: 16 maximum at one time: 2

1) \\server1\share1
SMBs: 9 Oplocks breaks: 0
Reads:  0 Bytes: 0
Writes: 0 Bytes: 0
Flushes: 0
Locks: 0 HardLinks: 0 Symlinks: 0
Opens: 0 Closes: 0 Deletes: 0
Posix Opens: 0 Posix Mkdirs: 0
Mkdirs: 0 Rmdirs: 0
Renames: 0 T2 Renames 0
FindFirst: 1 FNext 0 FClose 0

2) \\server2\share2
SMBs: 20
Negotiates: 0 sent 0 failed
SessionSetups: 0 sent 0 failed
Logoffs: 0 sent 0 failed
TreeConnects: 0 sent 0 failed
TreeDisconnects: 0 sent 0 failed
Creates: 0 sent 2 failed
Closes: 0 sent 0 failed
Flushes: 0 sent 0 failed
Reads: 0 sent 0 failed
Writes: 0 sent 0 failed
Locks: 0 sent 0 failed
IOCTLs: 0 sent 0 failed
Cancels: 0 sent 0 failed
Echos: 0 sent 0 failed
QueryDirectories: 0 sent 0 failed
ChangeNotifies: 0 sent 0 failed
QueryInfos: 0 sent 0 failed
SetInfos: 0 sent 0 failed
OplockBreaks: 0 sent 0 failed

[SuperQ]

Yes, mix is valid.

The above examples seem to be vers=2.x.

I don't have a sample of vers=3.0 yet.