Re: cifs large write performance improvements to Samba

[Steve French]

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
> cliffw
> OSDL
>  

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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/