Subject: Re: NAND flash support
To: None <email@example.com>
From: Toru Nishimura <firstname.lastname@example.org>
Date: 03/13/2007 12:11:39
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
- 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