[PATCH] flashcp: improve speed & some clean ups

[Russ Dill]

>> I would caution against treating all 0xff blocks as being erased. A
>> partially erased block will often return mostly 0xff, but some of the
>> bits are random. If they return 1, you'll think all is well when it is
>> not. This is why jffs2 has clean-markers. Secondarily, a partially
>> erased block that randomly returns a few bits that match you data to
>> be written would also be bad. In fact, no matter what stage power was
>> lost during an erase cycle, no matter how marginal any percentage of
>> the bits, your tool will smile and nod if it is writing all zeros.
>
> Hm yes.
> I did not consider power loss in a previous erase cycle.
> Actually I assumed that 1's and 0's would be pretty solid and not
> dangling in mid-air.
> Taking that into account it is definitely a must to put it behind an option.
>
> Taking that into account is it still worthwhile/interesting to have this patch?
> Or should I see if I can modify the program in such a way that it only
> erases what is needed
> (the change was triggered by having to copy a kernel image and/or
> initrd and/or rootfs to a partition that was quite overdimensioned)

I think if the data in flash matches the data you are about to write,
its ok to leave it, otherwise I'd erase and rewrite. There are a few
people on this list who have extensive experience with power failure
modes of NOR flash. Hopefully one of them can chime in. From what I
understand about the design of JFFS2 though, the only thing to watch
out for is an eraseblock that looks erased, but in reality isn't fully
erased. I think leaving in the part about checking for changes only
from 1->0 is a bit dangerous, if you leave it in, I'd put a big
warning on it.