Block Device Emulation over UBI

Block Device Emulation over UBI

[Yuri Tikhonov]

 Hello all,

 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.

 Regards, Yuri

-- 
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com

Re: Block Device Emulation over UBI

[Vinit Agnihotri]

Few months back I raised same question here &
I got nice replies from Artem.I am not able to found that discussion in my
mail box though :( & even not able to recall much of it.
However Artem said writing block device driver on top of UBI volume is same as
implementing FTL on it, basically its re-inventing the wheel. Probably Artem
can answer you well :-).

--Vinit.


On Jan 14, 2008 4:57 AM, Yuri Tikhonov <yur@emcraft.com> wrote:
>
>  Hello all,
>
>  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.
>
>  Regards, Yuri
>
> --
> Yuri Tikhonov, Senior Software Engineer
> Emcraft Systems, www.emcraft.com
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>



-- 
Life is so short. So, follow some rules. Forgive quickly, believe
slowly, love truly, laugh loudly & never avoid anything that makes U
smile.

Re: 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 (Битюцкий Артём)