[PATCH] UBI: introduce sequential counter

[Josh Boyer]

On Fri, 2007-02-09 at 11:12 +0200, Artem Bityutskiy wrote:
> Hello Josh,
> 
> On Thu, 2007-02-08 at 16:16 -0600, Josh Boyer wrote:
> > Do image creation tools now how to understand how to increment the
> > counter for each block in a binary image that would be flashed onto the
> > card raw?  Or do you leave the counter in all the VID headers as 0 for
> > such images?
> 
> They don't and they should be updated. But yes, they write zeroes to the
> sqnum and UBI is happy.

If writing zeroes to the field for all LEBs is valid, then I don't think
the tools need updating.  At least not the image creation tools.  We've
already declared the padding fields to be zero filled.

The unubi tool will need updating though.

> Here is an example:
> 
> I know the number of PEBs on the media N and I may introduce an
> empirical criteria of oldness M = F(N). For example, M=kN, k is a
> natural number. Its a subject for an investigation.
> 
> I know the highest sqnum (= the current global sequence counter) H, and
> any LEB with sqnum=S is treated it as old if S < H-M, and as "fresh"
> otherwise.
> 
> When I move a PEB with low EC, and I need to pick the target PEB (T),
> where I move the data to. I pick T with the highest EC if the data is
> old, and I pick T with an average EC if the data is fresh.

If you replace "old" with "stale" I agree.  My stupid english thinking
brain equates "old" with the passage of time, and that isn't what sqnum
is tracking.  It is valid to use stale though.

> > >  	ubi32_t data_crc;
> > > -	uint8_t padding1[24];
> > > +	uint8_t padding1[4];
> > > +	ubi64_t sqnum;
> > > +	uint8_t padding2[12];
> > 
> > Can't you add the field at the bottom before hdr_crc so you don't have
> > split padding like that?
> 
> No, it is 64-bit and I want it to be aligned.

Ah, aligned within on a 64-bit boundary... I see.  Looks odd, but ok.

josh