Re: [PATCH] UBI: introduce sequential counter

Josh Boyer
2007-02-09T13:11:24Z

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