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

[Artem Bityutskiy]

On Wed, 2011-12-14 at 07:03 +0000, katsuki.uwatoko at toshiba.co.jp wrote:
> This is a new Flash Translation Layer for NAND Flash on mtd.
> 
> mtd: SFTL (Simple Flash Translation Layer)
> 
> Introduction
> ------------
> 
> 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.

>  * the erase block scan at init is fast.
>  * a unit of read/write from/to MTD is an erase block.
> 
> Module parameters
> -----------------
> 
>   mtd=		MTD devices to attach.
> 		Parameter format: mtd=<num>
> 		Multiple mtd parameters may be specified.
> 
>   rb=		percents of reserved eraseblocks for bad blocks.
> 		This parameter must be from 1 to 90. The default is 2.
> 		The number of reserved blocks must be more than 5.

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

1. Which problems this solves.
2. What are the practical use-cases.
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.

Your really need to spend some time and prepare your strategy for
selling this to upstream.

Thanks!

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20111217/a651a9af/attachment.sig>