[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4FAD6563.7040408@nod.at>
Date: Fri, 11 May 2012 21:15:47 +0200
From: Richard Weinberger <richard@....at>
To: dedekind1@...il.com
CC: linux-mtd@...ts.infradead.org, tim.bird@...sony.com,
tglx@...utronix.de, linux-kernel@...r.kernel.org,
Heinz.Egger@...utronix.de
Subject: Re: [PATCH 1/7] [RFC] UBI: Add checkpoint on-chip layout
Am 11.05.2012 20:56, schrieb Artem Bityutskiy:
> I think this is not a good enough justification. I think we may use
> 0xFFFFFFFF and other high EC values to indicate that the block was bad
> or erroneous or whatever.
Okay, then we have to store all PEB ec values. (used, free, erroneous and scrub)
This is not a big deal.
As I said, currently only used and free PEBs are stored.
I think we need also a better solution for the protection queue.
My current solution (ubi_flush_prot_queue) is not the right thing.
Today I've observed a data corruption issue an I'm sure it happened
because fastmap did the wrong thing with the protection queue.
The problem is that a PEB in the protection queue is not visible to fastmap.
(Because it writes only used and free PEBs on the flash).
> BTW, did you think about scenario of moving dumping UBI2 on on one
> device with one bad PEBs distribution and then flashing it to a
> different device with a different bad PEB distribution? What would
> happen when we have fastmap enabled? Also, what if I write it to a
> larger flash with otherwise the same geometry?
>
> I guess we could detect these things and fall-back to scanning?
Falling back to scanning is easy.
But how can we detect such a change?
Thanks,
//richard
Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)
Powered by blists - more mailing lists