type and is explained below.</li>
</ul>
-<p>Lets introduce symbols:</p>
+<p>Let's introduce symbols:</p>
<ul>
<li><i>W</i> - total number of physical eraseblocks on the flash
For example, suppose the first NAND page of a PEB has some data, the second one
is empty, the third one also has some data, the fourth one and the rest of NAND
pages are empty as well. In this case UBIFS will treat all NAND pages starting
-from the fourth one as free, and will write data there. However, if the flasher
-program has already written <code>0xFF</code>'s to these pages, so they will be
-written to twice! However, many NAND flashes require NAND pages to be written
-only once, even if the data contains only <code>0xFF</code> bytes.</p>
+from the fourth one as free, and will write data there. If the flasher program
+has already written <code>0xFF</code>'s to these pages, then any new UBIFS data
+will cause a second write. However, many NAND flashes require NAND pages to be
+written only once, even if the data contains only <code>0xFF</code> bytes.</p>
<p>To put it differently, writing <code>0xFF</code> bytes may have side-effects.
What the flasher has to do is to drop all empty NAND pages from the end of the
</pre>
<p>This is true for UBIFS (except of the "some buggy implementations" part,
-because UBIFS does reserves space for cached dirty data). This is also true for
+because UBIFS does reserve space for cached dirty data). This is also true for
JFFS2, as well as for any other Linux file system.</p>
<p>However, some (perhaps not very good) user-space programmers do not take
<P>
Technically yes, as long as this MTD partition does not contain bad blocks. But
-it is generally a bad idea. For bad block aware copying, batter use nandwrite
+it is generally a bad idea. For bad block aware copying, use nandwrite
from the <CODE>mtd-utils</CODE> package.
</P>
<p>On NAND devices that support sub-page accesses, <code>ubiformat</code>
may choose a different location for the
-<a href="../doc/ubi.html#L_ubi_headers">VID header</a> to the kernel UBI driver
+<a href="../doc/ubi.html#L_ubi_headers">VID header</a> to the kernel UBI driver.
This can result in the following error when attaching to a UBI device:</p>
<pre>
<h2><a name="L_subpage">What is a sub-page?</a></h2>
-<p>Please, refer <a href="../doc/ubi.html#L_subpage">this</a> section.</p>
+<p>Please, refer
to <a href="../doc/ubi.html#L_subpage">this</a> section.</p>
<h3>Extra self-checks</h3>
<p>UBI contains various internal self-check functions which are often
-very useful for debugging or testing. Please, refer the corresponding
+very useful for debugging or testing. Please, refer to the corresponding
<a href="ubifs.html#L_how_debug_self_checks">UBIFS self-checks</a>
section for more information, because UBI extra self-checks are very
similar, just a bit simpler. Here is a similar table for UBI.</p>
tool with <code>-u</code> parameter. Of course, the tool has to be run on
the target system.</p>
-<p>Please, refer <a href="ubi.html#L_find_min_io_size">this</a> for more
+<p>Please, refer
to <a href="ubi.html#L_find_min_io_size">this</a> for more
information about how to find these parameters.</p>
<p>And optionally, you should decide which compression algorithm you want
</ul>
<p>The <code>ubinize</code> utility requires volumes description file. Please,
-refer <a href="ubi.html#L_ubi_mkimg">this</a> section for more
+refer
to <a href="ubi.html#L_ubi_mkimg">this</a> section for more
<code>ubinize</code> usage information.</p>
<p>In the example, the <code>ubinize.cfg</code> file tells <code>ubinize</code>
<h2><a name="L_nfs">Does UBIFS support NFS?</a></h2>
-<p>Not, it does not, which means you cannot export UBIFS file-system via NFS.
+<p>No, it does not, which means you cannot export UBIFS file-systems via NFS.
We did make an attempt to support NFS, but the support was not exactly correct
so it was dropped, and we have never found time to come back to that. Please,
refer to <a href="http://marc.info/?l=linux-next&m=121852228611051&w=2">this thread</a>
garbage-collection, etc. Please, refer
<a href="../doc/ubifs.html#L_spaceacc">this</a> section for details.</p>
-<p>Note, JFFS2 also has problems with free space predictions, but in average,
-it reports much more accurate amount of free space. However, JFFS2 may lie and
+<p>Note, JFFS2 also has problems with free space predictions, but on average,
+it reports free space much more accurately. However, JFFS2 may lie and
report more free space than it actually has. For example, we experienced
situations when JFFS2 reported 8MiB free space, while we were able to write
only 2 MiB of data. This makes some user-space applications very unhappy.</p>
-<p>UBIFS also lies, but it always report <i>less</i> space that user may
+<p>UBIFS also lies, but it always reports <i>less</i> space than the user may
actually write. For example, it may report 2MiB of free space, but if you
-start writing to it, may be able to write 4MiB there (even if you have
+start writing to it, you may be able to write 4MiB (even if you have
compression disabled).</p>
<p>Thus, the only way to find out <i>precise</i> amount of free space is to
projects / mtd-www.git / commitdiff