| Both sides previous revision Previous revision Next revision | Previous revision |
| gjournal [2005/06/28 18:16] – IvanVoras | gjournal [2020/12/27 06:45] (current) – Remove 3 broken hyperlinks. SashaVigole |
|---|
| Here's the original ["gjournal proposal"]. Many technical information and details of the plan can be found in it. | :!: **Note**: This is a [[SummerOfCode2005|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. | 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. |
| |
| :!: All information present on this page is ephemeral and unfinished. The end result of the project might be implemented in a totally different way. | :!: Note: Unfortunately, gjournal cannot replace a journaling filesystem. At least, a fsck is still needed on the journaled device/filesystem after a crash. |
| |
| The current plan for the journal disk format is that for several IO write requests (consisting of N data blocks total) this is written to the journal: | :?: //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 "descriptor" block, containing information such as disk offsets and sizes for the requests |
| * N verbatim data blocks | * 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. |
| |
| A list of descriptors for "live records" (those that need to be commited to data disk) is kept in memory to speed up journal replay and enable to mask-out old records that are overwritten by new ones (actual format in which the data is kept may or may not resemble a list :) ). This list is not written to journal but can be reconstructed from descriptor blocks if needed. | :?: 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 ===== | ===== Deliverables ===== |
| * "copy-on-write" (or "delayed-commit") mode | * "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: | 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 create mydevice /dev/data_disk /dev/journal_disk%%'' | * ''%%gjournal label mydevice /dev/data_disk /dev/journal_disk%%'' |
| * ''%%gjournal destroy mydevice%%'' | * ''%%gjournal destroy mydevice%%'' |
| * ''%%gjournal unjournal mydevice%%'' (temporarily stop journaling) | * ''%%gjournal unjournal mydevice%%'' (temporarily stop journaling, commiting it before stopping) |
| * ''%%gjournal rejournal mydevice%%'' (start journaling again) | * ''%%gjournal rejournal mydevice%%'' (start journaling again) |
| * ''%%gjournal commit mydevice%%'' (force a journal commit) | * ''%%gjournal commit mydevice%%'' (force a journal commit) |
| | * ''%%gjournal rollback mydevice%%'' (discard journal content) |
| |
| Some possible parameters that can be used are: | Some possible parameters that can be used in "label" command are: |
| * ''%%-m journal|cow%%'' - make a regular journal (default) or COW journal | * ''%%-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) | * ''%%-o speed|space%%'' - optimize journaling for speed or space taken on the journal device (optional implementation) |
| ===== Tentative schedule ===== | ===== 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-15. Of course bughunting, being such an interesting sport, will continue probably forever :) | 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 :) |
| |