gluebi vs. ubi-volume mapping

gluebi vs. ubi-volume mapping

[Shibin George]

Hi,

I am using the gluebi driver to emulate mtd block devices on top of
which I use squashfs.
I understand that calling ubiattach will result in a gluebi device
getting created for each  volume on that ubi device. But is there any
way to figure out which gluebi device was created for which particular
ubi volume?
/proc/mtd does show the mtd device with the name of the ubi volume but
I have multiple volumes across different ubi devices with the same
volume_name hence the dilemma.

Is there already a way to figure out, for a given "ubi-device+volume",
which gluebi device was created? Thanks in advance..

Regards,
Shibin George
george.shibin1993@gmail.com

Re: gluebi vs. ubi-volume mapping

[Richard Weinberger]

On Fri, Jan 11, 2019 at 7:36 AM Shibin George
<george.shibin1993@gmail.com> wrote:
>
> Hi,
>
> I am using the gluebi driver to emulate mtd block devices on top of
> which I use squashfs.
> I understand that calling ubiattach will result in a gluebi device
> getting created for each  volume on that ubi device. But is there any
> way to figure out which gluebi device was created for which particular
> ubi volume?
> /proc/mtd does show the mtd device with the name of the ubi volume but
> I have multiple volumes across different ubi devices with the same
> volume_name hence the dilemma.
>
> Is there already a way to figure out, for a given "ubi-device+volume",
> which gluebi device was created? Thanks in advance..

AFAIK we have currently no good way to find this relation.
Except the volume name. If the UBI volume has name "foo", the MTD device
will use the same.

BTW: Why are you using glubi+mtdblock at all? To support squashfs we
have ubiblock.
That way you can use read-only block-based filesystems directly on top
of UBI without glubi
and mtdblock.

-- 
Thanks,
//richard

Re: gluebi vs. ubi-volume mapping

[Shibin George]

On Fri, Jan 11, 2019 at 3:23 PM Richard Weinberger
<richard.weinberger@gmail.com> wrote:
>
> On Fri, Jan 11, 2019 at 7:36 AM Shibin George
> <george.shibin1993@gmail.com> wrote:
> >
> > Hi,
> >
> > I am using the gluebi driver to emulate mtd block devices on top of
> > which I use squashfs.
> > I understand that calling ubiattach will result in a gluebi device
> > getting created for each  volume on that ubi device. But is there any
> > way to figure out which gluebi device was created for which particular
> > ubi volume?
> > /proc/mtd does show the mtd device with the name of the ubi volume but
> > I have multiple volumes across different ubi devices with the same
> > volume_name hence the dilemma.
> >
> > Is there already a way to figure out, for a given "ubi-device+volume",
> > which gluebi device was created? Thanks in advance..
>
> AFAIK we have currently no good way to find this relation.
> Except the volume name. If the UBI volume has name "foo", the MTD device
> will use the same.
Got it. Guess I will have to resort to using unique ubi-volume names..
>
> BTW: Why are you using glubi+mtdblock at all? To support squashfs we
> have ubiblock.
> That way you can use read-only block-based filesystems directly on top
> of UBI without glubi
> and mtdblock.
ubiblock, being read-only, didn't satisfy my requirement.
The device I am working on needs to have block-level software upgrade
capability.
So gluebi was the best solution that I could find that can run block-based
filesystem.
>
> --
> Thanks,
> //richard

Regards,
Shibin George
george.shibin1993@gmail.com

Re: gluebi vs. ubi-volume mapping

[Richard Weinberger]

Am Freitag, 11. Januar 2019, 13:42:11 CET schrieb Shibin George:
> > BTW: Why are you using glubi+mtdblock at all? To support squashfs we
> > have ubiblock.
> > That way you can use read-only block-based filesystems directly on top
> > of UBI without glubi
> > and mtdblock.
> ubiblock, being read-only, didn't satisfy my requirement.
> The device I am working on needs to have block-level software upgrade
> capability.
> So gluebi was the best solution that I could find that can run block-based
> filesystem.

Usually you don't want such a deep stacking on an embedded system.
But you are aware of ubiupdatevol?

Thanks,
//richard

Re: gluebi vs. ubi-volume mapping

[Shibin George]

On Fri, Jan 11, 2019 at 6:14 PM Richard Weinberger <richard@nod.at> wrote:
>
> > ubiblock, being read-only, didn't satisfy my requirement.
> > The device I am working on needs to have block-level software upgrade
> > capability.
> > So gluebi was the best solution that I could find that can run block-based
> > filesystem.
>
> Usually you don't want such a deep stacking on an embedded system.
> But you are aware of ubiupdatevol?

Yes, ubiupdatevol was one of the candidates. However, I needed the capability
to upgrade software incrementally instead of packing the entire ubifs image
(This is because I can't afford to reserve storage for large software-upgrade
packages).
I had posted this query about ubiupdatevol @
https://stackoverflow.com/questions/50699945/apply-incremental-patches-on-ubifs-volume
and finally had to discard ubifs for my purpose for the same reason.
That and the fact the current software-upgrade solution that I have works well
with block-based filesystems.

> Thanks,
> //richard
>
>
>

Regards,

Shibin George
george.shibin1993@gmail.com

Re: gluebi vs. ubi-volume mapping

[Richard Weinberger]

Am Freitag, 11. Januar 2019, 13:54:22 CET schrieb Shibin George:
> On Fri, Jan 11, 2019 at 6:14 PM Richard Weinberger <richard@nod.at> wrote:
> >
> > > ubiblock, being read-only, didn't satisfy my requirement.
> > > The device I am working on needs to have block-level software upgrade
> > > capability.
> > > So gluebi was the best solution that I could find that can run block-based
> > > filesystem.
> >
> > Usually you don't want such a deep stacking on an embedded system.
> > But you are aware of ubiupdatevol?
> 
> Yes, ubiupdatevol was one of the candidates. However, I needed the capability
> to upgrade software incrementally instead of packing the entire ubifs image
> (This is because I can't afford to reserve storage for large software-upgrade
> packages).
> I had posted this query about ubiupdatevol @
> https://stackoverflow.com/questions/50699945/apply-incremental-patches-on-ubifs-volume
> and finally had to discard ubifs for my purpose for the same reason.
> That and the fact the current software-upgrade solution that I have works well
> with block-based filesystems.

I have no idea what this has to do with squashfs.

Instead of updating the squashfs via mtdblock->glubi->ubivolume->ubi,
just use ubiupdatevol to update the ubivolume.

Thanks,
//richard