This is an old revision of the document!
This is a SummerOfCode2005 project. 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.
2005-08-03 first public alpha version is available at http://ivoras.sharanet.org/gjournal.tgz
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.
All information present on this page is ephemeral and unfinished. The end result of the project might be implemented in a totally different way.
The current plan for the journal disk format is that for each IO write request (consisting of 1 data block) this is written 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.
Another journal format was considered (and is actually implemented as alternative) in which one descriptor blocks contains information about several records, for space efficiency. BUT, 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
It's planned to make a userland control utility similar to those of gmirror, gstripe, graid3 etc. Some of the commands planned are:
gjournal label mydevice /dev/data_disk /dev/journal_diskgjournal destroy mydevicegjournal unjournal mydevice(temporarily stop journaling, commiting it before stopping)gjournal rejournal mydevice(start journaling again)gjournal commit mydevice(force a journal commit)
Some possible parameters that can be used 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 :)