From: Artem Bityutskiy <dedekind@infradead.org>
To: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Cc: MTDML <linux-mtd@lists.infradead.org>
Subject: Re: [PATCH] UBI: introduce sequential counter
Date: Fri, 09 Feb 2007 16:40:00 +0200 [thread overview]
Message-ID: <1171032000.17314.4.camel@sauron> (raw)
In-Reply-To: <1171026729.4884.177.camel@zod.rchland.ibm.com>
On Fri, 2007-02-09 at 07:12 -0600, Josh Boyer wrote:
> 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.
They should be updated because they should generate unique numbers to
the sqnum field, do not use old 'leb_ver' stuff, because leb_ver stuff
will go away eventually, say, in a year. Also boot-loaders should be
eventually updated.
> > 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.
Just treat the steadily increasing sequential number as a kind of UBI
time, then my terminology start making sense.
> Ah, aligned within on a 64-bit boundary... I see. Looks odd, but ok.
Nothing odd, actually. I do not want to deal with unaligned addresses.
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2007-02-09 14:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-08 20:02 [PATCH] UBI: introduce sequential counter Artem Bityutskiy
2007-02-08 22:16 ` Josh Boyer
2007-02-09 5:50 ` Jörn Engel
2007-02-09 9:19 ` Artem Bityutskiy
2007-02-09 9:12 ` Artem Bityutskiy
2007-02-09 13:12 ` Josh Boyer
2007-02-09 14:40 ` Artem Bityutskiy [this message]
2007-02-09 14:50 ` Josh Boyer
2007-02-09 14:54 ` Artem Bityutskiy
2007-02-13 15:11 ` Frank Haverkamp
2007-02-13 15:40 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1171032000.17314.4.camel@sauron \
--to=dedekind@infradead.org \
--cc=jwboyer@linux.vnet.ibm.com \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.