Re: [PATCH] UBI: introduce sequential counter

[Artem Bityutskiy <dedekind@infradead.org>]

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 a new kernel is run with an older UBI image, will it automatically
> start using the field and increment the counter values?  (If yes, that
> makes my first question go away I think.)

Yes. Both are used, incremented, etc.

> No you can't.  You cannot determine time and rate from a simple counter
> number.  All you can determine is that LEB N is older than LEB M.  It
> could be older by 40 seconds, or older by 5 years.

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.

> 
> >    is close to the current one, it was written recently. This provides us
> >    an opportunity to distinguish between LEBs with static data vs. LEBs
> >    with not really static data (e.g., we have just recently taken a LEB
> >    with low erase counter and wrote data there). This is useful for WL.
> 
> Yes, this might help wear-leveling.  But if the data is used, I would
> recommend being very conservative about using the counter value to
> distinguish between "static" and "non-static" data.

Yes, this has to be carefully thought of.

> > + * eraseblocks P and P1. But P1 has greater sequence number, so UBI pick P1.
> 
> "... so UBI picks P1"

Yup, Tx.

> > + * which PEB is the original (obviously P will have lower @ts) and the copy.
> 
> What is @ts?

I first wanted to call it "time stamp", but store sequence number.
Leftovers, tx.


> > + * Note, there is an obsolete @leb_ver field which was used instead of @ts in
> 
> Again with @ts... I think you mean @seqnum?

Yup, tx.

> >  	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.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)