[PATCH v3 00/10] About the SLC/MLC

Gupta, Pekon pekon at ti.com
Mon Oct 21 22:11:37 PDT 2013


> From:  Huang Shijie
> On Mon, Aug 26, 2013 at 02:41:53PM +0200, Thomas Petazzoni wrote:
> > Dear Huang Shijie,
> >
> > On Mon, 26 Aug 2013 17:36:38 +0800, Huang Shijie wrote:
> > > In current mtd code, the MTD_NANDFLASH is used to represent both the
> > > SLC nand MLC(including the TLC). But we already have the
> MTD_MLCNANDFLASH
> > > to stand for the MLC. What is worse is that the JFFS2 may run on the MLC
> > > nand with current code. For the reason of READ/WRITE disturbance, the
> JFFS2
> > > should runs on the SLC only,
> >
> > Pardon the probably very silly question, but would you mind giving more
> > details about why JFFS2 is not appropriate on MLC flashes? Is there
> > anything that UBI/UBIFS does that JFFS2 isn't doing to take into
> > account read/write disturbance?
> I try to explain it.
> 
> For the UBIFS, it will writes the page(including the oob) only one time;
> but for jffs2, it may writes the page(including the oob) twice, one for the
> marker, one for the real data.
> 
> For the MLC, the write disturbance will cause some bitflips in this
> page. Since you write a page twice, so in the jffs2, you will meet
> uncorrectable
> ECC error.
> 
But, doesn't JFFS2 checks for the blank page before second-write of data ?
UBI does it here..
File: $KERNEL/drivers/mtd/ubi/io.c
@@ubi_io_write (... )
[...]
	err = ubi_self_check_all_ff(ubi, pnum, offset, len);

So, isn't it better to add this check in JFFS2 code so that its more
bit-flips tolerant ?
This way bit-flips caused by first write to OOB (cleanmarker) would be
caught before using that page for data write. And so MLC should also be
good for JFFS2..

with regards, pekon



More information about the linux-mtd mailing list