Messages in this thread | | | Subject | Re: [PATCH 09/20 take 4] UBI: wear-leveling unit | From | Frank Haverkamp <> | Date | Mon, 26 Mar 2007 14:34:14 +0200 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |