Re: cifs large write performance improvements to Samba

From: Steve French
Date: Mon Dec 13 2004 - 15:32:08 EST

cliff white wrote:

On Mon, 13 Dec 2004 10:56:45 -0600
Steve French <smfrench@xxxxxxxxxxxxx> wrote:

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

Generally what I wanted to see was:
1) at least one little endian and one big endian client to run the tests on (and for the network filesystems, at least one server).
2) execute a set of similar tests on each of the filesystems (for our Samba purposes e.g. ext3, xfs, jfs are particular important, and cifs and might as well run on nfsv3, nfsv4)
- fsx on each (specify an operation count of n=10000 should be sufficient)
- fsstress with at least 100 processes on each, with at least 2 loops, 200 ops
- "connectathon nfs" tests on each. The local filesystems should all be able to pass these.
- for cifs to Windows servers, there is one of the "special" subcategory of tests that has to be skipped (since Windows server can not support the operation)
- and for cifs locktests 7 and 10 are expected to fail at this time
- dbench

There are others that can be run but they don't seem to broaden it much. What is very important to add into the mix - based on defects I have seen in various network and cluster filesystems over the past few years - are something similar to the following:
- Add a test which hits the three Linux specific fcntls (dnotify, set and get lease)
- Add a test which uses O_DIRECT open flag (could also simply use the mount flag for those filesystems which support that). NFS guys made trivial mod to fsx for this and ran with fsx -W -R (to disable mmapping when running with direct i/o)
- Add a test which exercises flock to the mix
- Add a maximum and minimium path name and path component test
- Add a test of creating directories with very large number of entries (cthon "basic" subtests can be easily modified for this).
- Add a test which does sendfile with data integrity checking from one process and a mix of normal and mmapped writes and reads from another set of processes
- Add a test of data integrity to the same network fs from multiple clients
- Add a test for stable nanosecond (or 100 nanosecond which is good enough for the network case) timestamps (ext2 and ext3 will fail this since they round timestamps down to the second when inode metadata is written out)
- A better test for the various O_ flags and file modes (especially important to run from multiple clients)
- A better byte range locking functional test
- xattr testing (maximum, minimum sizes, illegal requests, bad user buffers etc.) There is an xattr testcase in the ltp but have not analyzed it enough to see if it will do
- POSIX ACL testing (getfacl/setfacl)
- Trusted and Security attribute testing (to make sure the FS properly handles long attributes and/or values, short attributes and/or values, bad buffers etc.)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at