[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $subject



David Woodhouse wrote:

> vmalik@xxxxxxx.com said:
> >  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.

Good point. I withdraw my argument :)


>
>
> 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.

Murphy once said..... ;) But I agree.


>
>
> vmalik@xxxxxxx.com said:
> >  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.

Ok. Agreed.

I'll restart testing as soon as I got a handle on that stupid module insertion
problem that
I'm having.

Vipin



To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com