• gjournal

Note: This is a SummerOfCode2005 project. Pawel (pjd) has reimplemented gjournal with hooks in the file system code so it can properly do file system journaling. See http://docs.freebsd.org/cgi/mid.cgi?20060619131101.GD1130 for details. This has effectively made the version of gjournal described here obsolete - please use the new version. This page is retained for historical purposes.

Here's the original gjournal_proposal. Many technical information and details of the plan can be found in it.

Gjournal is a layer in the GEOM hierarchy that consumes two lower-layer devices and produces one device. The two lower-layer devices are called data disk and journal disk. The data disk is self-sufficient and (eventually) contains verbatim data that's handled to the layer, so after the journal is disconnected it in itself can be used as a normal storage device. The journal disk contains linear records for every write request handled to the layer.

Note: Unfortunately, gjournal cannot replace a journaling filesystem. At least, a fsck is still needed on the journaled device/filesystem after a crash.

2005-09-01 final version is available at http://ivoras.sharanet.org/stuff/gjournal-beta3.tgz ! The only reason I'm calling it "beta" is that it didn't receive much testing yet. For all intents and purposes, this is the "release" version.

2005-08-14 feature-complete beta version is available at http://ivoras.sharanet.org/stuff/gjournal-beta.tgz - it is announced at current@ list. Be sure to read the README file!

2005-08-03 first public alpha version is available at http://ivoras.sharanet.org/stuff/gjournal.tgz - it's announced at hackers@ list.

2005-08-01 The work is progressing nicely, basic journaling works currently. The code needs to be cleaned up a lot (especially the parts using various locks) and a lot of features need to be implemented. Initial simple performance benchmarks show that it has the potential to be actually pretty fast.

The "speed-optimized" journal disk format for each IO write request (consisting of 1 data block) writes to the journal:

• 1 "descriptor" block, containing information such as disk offsets and sizes for the requests
• 1 verbatim data block

A record map is kept to keep track of which bits of information is stored where. Journal device is internally divided into two areas, one fills while other commits.

The "space-optimized" format is similar to the previously described, but one descriptor block contains information about several records, for space efficiency. It has proven to be significantly slower because it requires constant seekeing to maintain it current.

Deliverables

Gjournal will provide a "stable" data journal. There will be two usage modes:

• "regular" journaling, with records committed to data disk when the journal gets full
• "copy-on-write" (or "delayed-commit") mode

The kernel module is controlled similar to gmirror, gstripe, graid3 etc. - with the "geom journal" or "gjournal" utility. Some of the commands implemented are:

• gjournal label mydevice /dev/data_disk /dev/journal_disk

• gjournal destroy mydevice

• gjournal unjournal mydevice (temporarily stop journaling, commiting it before stopping)

• gjournal rejournal mydevice (start journaling again)

• gjournal commit mydevice (force a journal commit)

• gjournal rollback mydevice (discard journal content)

Some possible parameters that can be used in "label" command are:

• -m journal|cow - make a regular journal (default) or COW journal

• -o speed|space - optimize journaling for speed or space taken on the journal device (optional implementation)

Bits and pieces of information:

• Gjournal will enforce that both data disk and journal disk have same-sized sectors. This size will be advertized as the gjournal device sector size

Tentative schedule

Serious work will begin somewhere around 2005-07-15, with first results probably available at 2005-08-15. Project finalization is expected sometime around 2005-09-01 (Google's rules. I'll probably continue working on it even after the date, but this is the date when it must be usable). Of course bughunting, being such an interesting sport, will continue probably forever