[PATCH] [MTD] NAND : SFTL (Simple Flash Transration Layer)

[katsuki.uwatoko at toshiba.co.jp]

Hi Artem,

Thank you for the information and the advice. I will re-design it.

> > SFTL is a flash translation layer for NAND Flash on mtd_blkdevs
> > interface.  This is mainly-useful for read-oriented use (ex. a storage
> > for a boot image) because this provides simple wear-leveling and
> > scrubbing. The features are:
> > 
> >  * sftl provides wear-leveling (not static wear-leveling) and scrubbing.
> >  * sftl has one erase block size cache.
> >  * sftl uses 6 bytes in OOB for a logical address, status, version.
> 
> This is really bad idea nowadays, because modern flashes tend to use
> whole OOB for bad block handling. Or they may disallow writing to OOB
> because they cannot handle a write to OOB after a write to the page.
> 
> On top of this, modern flashes are so crappy that they have bit-flips
> all the time, and need strong ECCs (like 8-bit or more). But the OOB
> area is not covered by ECC, so your data in OOB will constantly become
> corrupted.
>
> I really suggest to re-design this.

I understood it and agree with that. I have to move the data of an erase
block to data area from OOB.  But I think that even nowadays, 
there are not a few NANDs which has ECC data on OOB to be trusted.

> Could you please present your work in more details. Could you please
> describe:

I would like to explain about your questions/comments.  
If I misunderstood something, please let me know.

We would like to use a block device on NAND as a storage for boot image. 
It includes compressed filesystem image and/or Linux Kernel. 
And the most important purpose of this driver is making the boot fast. 

> 1. Which problems this solves.

Compared mtdblock+gluebi+ubi,

1st, currently time of the sftl initial time (insmod time) is faster 
than ubi. The time is so important for us because a boot time depends 
on this.
 
The following is the result of insmod time on our target board.
(The NAND read performance of our target board may not be good.)

NAND : 256MB SLC, Large Size Page (2KB), Erase Block Size 128KB
       w/o subpage write 
MTD Partition Size : 16MB, 32MB, 256MB

	sftl	ubi
------------------------
32MB	 30msec	 160msec	 	
64MB	 40msec	 290msec
256MB	150msec 1070msec
------------------------

2nd, as I wrote already, the flash overhead is smaller than ubi.

> 2. What are the practical use-cases.

A boot image including compressed read-only filesystem (squashfs) is 
stored in a MTD partition of NAND Flash. 
All of the image is read to memory at system booting from NAND and 
it on memory is mounted at boot. Or it in NAND flash directly is 
mounted.

This means that it is normally read-only except update and the time
of reading from NAND affects boot time.

> 3. What are alternative existing solutions, why they are not good enough
>    and why this solution is better.
> 4. Explain why it is not possible to teach UBI to solve these tasks.
>    E.g., introduce a special "simplified" UBI mode with 1-1 mapping / no
>    erase counters / whatever. In other words, provide good grounds for
>    adding a separate module.

I heard that currently the optimization of UBI scan time is in progress.
It might be enough but currently I do not know how much fast it is.
I should investigate details of it. 

I think sftl would be close to sm_ftl in Linux MTD. But this driver 
depends on the specification of SMART media like small page size NAND, 
the size of logical address is 2 bytes (ZONE addressing) and so on.
So I think we should not modify this driver.

Thank you,
-- 
UWATOKO Katsuki