UBI in Shipping Products ??

UBI in Shipping Products ??

[Johnson, Charles F]

With UBI in the mainline upstream kernel, does anyone have any guess on
actual products shipping which use UBI ??


Charles Johnson
Ultra-Mobility Group
Platform Software Engineering
Intel Corporation
charles.f.johnson@intel.com

Yet Another UBI Question

[Johnson, Charles F]

 Is there exist yet a block driver which sits on top of UBI so that you
could use one of the traditional file systems such as ext3 or vfat?


Charles Johnson
Ultra-Mobility Group
Platform Software Engineering
Intel Corporation
charles.f.johnson@intel.com

Re: Yet Another UBI Question

[Artem Bityutskiy]

On Wed, 2007-10-24 at 15:39 -0700, Johnson, Charles F wrote:
> Is there exist yet a block driver which sits on top of UBI so that you
> could use one of the traditional file systems such as ext3 or vfat?

Hi, no, there are no such drivers, unfortunately. But writing one is
much easier on top of UBI then on top of a bare flash.

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

Re: Yet Another UBI Question

[Vinit Agnihotri]

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????

--Vinit.

On Oct 25, 2007 4:09 AM, Johnson, Charles F <charles.f.johnson@intel.com> wrote:
>  Is there exist yet a block driver which sits on top of UBI so that you
> could use one of the traditional file systems such as ext3 or vfat?
>
>
> Charles Johnson
> Ultra-Mobility Group
> Platform Software Engineering
> Intel Corporation
> charles.f.johnson@intel.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: Yet Another UBI Question

[Artem Bityutskiy]

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

Re: 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@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.

Re: Yet Another UBI Question

[Artem Bityutskiy]

On Mon, 2007-11-19 at 15:36 +0530, Vinit Agnihotri wrote:
> 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.

When we wrote UBI we _did not_ mean to create FTL or something close _at
all_. We solved other problems: wear-leveling across whole flash chip,
volumes creation/deletion/re-size, reliability (static volumes,
transparent clever errors and bad-block handling, bit-flips handling,
updates).

FTL is a completely different task, we _did not_ intend solve it! If one
needs FTL - please go ahead and implement it!

But I say that it will be easier to do this on top of UBI then on top of
MTD device because UBI already solves many (but not all) problems FTL
has to solve (see the above). If one wants better performance because of
less stacking - please, just write FTL on top of MTD.

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

Re: UBI in Shipping Products ??

[Josh Boyer]

On Wed, 24 Oct 2007 13:50:55 -0700
"Johnson, Charles F" <charles.f.johnson@intel.com> wrote:

> With UBI in the mainline upstream kernel, does anyone have any guess on
> actual products shipping which use UBI ??

They exist.

josh

RE: UBI in Shipping Products ??

[Johnson, Charles F]

I was wondering about specific examples. 


Charles Johnson
Ultra-Mobility Group
Platform Software Engineering
Intel Corporation
charles.f.johnson@intel.com


-----Original Message-----
From: linux-mtd-bounces@lists.infradead.org
[mailto:linux-mtd-bounces@lists.infradead.org] On Behalf Of Josh Boyer
Sent: Friday, October 26, 2007 5:17 AM
To: Johnson, Charles F
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBI in Shipping Products ??

On Wed, 24 Oct 2007 13:50:55 -0700
"Johnson, Charles F" <charles.f.johnson@intel.com> wrote:

> With UBI in the mainline upstream kernel, does anyone have any guess
on
> actual products shipping which use UBI ??

They exist.

josh

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/