Block Device Emulation over UBI

[Artem Bityutskiy]

Hi Yuri,

On Mon, 2008-01-14 at 15:57 +0300, Yuri Tikhonov wrote:
>  We are about to implement and then maintain a block device driver which is 
> intended to work on the top of UBI and provide users with the block-device 
> interface to the underlying Flash chips. The goal of this driver is to 
> provide users with the possibility to easily organize reliable file storage 
> in Flash memory chips (especially NAND Flash) using Flash-unaware 
> file-systems like FAT, EXT2/3, etc (UBI is supposed to provide the necessary 
> reliability using its features of wear-leveling and bad blocks handling).
> 
>  In many cases the ability to have the file-system formatted with, for 
> example, FAT is a highly desirable feature of the embedded devices (e.g. for 
> exporting the embedded storage via USB link to a Windows-based USB host), so 
> we guess our work will be usefull for the embedded world.
> 
>  Any suggestions or comments as to possible issues we may run into on this 
> road would be very appreciated.

You are welcome to implement a block device layer on top of UBI, I'd
call it ubiblk. Here is an idea of a very simple implementation which
belongs to Adrian Hunter.

Every block is mapped to permanent position P = blk_size * blk_number,
which is (P / leb_size):(P % leb_size) in LEB:offset terms. When you
change a block, you use the "atomic LEB change" operation
(ubi_leb_change()) and re-write whole LEB.

While it seems to be very inefficient, it might be not so bad because
Linux elevator should help. Indeed, it re-arranges block change requests
so that they go as consecutively as possible. So the result is that you
write many consecutive blocks which sit at the same LEB at one go in
many cases, not just one block. And we can hope this will be fast
enough, although not necessarily. But it anyway makes sense to try this
out before inventing anything more comprehensive.

Few notes you would also need to do:

1. Implement ubi_get_volume()/ubi_put_volume() interfaces which just
get/put a volume reference and return, thus preventing the volume go
away (e.g., be deleted) while ubiblk is keeping it. Current
open()/close() interfaces do not look quite appropriate.

2. Implement some notification mechanisms for volume re-size - ubiblk
has to be notified when this happens.

3. You might as well also separate gluebi out once you have the above 2
things done and make it a separate ubimtd module, instead of built-in
crap.

HTH.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)