Re: cifs large write performance improvements to Samba

cliff white
2004-12-13T17:30:41Z

On Mon, 13 Dec 2004 10:56:45 -0600
Steve French <smfrench@austin.rr.com> wrote:

> 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.

We ( OSDL ) would be very interested in this sort of testing. We have some fs tests
wrappered currently
cliffw
OSDL
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

--
The church is near, but the road is icy.
The bar is far, but i will walk carefully. - Russian proverb