From: Artem Bityutskiy <dedekind1@gmail.com>
To: Emmanuel Michon <emmanuel.michon@polytechnique.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: giving room for Linux filesystems on MLC/SLC
Date: Tue, 20 Oct 2009 15:39:25 +0300 [thread overview]
Message-ID: <1256042365.29856.260.camel@localhost> (raw)
In-Reply-To: <81859150910200356i1e80bb4er1b97046f43415938@mail.gmail.com>
On Tue, 2009-10-20 at 12:56 +0200, Emmanuel Michon wrote:
> Hello,
>
> we're preparing in my company the software for a general purpose (.5K,
> 2K, 4KB page)
> hardware MLC/SLC controller, especially how we're going to
> choose the byte offsets of a page+spare for `metadata' and `bad
> blocks' (those are excluded by our ECC check hardware).
>
> 0 4096+epsilon
> | metadata | data | bb info | data
>
> Our primary goal is to be compatible with our proprietary filesystem,
> but if we can enable Linux family of MTD FS with little effort, let's
> prepare it
>
> `bad block' information is a hardware stuff (unconsistently, poorly)
> documented to be near the start of spare area.
>
> For some reason we have this 4 byte metadata at the start of each
> page. Does this software concept apply to ubifs and friends and should
> it be sized differently?
We work with an abstract flash mode: it consists of eraseblock, each
eraseblock has several min. I/O units. So if in your cases the driver
hides these meta-data bytes, it should be fine.
However, current UBIFS is hard-coded with an assumption that min. I/O
size is power of 2. This would probably have to change. There was no
fundamental reason why we did it like this, we just wanted to save some
CPU cycles and avoid divisions. But this can be changed.
> Btw, any success stories about UBIFS+MLC since the FAQ report on this topic?
I have not heard them.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2009-10-20 12:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-20 10:56 giving room for Linux filesystems on MLC/SLC Emmanuel Michon
2009-10-20 12:39 ` Artem Bityutskiy [this message]
2009-10-21 10:16 ` Tadimarri Sarath Babu
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=1256042365.29856.260.camel@localhost \
--to=dedekind1@gmail.com \
--cc=emmanuel.michon@polytechnique.org \
--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