UBI/UBIFS interrupted write page handling

[Artem Bityutskiy]

On Tue, 2010-09-28 at 09:47 +0200, Matthieu CASTET wrote:
> Artem Bityutskiy a écrit :
> > On Sun, 2010-09-26 at 20:58 +0300, Artem Bityutskiy wrote:
> >>> The test is still running, but because for each boot we got this slow
> >>> dump (take near 1 min), I expect others errors to take longer to
> >>> appear.
> >> Your PEB 20 contains almost all 0xFFs, but not quite, and NAND pages are
> >> read with ECC errors. I think this is a result of power cut during
> >> erasure.
> >>
> >> My new patch-set is trying to detect situations when we have a PEB which
> >> contains important data, but its VID header is corrupted. We try to
> >> preserve such PEBs instead of erasing. UBI would not spam so much if
> >> debugging was disabled.
> > 
> > Matthieu, thanks for testing the latest UBI changes. I wonder, do you
> > have issues with the follow-up fix I sent you. I just wonder if it is ok
> > for me to put these patches to linux-next or it is better to wait a
> > little?
> > 
> That's better : interrupt erased page are not put anymore in corrupted list.
> But I have problem with interrupt write :
> this night the test crashed [1].

Yeah, this should be fixed by forcing LEB refresh for the last LEBs of
journal heads. This problem exists long time. I'll work on this and send
you patches.

Then I'll push the patches to the linux-next. This means I'll re-base
once again the master branch - will you survive such frequent
re-basing :-) ? But once the stuff in the linux-next - I do not rebase
it.

We also have the outstanding gc_lnum problem - did you see it in new
ubifs?

Also I wanted to add re-try logic to UBI read path, so that we could try
to read several times if there is an ECC errors, because as you pointed,
re-trying sometimes helps. However, this also needs a fix in mtd, which
is currently in my l2 tree:
http://git.infradead.org/users/dedekind/l2-mtd-2.6.git/commit/755e723d39ac6975e6488298e129284e30d74823


-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)