public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frank Haverkamp <haver@vnet.ibm.com>
To: Artem Bityutskiy <dedekind@infradead.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Woodhouse <dwmw2@infradead.org>,
	Josh Boyer <jwboyer@linux.vnet.ibm.com>,
	Alexander Schmidt <alexs@linux.ibm.com>
Subject: Re: [PATCH 09/20 take 4] UBI: wear-leveling unit
Date: Mon, 26 Mar 2007 14:34:14 +0200	[thread overview]
Message-ID: <1174912454.4202.59.camel@localhost.localdomain> (raw)
In-Reply-To: <20070323164342.8958.94778.sendpatchset@localhost.localdomain>

Hi,

I wonder if a generic wear-leveling infrastructure makes sense. Artem is
showing us here his example of how he is attacking the problem for UBI.

The wear-leveling described here is only one approach out of many
possible. A different one, I think, is used where e.g. filesystems do
their own approach, because they have deeper knowledge on how the blocks
are used.
I think this is something special and out of the scope of what I try to
point out here.

Artems approach for UBI, as far as I can see, uses currently the hints:
erase counts per block a sequence number and a full view of all existing
blocks. If a block is requested the user can give following information:
LONGTERM, UNKNOWN, and SHORTTERM. Internally it has trees containing:
free blocks, used blocks, and blocks to scrub.

Let me try to illustrate how I think that a generic aproach might look
like:

struct wlevel_block {
	phys_block_num;
	erase_count;
	sequence_number;
	... /* which other hints are reasonable? 
		maybe other devices -> other hints? */
};

struct wlevel {
	int (* erase_block)(phys_num, priv_data); /* callback */
	/* more callbacks needed? */
	...
	void *priv_data;
};

wlevel_init(struct wlevel *wl);
wlevel_add(struct wlevel *wl, struct block_info *bi); /* add block info
e.g. during scan */
wlevel_put(struct wlevel *wl, block); /* free/erase a block */
wlevel_scrub(struct wlevel *wl, block);

enum characteristics {
	WL_DATA_LONGTERM,
	WL_DATA_UNKNOWN,
	WL_DATA_SHORTTERM,
};

wlevel_get(struct wlevel *wl, enum characteristics ch);
...
wlevel_destroy(struct wlevel *wl);

I do not hope that throwing this topic into the discussion might lead to
more itzi-bitsi-ness, and obsolete interfaces in the code (which were
just removed), but it might be worth a discussion on the side, to
explore if there are other people trying to solve similar problems like
we try here for the FLASH example, and if a common approach for this
problem makes sense or not - and of course if so how it could look like.

Regards,

Frank


  reply	other threads:[~2007-03-26 12:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-23 16:42 [PATCH 00/20 take 4] UBI: Unsorted Block Images Artem Bityutskiy
2007-03-23 16:43 ` [PATCH 01/20 take 4] UBI: on-flash data structures header Artem Bityutskiy
2007-03-23 16:43 ` [PATCH 02/20 take 4] UBI: user-space API header Artem Bityutskiy
2007-03-23 16:43 ` [PATCH 03/20 take 4] UBI: kernel-space " Artem Bityutskiy
2007-03-23 16:43 ` [PATCH 04/20 take 4] UBI: internal header Artem Bityutskiy
2007-03-23 16:43 ` [PATCH 05/20 take 4] UBI: startup code Artem Bityutskiy
2007-03-23 16:43 ` [PATCH 06/20 take 4] UBI: scanning unit Artem Bityutskiy
2007-03-23 16:43 ` [PATCH 07/20 take 4] UBI: I/O unit Artem Bityutskiy
2007-03-23 16:43 ` [PATCH 08/20 take 4] UBI: volume table unit Artem Bityutskiy
2007-03-23 16:43 ` [PATCH 09/20 take 4] UBI: wear-leveling unit Artem Bityutskiy
2007-03-26 12:34   ` Frank Haverkamp [this message]
2007-03-23 16:43 ` [PATCH 10/20 take 4] UBI: EBA unit Artem Bityutskiy
2007-03-23 16:43 ` [PATCH 11/20 take 4] UBI: kernel API functions Artem Bityutskiy
2007-03-23 16:43 ` [PATCH 12/20 take 4] UBI: update functionality Artem Bityutskiy
2007-03-23 16:44 ` [PATCH 13/20 take 4] UBI: volume management functionality Artem Bityutskiy
2007-03-23 16:44 ` [PATCH 14/20 take 4] UBI: character devices functionality Artem Bityutskiy
2007-03-23 16:44 ` [PATCH 15/20 take 4] UBI: gluebi functionality Artem Bityutskiy
2007-03-23 16:44 ` [PATCH 16/20 take 4] UBI: misc stuff Artem Bityutskiy
2007-03-23 16:44 ` [PATCH 17/20 take 4] UBI: debugging stuff Artem Bityutskiy
2007-03-23 16:44 ` [PATCH 18/20 take 4] UBI: JFFS2 UBI support Artem Bityutskiy
2007-03-23 16:44 ` [PATCH 19/20 take 4] UBI: update MAINTAINERS Artem Bityutskiy
2007-03-23 16:44 ` [PATCH 20/20 take 4] UBI: linux build integration 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=1174912454.4202.59.camel@localhost.localdomain \
    --to=haver@vnet.ibm.com \
    --cc=alexs@linux.ibm.com \
    --cc=dedekind@infradead.org \
    --cc=dwmw2@infradead.org \
    --cc=jwboyer@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.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