linux-kernel - Re: [PATCH 09/20 take 4] UBI: wear-leveling unit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1174912454.4202.59.camel@localhost.localdomain>
Date:	Mon, 26 Mar 2007 14:34:14 +0200
From:	Frank Haverkamp <haver@...t.ibm.com>
To:	Artem Bityutskiy <dedekind@...radead.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
	Alexander Schmidt <alexs@...ux.ibm.com>
Subject: Re: [PATCH 09/20 take 4] UBI: wear-leveling unit

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/