Yet Another UBI Question

[Vinit Agnihotri]

Agree but What I mean is instead of implementing cdev & FTL on it.
Why not to implement block device for a volume in the first place.
ofcourse this block device will also have abilities of upadate, read/write.

Stacking is good approach but then stacking will causes performance degrade,
as we'll be emulating block device over a character device. But if we
can avoid it, we'll get performance improvements
& also widesread use of UBI as any FS could be put on UBI volumes with
no efforts.
User should not be given additional & complex task of writing FTL just
to put his FS on top of UBI volume.

Am I clearing my doubt enough?
--Vinit.

On Nov 19, 2007 3:11 PM, Artem Bityutskiy <dedekind at infradead.org> wrote:
> On Mon, 2007-11-19 at 14:54 +0530, Vinit Agnihotri wrote:
> > Hi,
> > As a part of work I have work with UBI & character drivers i.e. cdev.c in UBI.
> > Can we think of implementing block device drivers instead of cdev to
> > implement volume?
> > That way we'll not be needing any block emulation layer on top of
> > volume cdev & user will be able to
> > put any file system on top of it.
> > Will it complicate volume management or wear levelling anyway????
>
> Sorry, not sure what you mean. UBI character devices represent UBI
> volumes, they give you a possibility to update volumes, to read them, to
> fetch different kind of information. So we need them.
>
> An UBI volume is not a block device
> (http://www.linux-mtd.infradead.org/faq/ubi.html#L_ext2_over_ubi)
>
> You do have to write quite complex layer of code to implement FTL on top
> of UBI. Once you've done this, just expose the resulting block devices
> as /dev/ubiblock0 block device nodes. This is how I see it.
>
>
> --
> Best regards,
> Artem Bityutskiy (Битюцкий Артём)
>
>



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