From: Thomas Gleixner <gleixner@autronix.de>
To: David Woodhouse <dwmw2@infradead.org>, gleixner@autronix.de
Cc: linux-mtd@lists.infradead.org, jffs-dev@axis.com
Subject: Re: JFFS2 & NAND
Date: Thu, 14 Feb 2002 18:43:35 +0100 [thread overview]
Message-ID: <02021418433508.29375@thomas> (raw)
In-Reply-To: <1035.1013707668@redhat.com>
On Thursday, 14. February 2002 18:27, David Woodhouse wrote:
> gleixner@autronix.de said:
> I'm sorry I haven't been particularly responsive for the last few days.
> It's not that I'm not interested, more that the last few days included 24
> hours in a tin can coming back from linux.conf.au and I don't think I'm
> awake enough yet to attempt it :)
Ok no problem, i was a little bit irritated, that a lot of other issues were
answered and did not know, why the discussion was broken. So this was only a
well meant wakeup call.
I Include my latest statement on this, to have this new thread up to date.
Actual state of JFFS2 on NAND
I implemented a new structure into nand_chip structure, which describes the
usage of the oob area. You can read and modify this structure from the
filesystem driver via two functions, which i have implemented into the mtd
structure. (get_oobcfg, set_oobcfg).
The mtd_oob_config structure is:
/* configuration for out of band data (NAND,DOC...) */
struct mtd_oob_config {
int oob_size; /* size of out of band area */
int ecc_pos[6]; /* position of ECC bytes inside oob */
int badblock_pos; /* position of bad block flag inside oob -1
= inactive */
int eccvalid_pos; /* position of ECC valid flag inside oob -1
= inactive */
int fsdata_pos; /* position to store filesystem specific
information */
int fsdata_len; /* length available for filesystem specific
data */
};
With this structure we can decide at mount time, which scheme we use. Either
the fs driver modifies it to match it's requirements or the fs driver uses
the information given by the device driver. At the moment i use the
information given by the device driver.
I have now fixed the most NAND related FIXME's inside JFFS2, except the
problem with wbuf_flush fail. The cleanmarker in the oob area and the bad
block marking is working pretty good. I modified the scan routine to collect
bad block information. I have a old SmartMediaCard, which has bad blocks on
it. The information is collected correct. Then I erased one of the bad blocks
and destroyed the bad block flag. When gc erased this block again it was
detected as bad (not totaly erased) and marked bad again.
I ran some stress tests on the filesystem and encountered no serious problem,
except when i used a wornout old SMCard from a digicam i ran into the
flush_wbuf bug.
Thomas
__________________________________________________
Thomas Gleixner, autronix automation GmbH
auf dem berg 3, d-88690 uhldingen-muehlhofen
fon: +49 7556 919891 , fax: +49 7556 919886
mail: gleixner@autronix.de, http://www.autronix.de
next prev parent reply other threads:[~2002-02-14 17:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-14 15:57 JFFS2 & NAND Thomas Gleixner
2002-02-14 17:22 ` Peter De Schrijver
2002-02-14 17:27 ` David Woodhouse
2002-02-14 17:43 ` Thomas Gleixner [this message]
2002-02-17 9:51 ` David Woodhouse
2002-02-17 11:44 ` Thomas Gleixner
2002-02-17 17:25 ` David Woodhouse
2002-02-17 19:36 ` Thomas Gleixner
2002-02-18 8:48 ` Thomas Gleixner
2002-02-18 8:46 ` David Woodhouse
2002-02-18 9:26 ` Thomas Gleixner
2002-02-18 9:29 ` David Woodhouse
2002-02-18 9:48 ` Thomas Gleixner
2002-02-18 16:02 ` Thomas Gleixner
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=02021418433508.29375@thomas \
--to=gleixner@autronix.de \
--cc=dwmw2@infradead.org \
--cc=jffs-dev@axis.com \
--cc=linux-mtd@lists.infradead.org \
/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