Using UBIFS as an FTL

[Daniel Ehrenberg]

On Tue, Jul 29, 2014 at 12:16 AM, Artem Bityutskiy
<artem.bityutskiy at linux.intel.com> wrote:
> On Mon, 2014-07-28 at 10:47 -0700, Daniel Ehrenberg wrote:
>> My understanding of ubiblock is that, when you do 4k writes scattered
>> around the device, they will magnify into block-sized
>> read-modify-writes. This causes ~64x as much wear (depending on the
>> device type) and goes at 1/64th the speed.
>
> Yes, I think so.
>
>>  I don't think I could
>> change ubiblock to not have this property because that wouldn't be
>> backwards-compatible--I'd need an extra layer of indirection to
>> separate logical pages from logical erase blocks.
>
> Say, ext4 can mount ancient ext3 images, and it supports many media
> formats, etc. Some thing like this could in theory be done with
> ubiblock. But this is not necessarily the _best_ way to go.
>
>>  Isn't ubiblock
>> usable for, say, copying off or on a ubifs filesystem image?
>
> To copy the UBIFS image you can just read from the underlying UBI device
> (/dev/ubiX_Y).

Does this block device also work well for writing an image (with that
logic to delay writing out until you write to a different block) or
should I be using some other block device for that purpose?
>
>>  I
>> wouldn't want to remove that functionality (and maybe I'll end up
>> using it). It just seems like ubiblock and a real FTL need totally
>> different pieces of software.
>
> There are many aspects in FTL - how it scales WRT mount time, memory
> consumption, etc. If someone decides to tackle only one small aspect at
> a time, may be it makes sense to keep adding relatively small
> improvements to ubiblock, maintain backward compatibility, several
> on-the-media formats, etc. Keep adding features and keep doing
> improvements.
>
> But if a couple of smart folks decide to spend a year and create
> something several orders of magnitude more superior, it is probably more
> feasible to just implement a separate driver, say ubiftl or whatever.
>
> If you ask me, I'd say it is largely up to the people doing the actual
> work. Although talking to the community is a good idea in any case :-)
>
> Thanks!
>
> --
> Best Regards,
> Artem Bityutskiy
>