From: Artem Bityutskiy <dedekind1@gmail.com>
To: katsuki.uwatoko@toshiba.co.jp
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] [MTD] NAND : SFTL (Simple Flash Transration Layer)
Date: Sat, 17 Dec 2011 18:13:10 +0200 [thread overview]
Message-ID: <1324138390.4240.69.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <4CCCBA2E6B78F3katsuki.uwatoko@toshiba.co.jp>
[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]
On Wed, 2011-12-14 at 07:03 +0000, katsuki.uwatoko@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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2011-12-17 16:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-14 7:03 [PATCH] [MTD] NAND : SFTL (Simple Flash Transration Layer) katsuki.uwatoko
2011-12-14 9:29 ` Matthieu CASTET
2011-12-15 11:38 ` katsuki.uwatoko
2011-12-17 16:13 ` Artem Bityutskiy [this message]
2011-12-22 10:38 ` katsuki.uwatoko
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=1324138390.4240.69.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=katsuki.uwatoko@toshiba.co.jp \
--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