Build Instructions for XDD release
--
Supported OS:  Linux, AIX, OSX

On supported OS:
> ./configure
> make
> make install

By default, XDD and supporting scripts are installed in /usr/bin and /usr/lib, 
in order to change the installation path, use --prefix=<new path> during the 
configure step.  By default, the following features are enabled: XFS support,
NUMA support, and Infiniband support.  If you do not need these features, or
cannot install the relevant support libraries, you can disable each of these
features individually during configure with the following flags, respectively:
--disable-xfs, --disable-numa, and --disable-ib.

Build instructions for XDD repository code
--
If you are using the git repository version of XDD (i.e. you are a
prospective XDD developer), you will need to add one more step during the 
software build process.  We also suggest enabling debug mode.

On supported OS:
> autoconf
> ./configure --enable-debug
> make
> make install

XFS pre-allocation support
--
File preallocation on end-to-end transfers currently only works for the XFS
file system.  This is mainly because the posix_fallocate call is supported
inconsistently in Linux, and so we are making the direct fctl call in the
case of XFS file systems.  We attempt to enable preallocate on XFS if we can
find the correct headers in the default places.  But if the headers are not
easily locatable then we do not enable XFS preallocation support.  The
configure script controls xfs preallocation with with an explicit enable/disable
flag.  To guarantee that XFS preallocation is enable, use the following:

> ./configure --enable-xfs

To disable XFS preallocation, use the following instead:

> ./configure --disable-xfs

The defaults have been tested on Fedora 12, Scientific Linux, and Suse only.

Qdepth/Thread count advisory
--
In XDD, the number of threads is often governed by the queue depth option
or the thread count option.  The number of threads than may be created is
system dependent.  For example, on my laptop I can only create 916 threads
before the system returns a "resource busy or unavailable" error.  Its
not just a simple memory limitation necessarily either (i.e. reducing the
pthread stack size doesn't automatically increase the number of threads you
can create).  In general, the number of threads that can be initialized
by XDD is limited by the system rather than XDD.  This is mainly interesting
when using fork-thread type access patterns.