diff options
| author | Shaun Zinck <shaun.zinck@gmail.com> | 2007-10-20 02:38:36 +0200 |
|---|---|---|
| committer | Adrian Bunk <bunk@kernel.org> | 2007-10-20 02:38:36 +0200 |
| commit | 7356337bd2d4416bcaa0158520542dfbd154949c (patch) | |
| tree | 98e72abfb208cc95cfb261331c973462059657c4 /Documentation/filesystems | |
| parent | 59dd24d32cb379d8c2b9028dcea4ec951633eaf4 (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/filesystems')
| -rw-r--r-- | Documentation/filesystems/ext3.txt | 14 |
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 ------------- |