readme

这是一个针对大数据的反复多线程读写文件系统的测试代码。

do make,
then run ./tst,
then watch out for "ERROR!!" in tail -1 log*.

Explanations:

This revised test program demonstrates an aspect of the bug at 
   http://oss.sgi.com/bugzilla/show_bug.cgi?id=198
   It appears that the corruption can be exploited by a local process
   writing to a file, so it is not an NFS problem.

   This program writes a file containing a sequence of 8byte values.
   Each of these values has the current file offset encoded in its 48LSbs.
   Bits 48-55 encode an arbitrary 8bit value that can be used to identify
   the writer of the file. This value is passed as a command-line argument
   and is constant throughout the file.
   The 8MSbs of each 8byte value record the ID (1 or 2) of the thread
   which performed the write.

   It's a bit mad:
   -There are two threads writing alternating chunks.
   -It is random which of the two threads will write its chunk first, so
      small temporary holes can be created.
   -Once in a while the writing threads close and reopen the file. 

   The chkdwfile program can be used to check that the sequence of values
   (file offsets) was correctly written. After writing a few big enough
   files, possibly concurrently, we find that rereading some files does
   not give the expected result: some file regions do not contain the
   expected offset progression.

   One test that works well for me is running four instances of this
   program, each writing a 1000mbytes file. See "tst". This is on a 2CPU
   machine, with or without hyperthreading...

   The idea is to reproduce some peculiarities of the nfsd behavior,
   through which we first saw the corruption problem:
   -Some requests can get reordered, whenever packet loss occurs, and
      possibly due to scheduling vagueries,
   -Although the XFS refcache keeps files open between requests, it does
      close the files about every 30seconds (to flush them), and this
      occurs while other nfsd threads are stil extending and writing to those 
      files.

   One problem: Seems to require SMP and multiple instances of this
   program. This doesn't demonstrate the corruption bug on a
   uni-processor machine. Yet we do get corruption through nfsd even
   when booting the server with maxcpus=1.
   I imagine this test case could be simplified if I knew the
   right pattern...