From: "Brian Norris" <norris@broadcom.com>
To: "pjohn@mvista.com" <pjohn@mvista.com>
Cc: "linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH] mtd-www doc, FAQ, general: spelling fixes
Date: Thu, 24 Jun 2010 09:41:48 -0700 [thread overview]
Message-ID: <4C238ACC.8050004@broadcom.com> (raw)
In-Reply-To: <1277387522.24980.6.camel@localhost.localdomain>
On 06/24/2010 06:52 AM, Philby John wrote:
>
>> Probably because you flash is too small? Try to use JFFS2 then, becasue it
> ^^^ ^^^^^
> You missed "you", should be "your", and "becasue".
>
> Regards,
> Philby
>
>
Thanks. Here's just a couple more missed edits.
Signed-off-by: Brian Norris <norris@broadcom.com>
---
faq/jffs2.xml | 4 ++--
faq/ubifs.xml | 14 +++++++-------
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/faq/jffs2.xml b/faq/jffs2.xml
index 1bc8680..a08af7a 100644
--- a/faq/jffs2.xml
+++ b/faq/jffs2.xml
@@ -277,8 +277,8 @@ There are two cases where this does not work. The first is when JFFS2 is used
as a root filesystem. For now, this requires the mtdblock device to be
specified for <CODE>root=</CODE> on the kernel command line. The second case is
when the mount binary that is being used does not play nicely with the above
-format. The busybox version of mount is known to not work without the mtdblock
-device.
+format. The BusyBox version of <CODE>mount</CODE> is known to not work without
+the mtdblock device.
</P>
diff --git a/faq/ubifs.xml b/faq/ubifs.xml
index 9dd5d3d..ea371f6 100644
--- a/faq/ubifs.xml
+++ b/faq/ubifs.xml
@@ -33,8 +33,8 @@
<li><a href="ubifs.html#L_ubifs_extract">How do I extract files from an UBI/UBIFS image?</a></li>
<li><a href="ubifs.html#L_powercut">Is UBIFS tolerant to power-cuts?</a></li>
<li><a href="ubifs.html#L_smaller_jrn">I need more space - should I make UBIFS journal smaller?</a></li>
- <li><a href="ubifs.html#L_empty_file">Why my file is empty after an unclean reboot?</a></li>
- <li><a href="ubifs.html#L_end_hole">Why my file has zeroes at the end after an unclean reboot?</a></li>
+ <li><a href="ubifs.html#L_empty_file">Why is my file empty after an unclean reboot?</a></li>
+ <li><a href="ubifs.html#L_end_hole">Why does my file have zeroes at the end after an unclean reboot?</a></li>
<li><a href="ubifs.html#L_bgt_thread">What does the "ubifs_bgt0_0" thread do?</a></li>
<li><a href="ubifs.html#L_sudden_ro">UBIFS suddenly became read-only - what is this?</a></li>
<li><a href="ubifs.html#L_detect_ro">How do I detect if UBIFS became read-only?</a></li>
@@ -986,12 +986,12 @@ size.</p>
<p>To put it simple, the amount of available space on UBIFS does not really
depend on the journal size. There is very weak dependency, though, because for
-bigger journal we need bigger log, but it is really something which does not
-make any noticeable difference.</p>
+a bigger journal we need a bigger log, but it really does not make a
+noticeable difference.</p>
-<h2><a name="L_empty_file">Why my file is empty after an unclean reboot?</a></h2>
+<h2><a name="L_empty_file">Why is my file empty after an unclean reboot?</a></h2>
<p>Zero-length files are a special case of corruption which happens when
an application first truncates a file, then updates it. The truncation is
@@ -1048,7 +1048,7 @@ to implement it.</p>
-<h2><a name="L_end_hole">Why my file has zeroes at the end after an unclean reboot?</a></h2>
+<h2><a name="L_end_hole">Why does my file have zeroes at the end after an unclean reboot?</a></h2>
<p>Power cuts often lead to holes at the end of files. Holes are areas of
the file which contain no data. For example, if you truncate a file to a larger
@@ -1176,7 +1176,7 @@ I get: "init_constants_early: too few LEBs (12), min. is 17"
</a></h2>
<p>This error means that you are trying to mount too small UBI volume.
-Probably because you flash is too small? Try to use JFFS2 then, becasue it
+Probably because your flash is too small? Try to use JFFS2, then, because it
suits small flashes better since it has much lower space overhead. Indeed,
UBIFS stores much more indexing information on the flash media than JFFS2, so
it has much higher overhead. Also, UBI has some overhead (see
--
1.7.1
next prev parent reply other threads:[~2010-06-24 16:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-23 22:42 [PATCH] mtd-www doc, FAQ, general: spelling fixes Brian Norris
2010-06-24 13:52 ` Philby John
2010-06-24 16:41 ` Brian Norris [this message]
2010-07-08 9:24 ` Artem Bityutskiy
2010-07-08 22:23 ` Brian Norris
2010-07-18 7:24 ` Artem Bityutskiy
2010-07-13 8:10 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C238ACC.8050004@broadcom.com \
--to=norris@broadcom.com \
--cc=linux-mtd@lists.infradead.org \
--cc=pjohn@mvista.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).