[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1336762570.6126.6.camel@brekeke>
Date: Fri, 11 May 2012 21:56:10 +0300
From: Artem Bityutskiy <dedekind1@...il.com>
To: Richard Weinberger <richard@....at>
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
On Fri, 2012-05-11 at 19:15 +0200, Richard Weinberger wrote:
> Am 11.05.2012 14:21, schrieb Artem Bityutskiy:
> >>> It is weird that you do not have an array of ECs instead for _every_
> >>> PEB. Why wasting the flash and time writing/reading this data?
> >>
> >> By array of ECs you mean that all ec values are written to the flash
> >> and pnum is the index?
> >> Sounds sane.
> >
> > Yes, to me it sounds like the only sane way, unless there is a strong
> > reason to have redundant "pnum" fields. :-)
>
> While looking at my own code a bit closer I found out why I haven't used the
> array approach. B-)
> Currently only ec values for PEBs within the free and used list are stored.
> Therefore, the array can have gaps. E.g. If PEB X is in the erroneous list.
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.
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?
--
Best Regards,
Artem Bityutskiy
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists