From patchwork Sat Dec 20 02:38:25 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Brian Norris X-Patchwork-Id: 423029 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id E02B6140082 for ; Sat, 20 Dec 2014 13:40:55 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1Y29wp-000755-N1; Sat, 20 Dec 2014 02:39:15 +0000 Received: from mail-pd0-x22e.google.com ([2607:f8b0:400e:c02::22e]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Y29wd-0006yo-4I for linux-mtd@lists.infradead.org; Sat, 20 Dec 2014 02:39:07 +0000 Received: by mail-pd0-f174.google.com with SMTP id fp1so2303850pdb.5 for ; Fri, 19 Dec 2014 18:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=33z/Fb4ULzrYqgqPo9GqFCJ3x0VToLJFQ24fSDMcJDY=; b=SwEOK11vyNtjtjceNnxemfMsMkBzJxdKVNmSv3LN2MKitVVoyQB+LefseHFkiEckL4 T8Q52ZWmUqg45p9rP4ZcnuXIJIyvdjZisrjOpTXtebVd4xhlZd992j8XStAsfATxnrMR OZ+q75FiQbgDncOMM5GPjNVJAH14y4QGF5WisDw24/AfuzbOH/UguEmsxR+H62SBNqhz ZXmIsP817YTIHyvVoHRrnmmc9O1gWv2RZycTC5qrATSgZWcMLbS5DbzWeOtFe6r1vW0n hPMbhNiO+Q3i3hy0bIvg6zMLRp5e/BjLAGn+ndcYyqPEtXnK1hQaQQJrwXZUeQgjxdRz x9og== X-Received: by 10.70.38.71 with SMTP id e7mr17283232pdk.130.1419043120985; Fri, 19 Dec 2014 18:38:40 -0800 (PST) Received: from ld-irv-0074.broadcom.com (5520-maca-inet1-outside.broadcom.com. [216.31.211.11]) by mx.google.com with ESMTPSA id pe8sm10812516pdb.60.2014.12.19.18.38.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 19 Dec 2014 18:38:40 -0800 (PST) From: Brian Norris To: Subject: [PATCH mtd-www 3/4] doc / faq: spelling, grammar, etc. Date: Fri, 19 Dec 2014 18:38:25 -0800 Message-Id: <1419043106-16453-3-git-send-email-computersforpeace@gmail.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1419043106-16453-1-git-send-email-computersforpeace@gmail.com> References: <1419043106-16453-1-git-send-email-computersforpeace@gmail.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20141219_183903_277826_0528FB1E X-CRM114-Status: GOOD ( 19.19 ) X-Spam-Score: -0.8 (/) X-Spam-Report: SpamAssassin version 3.4.0 on bombadil.infradead.org summary: Content analysis details: (-0.8 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [2607:f8b0:400e:c02:0:0:0:22e listed in] [list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (computersforpeace[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain Cc: Brian Norris , David Woodhouse , Artem Bityutskiy X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Signed-off-by: Brian Norris --- doc/ubi.xml | 10 +++++----- doc/ubifs.xml | 2 +- faq/nand.xml | 2 +- faq/ubi.xml | 6 +++--- faq/ubifs.xml | 14 +++++++------- 5 files changed, 17 insertions(+), 17 deletions(-) diff --git a/doc/ubi.xml b/doc/ubi.xml index 5cb160306c61..3192fbce3144 100644 --- a/doc/ubi.xml +++ b/doc/ubi.xml @@ -535,7 +535,7 @@ amount of flash space available for UBI users. Namely:

type and is explained below. -

Lets introduce symbols:

+

Let's introduce symbols:

  • W - total number of physical eraseblocks on the flash @@ -665,10 +665,10 @@ which might be difficult to debug later. So we recommend to always do this.

    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 0xFF'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 0xFF bytes.

    +from the fourth one as free, and will write data there. If the flasher program +has already written 0xFF'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 0xFF bytes.

    To put it differently, writing 0xFF bytes may have side-effects. What the flasher has to do is to drop all empty NAND pages from the end of the diff --git a/doc/ubifs.xml b/doc/ubifs.xml index 44405d67aec5..c1f54b54744f 100644 --- a/doc/ubifs.xml +++ b/doc/ubifs.xml @@ -666,7 +666,7 @@ NOTES

    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.

    However, some (perhaps not very good) user-space programmers do not take diff --git a/faq/nand.xml b/faq/nand.xml index e142de88a4c8..05f0fbf09f65 100644 --- a/faq/nand.xml +++ b/faq/nand.xml @@ -92,7 +92,7 @@ necessary before you copy a filesystem image to the chip.

    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 mtd-utils package.

    diff --git a/faq/ubi.xml b/faq/ubi.xml index e20786203005..9b2165def9c3 100644 --- a/faq/ubi.xml +++ b/faq/ubi.xml @@ -501,7 +501,7 @@ Why does ubiattach on a freshly formatted device fail with "Invalid argument"?

    On NAND devices that support sub-page accesses, ubiformat may choose a different location for the -VID header to the kernel UBI driver +VID header to the kernel UBI driver. This can result in the following error when attaching to a UBI device:

    @@ -559,7 +559,7 @@ ubi.mtd=0,2048
 
 
    What is a sub-page?
    
 
-
    Please, refer this section.
    
+
    Please, refer to this section.
    
 
 
 
@@ -857,7 +857,7 @@ is a similar table for UBI.
    
 
    Extra self-checks
    
 
 
    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
 UBIFS self-checks
 section for more information, because UBI extra self-checks are very
 similar, just a bit simpler. Here is a similar table for UBI.
    
diff --git a/faq/ubifs.xml b/faq/ubifs.xml
index 0274b52958d5..8b61fc741967 100644
--- a/faq/ubifs.xml
+++ b/faq/ubifs.xml
@@ -188,7 +188,7 @@ by running the mtdinfo
 tool with -u parameter. Of course, the tool has to be run on
 the target system.
    
 
-
    Please, refer this for more
+
    Please, refer to this for more
 information about how to find these parameters.
    
 
 
    And optionally, you should decide which compression algorithm you want
@@ -264,7 +264,7 @@ vol_flags=autoresize

The ubinize utility requires volumes description file. Please, -refer this section for more +refer to this section for more ubinize usage information.

In the example, the ubinize.cfg file tells ubinize @@ -628,7 +628,7 @@ provably want the file-system doing inode updates every time they are read.

Does UBIFS support NFS?

-

Not, it does not, which means you cannot export UBIFS file-system via NFS. +

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 this thread @@ -682,15 +682,15 @@ compression, write-back, space wastage at the end of logical eraseblocks, garbage-collection, etc. Please, refer this section for details.

-

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 +

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.

-

UBIFS also lies, but it always report less space that user may +

UBIFS also lies, but it always reports less 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).

Thus, the only way to find out precise amount of free space is to