"HAMMER is going to be a little unstable as I commit the crash recovery code," began DragonFly BSD creator Matthew Dillon, adding, "I'm about half way through it." He went on to list what's left for crash recovery to work with HAMMER, his new clustering filesystem, "I have to flush the undo buffers out before the meta-data buffers; then I have to flush the volume header so mount can see the updated undo info; then I have to flush out the meta-data buffers that the UNDO info refers to; and, finally, the mount code must scan the UNDO buffers and perform any required UNDOs." He continued:
"The idea being that if a crash occurs at any point in the above sequence, HAMMER will be able to run the UNDOs to undo any partially written meta-data. HAMMER would be able to do this at mount-time and it would probably take less then a second, so basically this gives us our instant crash-recovery feature."
Matt went on to add that as an advantage of significantly separating the front end VFS operations from the backend I/O it would now be possible to fix several stalls in the code, significantly improving HAMMER's performance.
From: Matthew Dillon
Subject: HAMMER update 24-Apr-2008
Date: Apr 24, 2:57 pm 2008
HAMMER is going to be a little unstable as I commit the crash
recovery code. I'm about half way through it. Meta-data updates
to the disk media have now been separated out. I have a few things
left to do before crash recovery will actually work:
* I have to flush the undo buffers out before the meta-data buffers
* Then I have to flush the volume header so mount can see the updated
undo info.
* Then I have to flush out the meta-data buffers that the UNDO
info refers to.
* And, finally, the mount code must scan the UNDO buffers and perform
any required UNDOs.
The idea being that if a crash occurs at any point in the above
sequence, HAMMER will be able to run the UNDOs to undo any partially
written meta-data. HAMMER would be able to do this at mount-time and
it would probably take less then a second, so basically this gives us
our instant crash-recovery feature.
One interesting outcome of the separation work I just committed is
that the frontend VOPs are *massively* disconnected from backend disk
I/O now. In coming weeks I hope to take advantage of this separation
to remove the remaining stalls and significantly improve HAMMER's
performance.
-Matt
File system journal?
So why not call it a journal like every other file system developer does?
It does not appear to keep a
It does not appear to keep a journal.
DragonflyBSD
Speaking of Dragonfly, I believe the key difference from Free is the use of a more conservative threading/process model. From what I've seen from the version 7 benchmarks, FreeBSD did a very good job of integrating the new model. Apache and MySQL performance is up, which is that I personally care the most about.
Has it not been proven that the new model was a good one? Will the Dragonfly fork potentially close? Will HAMMER be ported to FreeBSD?
update