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

[Ezequiel Garcia]

Hi Ezequiel,
Hope this email finds you well.
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

[Richard Weinberger]

Post by Ezequiel Garcia

Hi Ezequiel,
Hope this email finds you well.
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. :-)

Post by Ezequiel Garcia
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

[Daniel Ehrenberg]

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

[Richard Weinberger]

Post by Daniel Ehrenberg

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

[Daniel Ehrenberg]

Post by Richard Weinberger

Post by Daniel Ehrenberg

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

[Richard Weinberger]

Post by 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

[Charles Godson]

Post by Richard Weinberger

Post by 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

[Richard Weinberger]

Post by 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

[Charles Godson]

Post by Richard Weinberger
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

[Richard Weinberger]

Post by Charles Godson

Post by Richard Weinberger
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