[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <501E823E.7080101@nod.at>
Date: Sun, 05 Aug 2012 16:25:02 +0200
From: Richard Weinberger <richard@....at>
To: Shmulik Ladkani <shmulik.ladkani@...il.com>
CC: artem.bityutskiy@...ux.intel.com, Tim Bird <tim.bird@...sony.com>,
"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"adrian.hunter@...el.com" <adrian.hunter@...el.com>,
"Heinz.Egger@...utronix.de" <Heinz.Egger@...utronix.de>,
"thomas.wucher@...utronix.de" <thomas.wucher@...utronix.de>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"Marius.Mazarel@...l.ro" <Marius.Mazarel@...l.ro>,
"nyoushchenko@...sta.com" <nyoushchenko@...sta.com>
Subject: Re: UBI fastmap updates
Am 05.08.2012 10:23, schrieb Shmulik Ladkani:
> On Thu, 2 Aug 2012 19:45:38 +0200 Richard Weinberger <richard@....at> wrote:
>> Okay, then let's explicitly reserve a few PEBs for fastmap.
>> This should be very easy task.
>
> Need to consider what's expected when migrating from a former non-FM
> UBI system to an FM enabled system, in the case where all PEBs where
> consumed (reserved) in the former system.
If no PEBs are available no fastmap can be installed.
*Maybe* we can steal some PEBs which reserved for bad block handling.
>> How much PEB should be reserved? 2 x sizeof(fastmap)?
>
> Since FM does not use EBA's atomic LEB change when writing the new
> fastmap, but instead implements its own FM "leb change" internally -
> then reserving 2x is needed if we'd like to avoid reusing the same
> fastmap PEB.
Yep.
Thanks,
//richard
Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)
Powered by blists - more mailing lists