[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JFFS2 on NAND flash
On Tue, 5 Feb 2002, Thomas Gleixner wrote:
> On Friday, 1. February 2002 19:10, David Woodhouse wrote:
> > cvs up -r jffs2-nand-branch
> I got it. The wbuf stuff is running now. But i have some questions.
> 1. in jffs2_flush_wbuf, you have a adjustment of c->nextblock->freesize.
> I don't find a reason to use it. If we write to a different block, we can not
> touch nextblock. If we pad a page, because the next node does not fit into
> this page, the information is already updated. This happens, when c->wbuf_len
> is 0x1fd and the next write occurs on the beginning of a new page.
If we're doing a flush only because fsync() caused us to do so without
filling the wbuf completely, then we've wasted some space at the end of
the wbuf, and the next write must go at the beginning of a new page -
that's why we need to modify the free_size.
If we have another node to write, we'll put as much in the wbuf as will
fit before flushing it, then write as many whole pages as we can from the
rest of the node, then put anything remaining at the end of the node into
the wbuf again. So we don't do anything with the free_size in that case.
At least we shouldn't - as I said, I haven't tested the code.
> 2. Powerdown with data in writebuffer.
> If we have data in the writebuffer, e.g. a new file, we will loose this file.
> The only way to get around this is a early powerfail warning, which shuts
> down the system.
We need to make sure that sync works in 'sync; poweroff -f'. Note you lose
the changes made _just_ before the poweroff, you don't lose the whole
> But what about data, whe have for lets say 20 Minutes in the writebuffer ?
> This happens, if the application has stopped to produce new data. Is there a
> possibilty to build a timeout for flashing out the remaining bytes in the
> writebuffer ?
Good point. We should wake up the GC thread, even if it's not required for
other reasons, if we have old data in the wbuf that needs flushing. We do
this in order to avoid flushing the wbuf with padding in it - we want to
use it all.
> 3. CLEANMARKER. In your "Ramblings on NAND flash support" you say we have to
> move the cleanmarker into the spare area of the flash-chip. This means we
> have to shorten the nodesize and fake the cleanmarker node in the nand driver
> on readback.
Why do we have to fake the cleanmarker? Just make the JFFS2 code check for
it in the right place instead of at the beginning of the eraseblock. I've
done this change already.
> What happens, when we flush the write buffer. The buffer starts
> at page offset 0xc, when we write at the beginning of a block. We have to
> change jffs2 node management and more things. I don't know if that's a good
> idea, because we build more incompabilties than neccecary.
All I had to change for checking the cleanmarker in the new place was the
jffs2_scan_medium() and jffs2_scan_eraseblock() code, not very
intrusively. And of course the bit that _writes_ the cleanmarker after an
erase. Do you think I missed something?
> We keep the Block Status Flag at it's original place. So we can retrieve bad
> blocks marked by the manufacturer (Thats only true for SmartMediaCards).
> When we write a short node (cleanmarker), we use a short ECC (on 512 Byte
> page devices only) and program the Short Data Status Flag to 0. On 256 Byte
> page devices we write the cleanmarker without ECC (and hope ....).
We can put the cleanmarker in the spare area and simplify this.
> When we flush the writebuffer, we have to ensure to use also the already
> written data for ECC calculation. We have to do this, if the Short Data
> Status Flag is zero.
We can declare that the wbuf never starts anywhere other than the
beginning of a page (I think my current code enforces that with a BUG()
already). It makes life easier.
We do need to accommodate the DiskOnChip hardware ECC, which uses the
first 6 bytes of the spare area. But we can make it hw-specific if we have
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org