From: "Artem B. Bityuckiy" <dedekind@yandex.ru>
To: tglx@linutronix.de
Cc: linux-mtd@lists.infradead.org, Jarkko Lavinen <jarkko.lavinen@nokia.com>
Subject: Re: ECC errors on padded images
Date: Thu, 09 Dec 2004 13:38:22 +0300 [thread overview]
Message-ID: <41B82B1E.80503@yandex.ru> (raw)
In-Reply-To: <1102181689.13353.301.camel@tglx.tec.linutronix.de>
Thomas Gleixner wrote:
> On Sat, 2004-12-04 at 15:33 +0200, Jarkko Lavinen wrote:
>
>>I recently encountered ECC errors with padded JFFS2 images (mkfs.jffs2
>>-p) on Nand flash.
>>
>>The padded pages were written into flash with a driver which uses
>>noninverted ECC code. Pages with all bytes either 00 or FF will
>>produce 00s as ECC bytes.
>>
>>When JFFS2 scans such padded image, it fails to check the zero ECC
>>bytes of seemingly unused pages and will use them. Then the already
>>once written page is written again and later an ECC error is produced
>>upon read -- because ECC bytes remain zero.
>>
>>We have now three options:
>>
>>1. We couuld blame JFFS2, because it fails to check ECC bytes of
>> seemingly unused pages.
>>
>> But should JFFS2 care if somebody produces an image that JFFS2
>> would never produce by itself?
>>
>> JFFS2 itself won't pad erase blocks and won't write unused blank
>> pages. Even if writing a long node would result writing an all FF
>> page, JFFS2 would know in next mount from node header the page is
>> being used and not available for writing.
>>
>>
>>2. We could blame Mkfs.jffs2, because it is the one who produced
>> padded erase block. Without padding there would be no error.
>>
>>
>>3. We could blame the Ecc logic and insist that writing a blank, all
>> FF page will result ECC code of FFs and it would allow writing
>> first a blank page and then real data page.
>>
>> Conceptually an unused, erased page is not the same as used,
>> written blank page.
>
>
> 4. We could blame you, that you did not read the mail archive and found
> the thread discussing this problem and for not using the -p=YOURPAGESIZE
> option :)
>
> tglx
>
Anyway, mkfs.jffs2 should print this in help, IMHO. I was confused by
this either.
--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.
prev parent reply other threads:[~2004-12-09 10:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-04 13:33 ECC errors on padded images Jarkko Lavinen
2004-12-04 17:34 ` Thomas Gleixner
2004-12-09 10:38 ` Artem B. Bityuckiy [this message]
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=41B82B1E.80503@yandex.ru \
--to=dedekind@yandex.ru \
--cc=jarkko.lavinen@nokia.com \
--cc=linux-mtd@lists.infradead.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.