-
Notifications
You must be signed in to change notification settings - Fork 314
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add parser for CIFS client stats #95
Comments
Here's a sample stats file: (Ubuntu 4.15.0-20-generic kernel)
|
This is what I get on CentOS7 (kernel: 3.10.0-862.3.3.el7.x86_64):
@SuperQ which Distribution is this? |
@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: 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? |
Ok now I am totally confused. I have tested this in a vagrant box with
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. |
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. |
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. |
Got yer note. Regarding the per-tree-connect output (each Let me know what version of the CIFS tools are in use in each case. Eg.: I'll ping the folks in charge and see what info they can give you regarding the formats you're getting back. |
@SuperQ possible that it's related to the used samba version. I have used the mount flag @c-r-h I will give you intel about the mount.cifs version tomorrow as well. Your help is welcome ;) |
Thanks @c-r-h! |
@shibumi: Right on track. Steve says:
|
Oh... and it's not the Samba version, but the protocol version that makes a difference. The |
@c-r-h 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
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. |
@c-r-h One question. Is a mix out of SMB1 and SMB3 possible? so something like this?:
|
Yes, mix is valid. The above examples seem to be vers=2.x. I don't have a sample of vers=3.0 yet. |
Ok, I got a sample for vers=3.0. It looks like there is no stats difference for 2.x or 3.x. |
Quick notes:
The chart on this page may be useful: http://cifs.com/ Oh... forgot to say... Each protocol version (SMB1, SMB2, SMB3) has multiple successive dialects. |
Thanks for the feedback. I have nearly finished the implementation of support for SMB1. Next step will be SMB2 and SMB3 + Test Units. I hope that I can get this finished tomorrow. |
I have a working version now that supports SMB1 and SMB2/SMB3. Here is my current branch: What is missing so far:
Am I missing something? Note: This is my first go code that goes beyond parsing some JSON.. so feedback is really appreciated |
Looks good so far! |
In case you want to test it out: Here is a main.go file with all structs and regexes: https://paste.xinu.at/1UJMr2/ |
Current Status:
Todo:
https://github.com/shibumi/procfs/tree/shibumi/cifs The tests are still failing.. Somebody an idea?
|
Ok I have worked on the tests, added some comments and added the cifs part to the |
Looks like the This leads to a question in my head. Do we want still want to support |
SMB1 will still be available in Samba. We're just turning it off by default as Microsoft has previously done in Windows. All that needs to be done to re-enable it is to change a setting in the smb.conf file. The same is true for the SMB1 protocol in the Linux SMB kernel client (aka. the CIFS kernel client). SMB1 will be disabled by default but can be re-enabled. The code will still be there. I imagine that legacy installations will continue to use SMB1 for some time. Whether or not you want to support these installations is a separate question. SMB2 and SMB3 share the same statistics format because they are the same protocol SMB3 is just SMB2 with some added features. |
Hi,
Any comments on this before I start coding? (Short Recap: We want to have SMB1 and SMB2/SMB3 statistics in procfs, but the kernel provides no serialization format. So the only way to parse this is via regex. Except you have a better idea...) Go Playground link to the regex (code generated by regex101.com): https://play.golang.org/p/WDDG6gjJdca |
Hi, https://github.com/shibumi/cifs-exporter You can have a look over it and decide if this is the functionality you would want to see in procfs. It's the best solution I came up with. |
The CIFS kernel module includes client stats in
/proc/fs/cifs/Stats
, but only if the kernel is configured withCONFIG_CIFS_STATS
.It includes per mountpoint info, so it should be pretty useful.
The text was updated successfully, but these errors were encountered: