Re: Ubiblock users call (Re: mvneta / openblocks switch)

Ezequiel Garcia
2013-11-06T11:00:15Z

On Wed, Nov 06, 2013 at 07:30:07AM +0100, Willy Tarreau wrote:
> Hi Ezequiel,
>
> On Tue, Nov 05, 2013 at 03:57:48PM +0100, Willy Tarreau wrote:
> > > Can you describe your usage?
> >
> > For example, one of my distro's boot scripts automatically detects
> > the available partitions, checks for a mountable FS there, then
> > locates the current config and loads it. With a block device, I have
> > nothing to change at all. With other solutions, I have to reconsider
> > the boot process.
>
> BTW, I forgot to describe the initial use case I had in mind which led to this:
> many of my machines (including the test ones) boot from a rootfs which is a
> squashfs stored as an initrd image. At the moment, the squashfs is read by
> u-boot from the NAND into memory and the kernel boots from this. Loading a 10
> MB rootfs from NAND to RAM takes 1-2 seconds depending on the device, and
> consumes 10 MB of RAM all the time. Also, you're always at risk that some bad
> blocks appear in the middle of this image (I had one device where I had to
> change the location of the initrd partition because of
> this).
>
> With ubiblock, I can totally solve this issue :
> - u-boot does not read anymore the initrd, thus saving time and RAM
> - kernel simply mounts the squashfs at boot from ubiblock, resulting
> in direct accesses
> - ubi would take care of bad blocks itself
>
> Doing so prevents me from upgrading the image since it's always mounted,
> which is why I wanted to try to write it from u-boot. It did not work so
> I wanted to use 2 images and upgrade one while running on the other one.
> But I did not make any progress on this yet.
>
> I'll definitely give your latest patches a try, I just don't know when :-)
>

Thanks for all these details! It'll be definitely interesting if you
could jump in the discussion when the patch is finally submitted.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering