[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finalized TODO list for NAND and JFFS...



David Woodhouse wrote:
> 
> I admire your optimism in calling it 'finalised' :)
> 
Hey, I can dream, can't I? :)

> >  1) Wear-leveling and aging for block re-usage for NOR and NAND
> 
> OK - this is useful information to have, but....
> 
> > 6) Block re-usage algorithm:
> 
> ... what's the point if you're not going to _use_ it? I'd be inclined to do
> without the statistics for now, and implement something like the block
> selection algorithm you quoted. We can add it later if it's absolutely
> necessary.
> 
I can see your point. So we will chop Item #1 and stick with just
Item #6, however, would you please clarify Item #5 in relation to
this. When reading an end of block, it would seem logical to pick
the next block/page in the case of a read. Why would I make a call
to get the next usable block? Silly question I'm sure.

> >  8) JFFS should do read after write of data with NAND flash only
> 
> Make it configurable, perhaps, but I'm inclined to do read-after-write with
> NOR flash too. If the MTD device claims to support ECC, you don't have to
> actually compare the data which were read back.
> 
This sounds fine. It will be a configuration option at the MTD
level and not the JFFS level. The return value handed back by
'MTD_WRITE' inside of 'flash_safe_write' can be used just like
before. The MTD layer can do the read verify and set the return
code if it fails. JFFS should not have to explicitly do a write
and then a verify read. Let MTD handle that if its configured
as such.

> >  2) JFFS needs write gathering for NAND to keep from writing
> >    more than 10 times per page
> >  2) I understand what the sentence is saying, but I do not have
> >     a clear idea on how to do this.
> 
> I'm inclined to start by making flash_safe_write() do caching and only
> flush to the actual MTD device when a later write wants to write to a
> different page. Then look at the places where you've either broken the
> journalling or could still exceed the write limit.
> 
> > 7) Utilize 'drivers/char/flash_mem.c' for caching 512 byte blocks
> >    with a buffer and write out data only when different page is found
> > 7) I believe this will be handled at the MTD level and is
> >    transparent for JFFS.
> 
> No, you'll break the journalling if JFFS doesn't know what's going on. Use
> flash_mem.c as a reference - it's doing the same thing as you wanted to
> write in item 2.
> 
Yes, reading back over the comment I made for Item #7, I was not
thinking (sigh). Item #7 will be eliminated. Item #2 will be re-worded
to implement caching in 'flash_safe_write'.

> Add:
>  - Compression.
>  - Formal proof of GC correctness.
> 
Wait a second, I was making a TODO list with items for changes
necessary for NAND and JFFS to work together. I wasn't making
a complete TODO list for MTD and JFFS, unless you're volunteering
me for that :).

-Steve

-- 
 Steven J. Hill - Embedded SW Engineer
 Public Key: 'finger sjhill@xxxxxxx.com'
 FPR1: E124 6E1C AF8E 7802 A815
 FPR2: 7D72 829C 3386 4C4A E17D