Opt Problem

Contents

[edit] The /opt Problem

There is not enough space on the rootfs to fit all applications, therefore an additional partition has to be used. But how?

There is a section in the Maemo 5 Developer Guide explaining the basics: Installing under /opt and /MyDocs

[edit] Current situation

  • 256MB OneNAND chip: bootloader, kernel, root (ubifs - with compression)
  • 32GB eMMC: /home ~2GB (ext3), /home/user/MyDocs ~29GB (vfat), swap 0.7GB
  • symlink: /opt/ -> /home/opt/
  • OneNAND is probably "much" faster than the eMMC (hard numbers? read? write? small blobs? big blobs?)
  • file system benchmark results for different media
  • OneNAND performance figures: Sustained read performance: 108MB/s. Sustained write performance: up to 17MB/s. See Samsung OneNAND specs.
  • eMMC performance figures: read performance 37MB/s. Write performance 20MB/s. Write speed of 17MB/s has been achieved in this test at symbianbriefs.blogspot.com. My own read tests however show ~11MB/s (370MB file).
  • Decisions were taken in a "what shall we do about /opt?" BOF at the Maemo Summit 2009. Minutes: http://lists.maemo.org/pipermail/maemo-developers/2009-October/021289.html

[edit] Some goals

  • Firmware should be flashable.
  • Should not break applications.
  • One should be able to install more than 256mb worth of software.
  • Standards compliance, less need to make incompatible quirks.
  • A fix should be doable after shipping (before shipping, probably not?)

[edit] Current problems / developer and packaging issues

This should be a list of current problems developers are experiencing related to optification:

  • Symlinks take up space in the rootfs. This may become an issue if there are lots of them.

[edit] Tool for detection of non-optified packages


Storage Usage provides a great visual way to detect non-optified packages.

[edit] Possible solutions, even the bad ones

[edit] Applications are made relocatable and installed to /opt

  • Relocatable applications can move everywhere without breaking.
  • No symlinks get scattered over the rootfs (symlinks take up space, too).
  • Not all applications can easily be made relocatable.
  • Requires more work by the programmer.
  • May not be feasible for ports from an upstream source.
  • Putting a startup script into /usr/bin setting up environment variables such as LD_LIBRARY_PATH can help.
  • autotools-based packages can use --prefix=/opt/<packagename>.
  • Python apps can make use of the __file__ module-scope variable to determine where they are installed (e.g. installdir = os.path.dirname(__file__)).
  • Could be taken into account as an alternative to maemo-optify wherever feasible.

[edit] Have a 2-5gb partition on the emmc for addon packages mounted to /usr/local or /opt

  • Most apps by default usually go there
  • for /opt store according to the FHS standard /opt/<package> and symlink to /opt/maemo/{bin,lib,share,...} (actually the standard is /opt/<vendor>/whatever In this case using /opt/maemo directly would work).
  • Having ld.so.conf and PATH set properly avoids all the symlink madness
  • Don't do symlinks for /usr/local|/opt - make it a real partition
  • Explain to people why they don't have full 32GB of storage - or use LVM on the eMMC to dynamicaly change the size as things get installed through some dpkg hooks or such - we do know how much it will take ahead of time so if there isn't enough storage do a resize(VFAT should be resizable with something like gparted maybe?) ext3/2 are both online resizeable (growth only!)
  • Requires a bit more work when packaging - make some defaults pre-set in SDK
  • All apps should use a normal usr layout underneath any path. Example: /opt/maemo/{bin,sbin,lib, etc...} same if it would be in /usr/local - works like GNU stow

[edit] store addon packages completely in /home/opt hierarchy

  • see this page
  • like previous solution but on the standard /home partition
  • very clean solution as no files (except for /var/lib/dpkg which may be moved as well) are created or modified on the NAND.
  • /etc and /var could be copied there as well and mounted to root using bind. This way OneNAND would only be changed be reflashes and if /home is not mounted (e.g., by a keypress during boot) a fallback system could boot from unmodified OneNAND.
  • if OneNAND is significantly faster, mark some often used shared libraries as candidates for a /usr/lib/cache directory in which they are copied during installation until a certain cache limit is reached.

[edit] During packaging move all files >500kb to /opt and symlink to root

  • Optify is basically this.
  • Install is not slowed down, work is done when packaging.
  • Some packages break when replaced with symlinks. How to prevent - hack on hack?
  • A buildbot could force this to debian/rules automatically.

[edit] Use aufs/unionfs to overlay OneNAND root with eMMC filesystem.

  • This could be partial overlay, for example only /lib and /usr.
  • Could keep essential libraries on OneNAND so they would work faster.
  • Has anyone measured the speed penalty for aufs/unionfs usage?
  • Is it faster or slower that moving root to eMMC?
  • Might be difficult to have new programs to benefit from faster OneNAND.

[edit] Hack with --datadir, --libdir etc. through debian/rules

  • Could be forced by a buildbot.
  • Should move most of the big lumps on larger media if there are some.
  • Works at least with packages with configure.
  • Requires at least additional $LIBDIR setup?
  • Programs which have hardcoded paths (ugly code) break.
  • Could additionally symlink files from opt to root.

[edit] Require that applications have --prefix /opt

  • Could be forced by a buildbot.
  • Should not break anything.
  • Programs would not benefit from faster OneNAND.
  • Requires at least additional $PATH setup?
  • Programs which have hardcoded paths (ugly code) break.
  • Could additionally symlink files from opt to root.
  • Just reminds me of 770's /var/lib/install..
  • Against standard

[edit] Move root from OneNAND to eMMC and combine with /home to create a new root

  • How much faster OneNAND is? Numbers?
  • Can flasher flash on eMMC?
  • Leave only the bootable and rescue stuff in the rootfs
  • Maybe use it uncompressed for speed and add a /fast/usr folder to OneNAND to store some system files that would benefit from the speed (example: move /usr/something to /fast/usr and symlink it or just place /fast/usr in the path)

[edit] Use mount -o bind (or -o rbind)

  • Method: Do not use NAND for any additional data. Boot into standard image. Any additional changes made are only available after -o bind or -o rbind which are defined in /etc/fstab . Setup provides potential fail-over; if -o bind or -o rbind fails user gets into 'rescue shell' providing 1) recovery method 2) quick install to vanilla firmware without 3rd party utilities, networking, or computer (think: no network available, expensive roaming, no computer with fwflasher or Nokia Software Downloader available, ...)

[edit] Turn the problem around, pivot the root with /opt

  • After pivot /opt would be root and old root would be /opt. Symlink the old root contents to new root would make those available.
  • Can the base system dependencies handle this?
  • Can Nokia created software handle this?
  • Could this work? If so, then all additional packages would install directly on eMMC.

[edit] After install move all files >500kb to /opt and symlink to root

  • Could be done at background after install or with post-install hook.
  • There might not be enough space on / even for install.
  • Install is already slow, could make it even slower.
  • Some packages break when replaced with symlinks. How to prevent - hack on hack?
  • Uninstall might be messy, some post-remove magic needed.

[edit] Chroot install in /opt, symlink to where it belongs

  • A Bit like stow.
  • Maybe somebody can see something good in this?
  • Difficult hack.. would need all the tools etc to be visible in the chroot.

[edit] Make /usr another partition

You know, historically /usr exists entirely for the purpose of separating the application partition from the underlying system, which is exactly our problem.

  • All the core nokia software and libraries should be relocated to / or maybe a /maemo.
  • /usr and /opt should become symlinks to /home/usr and /home/opt.
  • Maemo targeted GUI software would be encouraged to use /opt/[application].
  • Linux libraries and CLI software could safely use /usr, minimizing the required modifications.
  • Any frequently used accessed files in /home but not /home/user/MyDocs could be cached in /cache, which then gets overlaid with /home using unionfs or something more specialized.
  • Another location like /alt could be used by packages that know they need the NAND's speed, but this is discouraged.
Retrieved from "https://wiki.maemo.org/Opt_Problem"