DragonFly kernel List (threaded) for 2008-04
DragonFly BSD
DragonFly kernel List (threaded) for 2008-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

HAMMER update 26-Apr-2008


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 26 Apr 2008 12:40:12 -0700 (PDT)

    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 
					<dillon@backplane.com>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]