summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorShaun Zinck <shaun.zinck@gmail.com>2007-10-20 02:38:36 +0200
committerAdrian Bunk <bunk@kernel.org>2007-10-20 02:38:36 +0200
commit7356337bd2d4416bcaa0158520542dfbd154949c (patch)
tree98e72abfb208cc95cfb261331c973462059657c4 /Documentation
parent59dd24d32cb379d8c2b9028dcea4ec951633eaf4 (diff)
documentation/ext3: grammar fixes
Fix some grammar in the explanation of the Journal Block Device layer. Signed-off-by: Shaun Zinck <shaun.zinck@gmail.com> Acked-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Adrian Bunk <bunk@kernel.org>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/filesystems/ext3.txt14
1 files changed, 7 insertions, 7 deletions
diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt
index 4aecc9bdb273..b45f3c1b8b43 100644
--- a/Documentation/filesystems/ext3.txt
+++ b/Documentation/filesystems/ext3.txt
@@ -130,12 +130,12 @@ Device layer.
Journaling Block Device layer
-----------------------------
-The Journaling Block Device layer (JBD) isn't ext3 specific. It was design to
-add journaling capabilities on a block device. The ext3 filesystem code will
-inform the JBD of modifications it is performing (called a transaction). The
-journal supports the transactions start and stop, and in case of crash, the
-journal can replayed the transactions to put the partition back in a
-consistent state fast.
+The Journaling Block Device layer (JBD) isn't ext3 specific. It was designed
+to add journaling capabilities to a block device. The ext3 filesystem code
+will inform the JBD of modifications it is performing (called a transaction).
+The journal supports the transactions start and stop, and in case of a crash,
+the journal can replay the transactions to quickly put the partition back into
+a consistent state.
Handles represent a single atomic update to a filesystem. JBD can handle an
external journal on a block device.
@@ -164,7 +164,7 @@ written to the journal first, and then to its final location.
In the event of a crash, the journal can be replayed, bringing both data and
metadata into a consistent state. This mode is the slowest except when data
needs to be read from and written to disk at the same time where it
-outperforms all others modes.
+outperforms all other modes.
Compatibility
-------------