Filesystem Journaling Update II - July 2005

[Matthew Dillon]

:
: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
    by userland.

    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.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>