[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> If that's the case, then I put forward the argument that we don't
> need "flipping bits" (or partially erased sector) detection anyway
> (hence the I'm done erasing signature), as by (your above) definition,
> only sectors full of dirt would have been in the middle of an erase
> when power failed.
Ah, but the erase might have almost completed, leaving it looking erased
when we scan it although one or two of the bits are actually flipping.
I suppose it's also theoretically possible that when we fill up the block
with data and subsequently erase it, the chip manages to erase all but the
first marker node before we remove power. I think that's extremely unlikely
to happen in real life though.
> The only thing to be careful of, would be actual implementation code
> that gets tripped up by bits changing in the same location during a
> scan, a-la JFFS1- which resulted in a forever loop of kernel memory
> allocation, that ultimately resulted in a kernel panic due to memory
> leaking away.
That's not a problem with the JFFS2 scan implementation. If a block returns
_strictly_ alternating results we could possibly end up in a loop - I should
fix that. But the problem we really have to look out for is putting a block
like this on the free list when it's not really usable, because we happened
to read all ones from it when we scanned it. And the clean marker scheme
that Alan proposed fixes that quite effectively.
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org