public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@lazybastard.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, 9 Feb 2007 05:50:14 +0000	[thread overview]
Message-ID: <20070209055014.GA21893@lazybastard.org> (raw)
In-Reply-To: <1170972968.4884.140.camel@zod.rchland.ibm.com>

On Thu, 8 February 2007 16:16:02 -0600, Josh Boyer wrote:
>
> > 3. in the wear-leveling code we can distinguish between LEBs which were
> >    written to long time ago and recently. Indeed, if the sequential number
> 
> No you can't.

Yes, you can. :)

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

This is an unusual way of looking at time, but it is perfectly valid.
Whether an LEB is 40 seconds or 40 million years old is completely
inconsequential.  What matters is not how much wall-clock time has
passed, but how much other data was written.  "Bytes of data written" is
a valid unit of time, really, and a very useful one.  Esp. for wear
leveling decisions.

Congratulations, Artem!

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

Having a hard distinction between static and non-static data sounds bad,
agreed.  What this can (and will, in LogFS) be used for is not doing GC
on new data, if possible.  The newer your data, the higher the chances
of it becoming obsolete in the near future anyway.  So letting it sit
until it ages a little makes sense.

UBI is a bit coarser, as it has no clue about the LEB contents, but a
similar strategy may still make sense.

Jörn

-- 
tglx1 thinks that joern should get a (TM) for "Thinking Is Hard"
-- Thomas Gleixner

  reply	other threads:[~2007-02-09  5:54 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 [this message]
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
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=20070209055014.GA21893@lazybastard.org \
    --to=joern@lazybastard.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox