[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


gleixner@xxxxxxx.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.  


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


To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com