public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: gleixner@autronix.de
Cc: linux-mtd@lists.infradead.org, jffs-dev@axis.com
Subject: Re: JFFS2 & NAND
Date: Sun, 17 Feb 2002 09:51:15 +0000	[thread overview]
Message-ID: <7814.1013939475@redhat.com> (raw)
In-Reply-To: <02021418433508.29375@thomas>

gleixner@autronix.de said:
> 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).

I'm slightly concerned that this may be overkill. The JFFS2 code has to
recognise certain types of hardware and arrange its own data in the spare
area accordingly. Does it really need to make that information available, or
just do its own thing? Is the existing mtd->{oobblock,oobsize,ecctype}
really not sufficient?


> 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.  

Excellent. 

>  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. 

OK, let's work on getting your current changes merged, then we can deal 
with the wbuf_flush failure handling. Can you send me a patch against the 
current CVS tree -- I don't think I've changed anything on the 
jffs2-nand-branch recently (since the 5th of February in fact).

--
dwmw2

  reply	other threads:[~2002-02-17  9:40 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
2002-02-17  9:51     ` David Woodhouse [this message]
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=7814.1013939475@redhat.com \
    --to=dwmw2@infradead.org \
    --cc=gleixner@autronix.de \
    --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