Re: Block device emulation on top of ubi volumes with read/write support

Re: Block device emulation on top of ubi volumes with read/write support

[Ezequiel Garcia]

On 20 January 2016 at 18:33, Charles Godson <cestgodson@gmail.com> wrote:
> Hi Ezequiel,
>
> Hope this email finds you well.
>
> I could have sent this directly to linux-kernel@vger.kernel.org or
> linux-mtd@lists.infradead.org, but I thought there may be a quick answer to
> this one.
>

I'm Ccing linux-mtd, and some interested folks.

> I am looking into enabling ext4 support on top of NAND flash. I am currently
> using squashfs on top of UBI volumes (with your read-only block device
> emulation), and that works exceptionally well for me (thanks for the quality
> code!).
>
> I've looked at your earlier work, where you started with block device
> emulation with RW support (e.g. https://lwn.net/Articles/525957/). I haven't
> seen much progress there, and in 2014 you''ve introduced RO version.
>
> I was wondering why the switch?
>

I guess there are two reasons: first, because even though UBI
does wear-leveling, we feared [1] that a regular filesystem would wear out
blocks by doing a crazy amount of writes.

To be honest, it wasn't the main obstacle, so I added the
write-support as an option
with a big fat warning message. It was later asked to drop the option,
and I fell for the
safer read-only instead of leaving write support there.

The read-only version was much much simpler, and it was tempting to keep things
simple. This is the second reason.

You may restart this discussion, write support and see how it goes. I'm not
entirely opposed to the idea.

BTW, why can't you just use UBIFS instead?

[1] http://lkml.iu.edu/hypermail/linux/kernel/1211.2/02895.html
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

Re: Block device emulation on top of ubi volumes with read/write support

[Richard Weinberger]

Am 20.01.2016 um 22:50 schrieb Ezequiel Garcia:
> On 20 January 2016 at 18:33, Charles Godson <cestgodson@gmail.com> wrote:
>> Hi Ezequiel,
>>
>> Hope this email finds you well.
>>
>> I could have sent this directly to linux-kernel@vger.kernel.org or
>> linux-mtd@lists.infradead.org, but I thought there may be a quick answer to
>> this one.
>>
> 
> I'm Ccing linux-mtd, and some interested folks.
> 
>> I am looking into enabling ext4 support on top of NAND flash. I am currently
>> using squashfs on top of UBI volumes (with your read-only block device
>> emulation), and that works exceptionally well for me (thanks for the quality
>> code!).
>>
>> I've looked at your earlier work, where you started with block device
>> emulation with RW support (e.g. https://lwn.net/Articles/525957/). I haven't
>> seen much progress there, and in 2014 you''ve introduced RO version.
>>
>> I was wondering why the switch?
>>
> 
> I guess there are two reasons: first, because even though UBI
> does wear-leveling, we feared [1] that a regular filesystem would wear out
> blocks by doing a crazy amount of writes.
> 
> To be honest, it wasn't the main obstacle, so I added the
> write-support as an option
> with a big fat warning message. It was later asked to drop the option,
> and I fell for the
> safer read-only instead of leaving write support there.

Yes. UBI is *not* a FTL and doing a proper RW block driver on top of UBI
will be hard. Especially if you want decent performance, power cut tolerance
and a good lifetime of your NAND.

We have UBIFS for reasons. :-)

> The read-only version was much much simpler, and it was tempting to keep things
> simple. This is the second reason.
> 
> You may restart this discussion, write support and see how it goes. I'm not
> entirely opposed to the idea.
> 
> BTW, why can't you just use UBIFS instead?

Please use UBIFS. Are you missing some ext4 feature?

Thanks,
//richard

Re: Block device emulation on top of ubi volumes with read/write support

[Daniel Ehrenberg]

On Wed, Jan 20, 2016 at 3:30 PM, Charles Godson <cestgodson@gmail.com> wrote:
> Thanks for quick reply. I replaced YAFFS2 root file system with SQUASHFS on
> top of UBI [1], and so far it works like a charm. I am currently using UBIFS
> on "user" partitions. Mostly, I needed quota on them, and there was nothing
> in the works about a year ago. I was exploring different avenues: add quota
> support to UBIFS or use [2]. However, I saw that UBIFS quota support is
> introduced somewhere in July [3].
>
> After your explanations and suggestions above, I think ext4 is not really an
> option for me. Since quota support for UBIFS is already in the works, the
> choice is fairly clear :) .
>
> Thanks for your help on this.
>
> [1] http://lists.infradead.org/pipermail/linux-mtd/2014-February/052261.html
> [2] https://lwn.net/Articles/525957/
> [3] https://lwn.net/Articles/651925/
>
> Best regards,
> Charles
>
I was also looking into using squashfs on top of ubiblock, hoping to
write to overwrite a particular entire UBI partition with read-write
ubiblock support. I ended up using separate MTD partitions each
squashfs volume, with an UBI instance on each one, which could then be
updated using the ubi formatting tools, rather than writing through
ubiblock. Maybe UBIFS would be a better design, in retrospect.

Dan

Re: Block device emulation on top of ubi volumes with read/write support

[Richard Weinberger]

Am 21.01.2016 um 00:54 schrieb Daniel Ehrenberg:
> On Wed, Jan 20, 2016 at 3:30 PM, Charles Godson <cestgodson@gmail.com> wrote:
>> Thanks for quick reply. I replaced YAFFS2 root file system with SQUASHFS on
>> top of UBI [1], and so far it works like a charm. I am currently using UBIFS
>> on "user" partitions. Mostly, I needed quota on them, and there was nothing
>> in the works about a year ago. I was exploring different avenues: add quota
>> support to UBIFS or use [2]. However, I saw that UBIFS quota support is
>> introduced somewhere in July [3].
>>
>> After your explanations and suggestions above, I think ext4 is not really an
>> option for me. Since quota support for UBIFS is already in the works, the
>> choice is fairly clear :) .
>>
>> Thanks for your help on this.
>>
>> [1] http://lists.infradead.org/pipermail/linux-mtd/2014-February/052261.html
>> [2] https://lwn.net/Articles/525957/
>> [3] https://lwn.net/Articles/651925/
>>
>> Best regards,
>> Charles
>>
> I was also looking into using squashfs on top of ubiblock, hoping to
> write to overwrite a particular entire UBI partition with read-write
> ubiblock support. I ended up using separate MTD partitions each
> squashfs volume, with an UBI instance on each one, which could then be
> updated using the ubi formatting tools, rather than writing through
> ubiblock. Maybe UBIFS would be a better design, in retrospect.

What is wrong with having a single MTD parition and multiple UBI volumes?
You can use ubiupdatevol to update your squahsfs.

Thanks,
//richard

Re: Block device emulation on top of ubi volumes with read/write support

[Daniel Ehrenberg]

On Wed, Jan 20, 2016 at 4:12 PM, Richard Weinberger <richard@nod.at> wrote:
> Am 21.01.2016 um 00:54 schrieb Daniel Ehrenberg:
>> On Wed, Jan 20, 2016 at 3:30 PM, Charles Godson <cestgodson@gmail.com> wrote:
>>> Thanks for quick reply. I replaced YAFFS2 root file system with SQUASHFS on
>>> top of UBI [1], and so far it works like a charm. I am currently using UBIFS
>>> on "user" partitions. Mostly, I needed quota on them, and there was nothing
>>> in the works about a year ago. I was exploring different avenues: add quota
>>> support to UBIFS or use [2]. However, I saw that UBIFS quota support is
>>> introduced somewhere in July [3].
>>>
>>> After your explanations and suggestions above, I think ext4 is not really an
>>> option for me. Since quota support for UBIFS is already in the works, the
>>> choice is fairly clear :) .
>>>
>>> Thanks for your help on this.
>>>
>>> [1] http://lists.infradead.org/pipermail/linux-mtd/2014-February/052261.html
>>> [2] https://lwn.net/Articles/525957/
>>> [3] https://lwn.net/Articles/651925/
>>>
>>> Best regards,
>>> Charles
>>>
>> I was also looking into using squashfs on top of ubiblock, hoping to
>> write to overwrite a particular entire UBI partition with read-write
>> ubiblock support. I ended up using separate MTD partitions each
>> squashfs volume, with an UBI instance on each one, which could then be
>> updated using the ubi formatting tools, rather than writing through
>> ubiblock. Maybe UBIFS would be a better design, in retrospect.
>
> What is wrong with having a single MTD parition and multiple UBI volumes?
> You can use ubiupdatevol to update your squahsfs.
>
> Thanks,
> //richard

Oh that's right. We considered that, but ultimately decided we wanted
to isolate the partitions from each other in terms of wear leveling.

Dan

Re: Block device emulation on top of ubi volumes with read/write support

[Richard Weinberger]

Am 21.01.2016 um 01:19 schrieb Daniel Ehrenberg:
> Oh that's right. We considered that, but ultimately decided we wanted
> to isolate the partitions from each other in terms of wear leveling.
> 

Why that? Usually you want the wear-leveling domain as large as possible.

Thanks,
//richard

Re: Block device emulation on top of ubi volumes with read/write support

[Charles Godson]

On Wed, Jan 20, 2016 at 4:21 PM, Richard Weinberger <richard@nod.at> wrote:
> Am 21.01.2016 um 01:19 schrieb Daniel Ehrenberg:
>> Oh that's right. We considered that, but ultimately decided we wanted
>> to isolate the partitions from each other in terms of wear leveling.
>>
>
> Why that? Usually you want the wear-leveling domain as large as possible.
>
> Thanks,
> //richard

Dan, I am trying to do the opposite: have one UBI container with
multiple volumes (this is similar to hard drive and its partitions).
Wear levelling is going to be spread over the whole flash, and that
should be far better than having smaller mtd partitions. Now I can use
ubi tools to resize volumes, clean them out, reformat them and all of
this on the fly. My only concern is flash corruption. Anyone have the
experience with multi-volume UBI and flash corruption(s)?

Thanks,
Charles

Re: Block device emulation on top of ubi volumes with read/write support

[Richard Weinberger]

Am 21.01.2016 um 01:29 schrieb Charles Godson:
> My only concern is flash corruption. Anyone have the
> experience with multi-volume UBI and flash corruption(s)?

What is your fear?
If your NAND is loosing random blocks you are in trouble anyways.

Thanks,
//richard

Re: Block device emulation on top of ubi volumes with read/write support

[Charles Godson]

On Wed, Jan 20, 2016 at 4:35 PM, Richard Weinberger <richard@nod.at> wrote:
>
> What is your fear?
> If your NAND is loosing random blocks you are in trouble anyways.
>
> Thanks,
> //richard
More along the lines of having software blow away first 2K (or
similar) of my mtd partition (sw bug). I think I would lose everything
in that case, right? When I have multiple mtd partitions, I would lose
only one of my file systems. However, all of this probably comes down
to having backup images, if high availability and reliability is
required.

Cheers,
Charles

Re: Block device emulation on top of ubi volumes with read/write support

[Richard Weinberger]

Am 21.01.2016 um 01:51 schrieb Charles Godson:
> On Wed, Jan 20, 2016 at 4:35 PM, Richard Weinberger <richard@nod.at> wrote:
>>
>> What is your fear?
>> If your NAND is loosing random blocks you are in trouble anyways.
>>
>> Thanks,
>> //richard
> More along the lines of having software blow away first 2K (or
> similar) of my mtd partition (sw bug). I think I would lose everything
> in that case, right? When I have multiple mtd partitions, I would lose
> only one of my file systems. However, all of this probably comes down
> to having backup images, if high availability and reliability is
> required.

If your software kills random blocks you're better with multiple
partitions due to backups...But as the kernel is software too... ;)

Strictly speaking you'd not lose everything after say 2k are gone.
But have to recover the data manually. :)

Thanks,
//richard