Distribution: FC2 Hardware Environment: x86 Problem Description: Trying to access the samba shares, I am getting the Slab corruption messages and the system became unstable. This problem was already discussed on LKML and Andrew located the broken code, but it is still not resolved: http://marc.free.net.ph/message/20041027.000343.74f4a932.html http://lkml.org/lkml/2004/11/13/75 http://lkml.org/lkml/2004/11/15/119 I am opening the report for it so to not let it to get forgotten. This is rather severe problem, I'd be happy if it is fixed. I can't use smbfs as it currently is.
SMBFS is being deprecated, you should be using CIFS instead (see http://lwn.net/Articles/183693/)
> SMBFS is being deprecated, you should be using CIFS instead Unless something have changed really recently: 1. CIFS doesn't support NTLMv2 properly 2. CIFS doesn't support DFS properly 3. Memory corruptions have to be fixed regardless, as this may be a security threat. I have to use CIFS as smbfs is simply broken (hence that report), but it doesn't suit my needs at all.
NTLMv2 has been merged in 2.6.18 (actually, the main reason why smbfs is still in the tree is the fact that cifs didn't supported NTLMv2). As for DFS, that's a completely different beast and has never been supported in smbfs either. AFAICS, the cifs code in 2.6.18-rc's should be able to replace completely smbfs. smbfs is certainly full of bugs precisely because of lack of maintainance, but I don't know what's the official position with it other than "get rid of it as soon as possible", people is puttin all their efforts in cifs instead ;(
> NTLMv2 has been merged in 2.6.18 Ah-ha, so that's interesting, thank you. I'll try the -rc soon to see how it works, and then perhaps I won't need smbfs any more indeed. > As for DFS, that's a > completely different beast and has never been supported in smbfs either. I expected that, although, since smbfs doesn't work, I wasn't able to test and make sure. :)
OK, so the only problem I have now with CIFS is that it generates a very heavy traffic. The more shares are mounted, the heavier is the traffic, even if I do nothing at all with the shares. The traffic goes to port 445/tcp. Is there any way to solve this?
cifs vfs support for NTLMv2 works to Samba, but needs minor addition to work with Windows2003 (cifs does not send the server & domain name strings a second time in the ntlmv2 response as Windows apparently expects) CIFS should generate a bit less traffic than smbfs does (cifs writes by default are more efficient 56K in size rather than 4K, reads 16K rather than 4K, and cifs vfs does much better job local caching than smbfs). I had noticed slab fragmentation on the client (but not corruption, and only on the client) but more on 2.6.9 and earlier kernels, except for heavy write workloads which were greatly helped when cifs vfs went to using iovecs on write (only doing a small few hundred byte allocation on write, rather than 17K slab allocation). When signing is required cifs does still do a large slab allocation (which can lead to some fragmentation in heavy write workloads) so that we can calculate the signature on a buffer that won't change out from under us (although that can be changed by turning on experimental)
> cifs vfs support for NTLMv2 works to Samba, but needs minor addition to work > with Windows2003 Thanks for info - fortunately, I am using it with samba and it works fine. > CIFS should generate a bit less traffic than smbfs does (cifs writes by default > are more efficient 56K in size rather than 4K, reads 16K rather than 4K, and > cifs vfs does much better job local caching than smbfs). I understand, however, I see the nasty traffic even when there is no activity at all on the mounted volumes. I am not reading anything and not writing, so I guess caching is not involved. But the more shares I mount, the heavier is the traffic. Is this expected, or a bug? Where does that traffic come from, if I do not do any transfer? Of course the VFS can do some periodic pinging to see if the link is still alive, but this can't cause such a big and constant traffic, or can it?
I usually trace traffic with ethereal and look at the network analyzer to see what is being sent (or tcpdump if only from command line), but a couple other options are also easy: 1) if cifs stats are enabled in config, periodically dump out the stats to see what types of commands are being sent: "cat /proc/fs/cifs/Stats" (presumably these are lookups which on the wire are transact2 QueryPathInfo calls and show up in the total SMB request count) or 2) for a short period of time: a) enable debugging "echo 1 > /proc/fs/cifs/cifsFYI" b) dump dmesg ("dmesg > dmesg-output" c) disable debugging ("echo 0 > /proc/fs/cifs/cifsFYI")
Created attachment 8781 [details] dmesg dmesg output
Created attachment 8782 [details] etherial etherial output
Created attachment 8783 [details] stats /proc/fs/cifs/Stats
Created attachment 8784 [details] tcpdump tcpdump output
Thanks. I collected all the outputs you mentioned. Could you please take a look at it?
OK, I have to apologize. I've located the faulty user-space process that caused this. So, except for the missing DFS support, I have no problems with CIFS right now. Thanks!
Stas, if you don't object let's the bug then since you've resolved the issue - unless you feel like DFS issues still need to be addressed. Thanks.
> Stas, if you don't object let's the bug then Let's the bug what? Close it? > since you've resolved the issue I resolved the issues with CIFS, while the bug was initially submitted for smbfs. It was said here that smbfs is being deprecated, but all these years long it is still provided. Nevertheless, feel free to close the bug. I am now using CIFS and do not care about the deprecated smbfs any more. Now the fix I would really appreciate, is to just remove the buggy smbfs from kernel. :)
Created attachment 12906 [details] Deprecate buggy smbfs Here's the real fix, please consider applying before closing this. :)
I think this is probably good idea, we'll see what Steve thinks. Some things phase out slowly, this probably depends on who still depends on them.
That (patch to mark smbfs as deprecated) is fine by me - if particular problems with Windows9x or OS/2 were found, I would not mind delaying this - but the support in cifs for those servers seems to work well enough. The only missing feature (relative to smbfs for which it only partially works anyway) in cifs is Kerberos support which is in progress.
OK in recent git it reads now: config SMB_FS tristate "SMB file system support (OBSOLETE, please use CIFS)" depends on INET select NLS Thanks, closing the bug.