Re: NAND flash support

["Toru Nishimura" <locore64%alkyltechnology.com@localhost>]

I feel hesitating being a man of "howling for full moon," though, I've
been skeptic about FTL/journalled flash filesys implementations;

- bad block management is a part of either device driver or filessys,
here those words used here as a standard Unix terminology.
"Translation" implies to pretend fault-less HW to hide defects from "upper"
SW.  Probably, it's just the negative consequent of that HW vendors have
been over- or mistakenly emphasising the necessity of SW tactics.
- I found that papers describing FTL argue much about a specific filesys
implementation, FAT, indeed.  Isn't it an irony the filesys was originally
invented for much-unreliable-and-must-be-discarded-soon flexible floppy
drive media?
- wear-levelling can be done only with the help of appropriate filesys
design characteristics, not by translation nor bad block forwarding.
- robustness of filesys consistency for emergent conditions, say, abrupt
power cut, is a different argument in a different dimension.

Then, what characterises should be pursued to invent the filesys?
- well-defined ordered meta operation to modify filesys.
- a distinct block reclaim strategy; blocks which are free'd away can
be re-written only when all the blocks are exhausted.  "Never re-write
in the place."

We have good basis for them; the former is nothing other than
softdep, and the latter is the characteristic (ah, goal) of BSDLFS.
Bad block avoidance can be done in ease just FAT can do.

I felt amusing somehow to see how the write operation is done
unevenly since my code tracks write count in NAND spare field.

Toru Nishimura/ALKYL Technology