DragonFly kernel List (threaded) for 2005-07
Re: Filesystem Journaling Update II - July 2005
:Matthew Dillon wrote:
:> .....This is about
:> a 7% performance penalty, which is quite reasonable considering what
:> you get for the trouble....
:I should say so!
:Because I don't pretend to understand the technical details of what you have
:done with journalling I'm a bit fuzzy about how much of this work depends on
:your prior work with LWKT, messaging, and such.
:IOW, could this same journalling mechanism be used in FBSD or NBSD
:with a bit of hackery? Or not.
Basically what our high-level journaling is is a VFS layer inbetween
the kernel and the filesystem. It takes the VFS operation and
constructs a data record to represent the transaction. The data
record is injected into an in-memory FIFO (it's actually constructed
in-place in the FIFO buffer) and a kernel thread then takes the data
off the FIFO and writes it out to the journaling descriptor supplied
The in-memory FIFO has a limited size, which means that the filesystem
operation will stall if the FIFO fills up. The vast majority of
VFS operations... pretty much everything except a file copy, are
fairly small and the performance penalty is roughly similar to that of
a bcopy(). The back-end thread only wakes up once a second or if the
FIFO gets over half full so the overhead is typically very low. Large
volumes of data will of course create a far more significant penalty.
Copying a large data file, for example.
I don't think any of the other BSDs could adopt our journaling layer
without also adopting most of the VFS work I've done over the last year
and a half. It would be a huge job. Without the namecache and API work
it would not be possible to tag the journaling records properly or
guarentee transactional consistency or even feed the VFS operations
through the new layer safely. In short: you won't ever see this in any
of the other BSDs.