The UNDO buffer and crash recovery code is now in-place and working
fairly well. There may still be a few cases where inode link counts and
data get out of sync after a crash but the filesystem should have
much better integrity now. I can ^\+^C my vkernel, restart it,
mount, and HAMMER doesn't blow up. I still have work to do but I am
making really excellent progress.
The pruning and reblocking ioctls are currently non-working due to
the changes, but I expect to have those in working order again (and
crash recoverable as well) in the next few days.
I also still have to do the filesystem full handling before I can
officially declare the filesystem 'alpha'.
--
Large-file write performance is pretty nasty right now, but small
file write performance is insanely good. Even with all the debugging
console spew and other inefficiencies with the backend flushder, copying
the pkgsrc tree to a HAMMER partition is already competitive with
UFS+softupdates:
(tar cf - /usr/pkgsrc a few times to stabilize the NFS server)
/usr/bin/time -l cpdup /usr/pkgsrc/. /home/pkgsrc
208.94 real 4.35 user 32.25 sys
/usr/bin/time -l cpdup /usr/pkgsrc/. /mnt/pkgsrc
183.00 real 4.73 user 47.46 sys
umount /home
umount /mnt
mount /home
mount /mnt
/usr/bin/time -l rm -rf /home/pkgsrc
72.12 real 0.10 user 3.77 sys
/usr/bin/time -l rm -rf /mnt/pkgsrc
73.37 real 0.23 user 13.12 sys
I expect to be able to drop those times a lot more before I'm done.
The large-file write performance issue is just an implementation issue.
Because data is not overwritten it is possible for the frontend to
directly allocate media space and issue the data portion of the writes
directly to the media, only queueing the meta-data portion to the backend.
But I don't do that yet, and right now the backend synchronizer is
being woken up way, way too often due to the data buffer load.
Please note that HAMMER spews a lot of junk to the console at the
moment, too. This is getting rather exciting!
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
