Re: cifs large write performance improvements to Samba

[Steve French]

The current mainline (very recent 2.6.10-rc Linux tree) should be fine 
from memory leak perspective.  No such leaks have been reported AFAIK on 
current cifs code and certainly none that I have detected in heavy 
stress testing. 

I do need to add some additional filesystem tests to the regression test 
mix soon, and I have asked one  of the guys here  with a ppc64 box to 
run some more bigendian tests on it too.   The ltp has filesystems tests 
scatterred in multiple directories which I need to track down and setup 
scripts to automate (e.g. the sendfile tests are not in the same 
directory with other tests in testcases/kernel/fs, nor is the very 
useful "connectathon nfs" posix filesystem test suite)

The oops (referenced in your post) does need to be fixed of course, but 
since the code that would cause it is disabled (and only is broken to 
certain servers and is noted as broken in the TODO list, implying that 
it should not be turned on in /proc/fs/cifs) - I was considering it 
lower priority than the other issues recently fixed which have been 
consuming my time.  Fixing/adding support for extended security is 
getting closer to the top of the priority list now though.  If I can at 
least prevent the oops with a small change (even if it does not fully 
fix the spnego code) I will push that changeset in soon.   The userspace 
piece should be -- much -- easier to communicate with now that the 
kevents stuff is in.    Very high on the list as well is getting NTLMv2 
tested and working as many environments require it.  Figuring out the 
mysterious byte range lock failure which sometimes occurs on an unlock 
in locktest 7 (I noticed it starting after the nfs changes for the vfs 
posix locking a few months ago) and I have posted about before (Kernel 
panic - not syncing: Attempting to free lock with active blocklist) is a 
slightly higher priority.  Basically I need to figure out what is going 
on with the line in fs/locks.c?

      if (!list_empty <http://lxr.linux.no/ident?v=2.6.8.1;i=list_empty>(&fl->fl_block)
		 panic <http://lxr.linux.no/ident?v=2.6.8.1;i=panic>(/"Attempting to free lock with active block list"/);


Since I am not adding anything to the fl_block list intentionally, I 
need to find out what causes items to be added to the fl_block list (ie 
when the locks_insert_block and locks_delete_block call are made and why 
they sometimes happen differently in lock test 7 then in other byte 
range lock testcases in which unlock obviously works fine).

On the issue of regressing back to smbfs :)  There are a few things 
which can be done that would help.

1) Need to post an updated version of when to still use smbfs for an 
occassional mount (there are only a couple of cases in which smbfs has 
to be used now but they are important to some users - such as users who 
have to access an occassional old OS/2 or DOS server, or who need 
Kerberos), and I need to add it that chart to the fs/cifs/README and the 
project page etc.
2) Public view of the status of testing - the raw data needs to be 
posted regularly as kernel updated (and against five or six different 
server types) so users see what is broken in smbfs (and so users can see 
what posix issues are still being worked on cifs and any known 
problems).   smbfs fails about half of the filesystem tests that I have 
tried, due to stress issues, or because the tests requires better posix 
compliance or because of various smbfs stability fixes.

 If only someone could roll all of the key fs tests into a set of 
scripts which could generate one regularly updated set of test status 
chart ... one for each of XFS, JFS, ext3, Reiser3, CIFS (against various 
servers, Samba version etc), NFSv2, NFSv3, NFSv4 (against various 
servers), AFS but that would be a lot of work (not to run) but the first 
time writing/setup of the scripts to launch the tests in the right order 
since some failures may be expected (at least for the network 
filesystems) due to hard to implement features (missing fcntls, dnotify, 
get/setlease, differences in byte range lock semantics, lack of flock 
etc.) and also since the most sensible NFS, AFS and CIFS tests would 
involve more than one client (to test caching/oplock/token management 
semantics better) but no such fs tests AFAIK exist for Linux.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/