56C represents an additional significant improvement in performance,
    plus bug fixes and most of the final media changes.

    As with all the commits this week, a kernel and utilities rebuild plus
    a newfs_hammer is needed to continue testing.

    The filesystem block size now increases from 16K to 64K once a file
    has grown past 1MB.  This improves write performance to the point
    where I don't really need to implement cluster_write(), so I've decided
    to forego doing that for the release.

    I will be making one final media change on Friday and then HAMMER 
    development will go into testing & bug fixing mode until the release.
    This last media change will fix mtime and atime storage.  At the moment
    mtime/atime updates require generating UNDO records and, needless to say,
    they're expensive.  I will consider my options tomorrow but I think I
    am going to just not include those fields in the CRC so they can be
    updated asynchronously, without any UNDO's.

				    --
				 Stability
				    --

    I have really begun pounding the filesystem by running blogbench,
    buildworld -j 8, and fsx simultaniously on two test boxes.  I expect
    that any remaining bugs will be worked out over the next week or two.

				     --
				 Performance
				     --

    All performance work except for the atime/mtime issue is now complete.
    WYSIWYG.  HAMMER's performance is extremely good now, and its system
    cpu overhead has dropped to roughly the same that we get from UFS
    (buildworlds run 610-620 seconds of system time for HAMMER, and
    610-620 seconds of system time for UFS).

    HAMMER is now able to sustain full disk bandwidth for bulk reads and
    writes.  HAMMER continues to have far superior random-write performance,
    whether the system caches are blown out or not.  Not only that but
    the performance can potentially improve even more if I redo the 
    deadlock avoidance algorithms.  HAMMER is within 10% of UFS's read
 ...
[ message continues ]

Hi,



That's harmless for atime, but you really want mtime to be properly  
synchronised with the last data update (and to stay that way across an  
undo). Ideally, timestamp data records and hold mtime as a reference  
to the last one updated (or something like that).

--
Bob Bishop          +44 (0)118 940 1243
rb@gid.co.uk fax +44 (0)118 940 1295




[ message continues ]