I've never looked at the Reiser code though the comments I get from
    friends who use it are on the order of 'extremely reliable but not
    the fastest filesystem in the world'.

    I don't expect HAMMER to be slow.  A B-Tree typically uses a fairly
    small radix in the 8-64 range (HAMMER uses 8 for now).  A standard
    indirect block methodology typically uses a much larger radix, such
    as 512, but is only able to organize information in a very restricted,
    linear way.

    The are several tricks to making a B-Tree operate efficiently but
    the main thing you want to do is to issue large I/Os which cover
    multiple B-Tree nodes and then arrange the physical layout of the B-Tree
    such that a linear I/O will cover the most likely path(s), thus
    reducing the actual number of physical I/O's needed.  Locality of 
    reference is important.

    HAMMER will also be able to issue 100% asynchronous I/Os for all B-Tree
    operations, because it doesn't need an intact B-Tree for recovery of the
    filesystem.  It can reconstruct the B-Tree for a cluster by scanning
    the records in the cluster and using a stored transaction id verses the
    transaction id in the records to determine what can be restored and
    what still may have had pending asynchronous I/O and thus cannot.

    HAMMER will implement one B-Tree per cluster (where a cluster is e.g.
    64MB), and then hook clusters together at B-Tree leaf nodes (B-Tree
    leaf -> root of some other cluster).  This means that HAMMER will be
    able to lock modifying operations cluster-by-cluster at the very
    least and hopefully greatly improve the amount of parallelism supported
    by the filesystem.

    HAMMER uses a index-record-data approach.  Each cluster has three types
    of information in it:  Indexes, records, and data.  The index is a B-Tree
    and B-Tree nodes will replicate most of the contents of the records as
    well as supply a direct pointer to the related data.  B-Tree nodes...
[ message continues ]