mount costs too long

Aubrey aubreylee at gmail.com
Sat Nov 11 09:11:56 EST 2006


On 11/11/06, Artem Bityutskiy <dedekind at infradead.org> wrote:
> On Fri, 2006-11-10 at 19:34 +0300, Vitaly Wool wrote:
> > B/c due to the MTD layer rework, there's no way now to use custom
> > oobinfo in yaffs.
> > Therefore, as yaffs1 presumes the SmartMedia OOB layout one can either
> > read/write raw OOB but that will most probably break the bad block
> > handling, or implement a small shim layer putting spare OOB area into
> > SmartMedia OOB layout or back. Any other way will result in
> > incompatibility with the older version of yaffs1.
>
> OK, as it was said that YAFFS1 becomes much slower, this means that it
> reads more data from OOB then if it were working with older kernel.
> Right? Why it reads more data?
>

Well, If I understand correctly, this should be a YAFFS issue. I got
the following explaination from YAFFS mailing list:
------------------
 Charles Manning to yaffs, me

On Saturday 11 November 2006 03:53, Vitaly Wool wrote:
> You'll have to do some code hacking to speed things up. I.e. you'll
> need to set up your OOB layout according to SmartMedia spec and then
> you'll be able to remove the translation shim in yaffs code.

It is important to understand this:

The mtd NAND driver is generic code that is parameterised by configuration
tables to make it flexible. This gives an (almost/often) out of the box
experience, and IMHO, is pretty slick code, but there's a cost associated
with the flexibility.

A custom driver can be a lot faster, but then it won't be generic any more.

Most people who want fast NAND speed end up writing their own custom drivers
to maximise ransfer with their hardware.
---------------------

I think I need more time to read source code to understand this. Did
anyone enable yaffs on small page NAND chip on the kernel >= 2.6.18?

-Aubrey




More information about the linux-mtd mailing list