[RFC] read-only filesystem support for NAND flash devices

[Russ Dill]

On 5/11/06, Josh Boyer <jwboyer at gmail.com> wrote:
> On 5/11/06, Russ Dill <russ.dill at gmail.com> wrote:
> > > > Free block list? Bad block list? Tracking of block numbers? Sounds
> > > > like a full on FTL to me.
> > >
> > > A full read-write FTL needs to handle 512-byte writes if it's going to
> > > pretend to be a normal block device. A simple FTL for read-only stuff
> > > like cramfs/squashfs doesn't need that.
> > >
> > > We should probably do this kind of thing as an FTL -- we already have
> > > the 'mtd_blkdevs' infrastructure to help you by doing most of the
> > > interfacing to MTD and block layers for you. And then you can use any
> > > read-only file system on it.
> >
> > True, I also realized another possible shortcut. If a blocks gets an
> > ECC correction on a read, rewrite it to a free block, erase the block,
> > rewrite it from the data written to the free block, and then erase the
> > free block. You'd need to put some info in the OOB so you could know
> > what the state is on power recovery.
>
> Um, or simply leave the copied block alone, erase the original block
> and use it as the spare now.  You only need a single block for
> scrubbing.

At some point, the original block needs to be reused though, I suppose
it could go onto your freelist at scantime. I'm just looking for ways
to decrease mount time. If any block could be anywhere, you will have
long mount times.

If, on the other hand, you have a free block list past the end of the
image, you only need to scan this at mount, or even lazy, if a block
isn't available when you read it, then at that point, scan the free
list until it is found.