OpenBMC Image Management

[Patrick Williams]

On Thu, Aug 03, 2017 at 10:14:55AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2017-08-02 at 12:15 -0500, Adriana Kobylak wrote:
> > General:
> > * Move to UBI volume management (on the BMC and PNOR chips), which
> > provides dynamic partitioning and wear-leveling. In a limited flash
> > space environment there might be the need to re-allocate partition
> > space and resizing in a static partitioning implementation can be
> > very painful.
> > * Use CRAMFS for read-only partitions, and UBIFS for read-write
> > partitions.
> 
> I still don't understand what is the point of using UBI on a 32M or 64M
> NOR flash. Other than wasting space and time.

Ben,

"Still don't"?  You've never actually asked any questions even though
this was first proposed publicly on the mailing list on Jan 26th:

    https://lists.ozlabs.org/pipermail/openbmc/2017-January/006298.html

No one questioned UBI in that original thread, or really since then,
until now.  Kernel changes were proposed and merged back in early Feb
and again there was no discussion or questions:

    https://lists.ozlabs.org/pipermail/openbmc/2017-February/006457.html

But ok, I'll bite.  There are two main reasons we went this path:

    *  UBIFS is, to the best of my knowledge, a better file system than
       JFFS2 in pretty much every metric.

    *  Dynamic volumes are easier to deal with than static volumes,
       which Adriana spelled out above.

Is your real question why do we have a file system instead of a raw FFS
image?  That could have been implemented with static volumes instead of
UBI, and someone still could go implement code to do that instead if
they are interested.  A few advantages of a file system over raw FFS are:

    * Measurably faster boot and update performance.
    * Ability to support a true "factory reset" operation, unlike the
      competitive BMC implementations of raw FFS.
    * Easier and more obvious removal of development patches from a
      machine.

> 
> Ben.
> 

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170803/d43efc4d/attachment.sig>