[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1331207881.7257.37.camel@sauron.fi.intel.com>
Date: Thu, 08 Mar 2012 13:58:01 +0200
From: Artem Bityutskiy <dedekind1@...il.com>
To: Richard Weinberger <rw@...utronix.de>
Cc: Shmulik Ladkani <shmulik.ladkani@...il.com>, tglx@...utronix.de,
linux-mtd@...ts.infradead.org, linux-kernel@...r.kernel.org,
tim.bird@...sony.com
Subject: Re: [RFC][PATCH 0/7] UBI checkpointing support
On Thu, 2012-03-08 at 10:21 +0100, Richard Weinberger wrote:
> On 08.03.2012 08:08, Shmulik Ladkani wrote:
> > But doesn't the CP data (sorry, UBIUBI data :) need to have one
> > 'struct ubi_cp_ec' descriptor for each used/free PEB, and as such the
> > maximum number of 'ubi_cp_ec' descriptors is total device PEBs, meaning
> > CP data is still linearly scaled to device size (with a very small
> > multiplier)?
> >
>
> It's UBIVIS data. :D
I have a suggestion for the property of the new term. Because your old
one can be both a noun and a verb (write a checkpoint, to checkpoint),
the new term should probably have the same property.
To write the ubibis and to ubibis? Hmm... not sure.
To write the fastmap and to fastmap or decide to not fastmap because all
PEBs within the first 64 have too high erasecounter? Sounds better IMO.
> The size of the checkpoint depends on the number of free/used PEBs.
> But in most cases the checkpoints fits into one or two PEBs.
> Because larger devices have larger erase blocks...
They do, but the eraseblock size grows much slower AFAICS.
--
Best Regards,
Artem Bityutskiy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists