Differences

This shows you the differences between two versions of the page.

--- gjournal [2005/08/01 22:23] – Some clarifications IvanVoras
+++ gjournal [2020/12/27 06:45] (current) – Remove 3 broken hyperlinks. SashaVigole
@@ Line 1: / Line 1: @@
-This is a [[SummerOfCode2005|SummerOfCode2005]] project. 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.
-:?: //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.
+:!: Note: Unfortunately, gjournal cannot replace a journaling filesystem. At least, a fsck is still needed on the journaled device/filesystem after a crash.
-:!: All information present on this page is ephemeral and unfinished. The end result of the project might be implemented in a totally different way.
+:?: //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 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:
+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.
+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.
-:?: 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.
+:?: 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 =====
@@ Line 21: / Line 29: @@
   * "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 label mydevice /dev/data_disk /dev/journal_disk%%''
   * ''%%gjournal destroy mydevice%%''
@@ Line 27: / Line 35: @@
   * ''%%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 are:
+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)