From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ipmail04.adl2.internode.on.net ([203.16.214.57]) by bombadil.infradead.org with esmtp (Exim 4.68 #1 (Red Hat Linux)) id 1K8kyK-0007rV-UY for linux-mtd@lists.infradead.org; Tue, 17 Jun 2008 23:52:22 +0000 Message-ID: <48584DE9.3000709@call-direct.com.au> Date: Wed, 18 Jun 2008 09:51:05 +1000 From: Iwo Mergler MIME-Version: 1.0 To: Matthieu CASTET Subject: Re: [BUG] JFFS2 power loss recovery issues on NAND References: <48570D5A.1050906@call-direct.com.au> <48577212.9070004@parrot.com> In-Reply-To: <48577212.9070004@parrot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dwmw2@infradead.org, joern@logfs.org, linux-mtd@lists.infradead.org, Alexey Korolev List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Matthieu CASTET wrote: > Iwo Mergler wrote: >> Alexey Korolev wrote: >>> >> Alexey, >> >> I know of at least one hardware ECC implementation which can flag >> errors within the ECC bytes separately. In other words, not all >> implementations >> will detect/correct bit errors in the case of a ECC write error. >> >> About how to fix it - what about making the reading without ECC the >> default >> and only re-reading with ECC if JFFS2 finds an invalid checksum? >> > But what happen if a but flip happen ? > If we do this, ecc won't correct it, the error can happen everywhere > not only in checksum, for example wrong nodetype. Forgive my ignorance - does that mean that not everything in JFFS2 is CRC protected? If that is the case, forget my suggestion. I don't know JFFS2 that intimately. :-) Kind regards, Iwo