| commit | 1ace1bdc0351b1c1b4ed5625c523d2b4bc3dc89f | [log] [tgz] |
|---|---|---|
| author | Ed Tanous <ed.tanous@intel.com> | Thu Nov 01 12:15:57 2018 -0700 |
| committer | Andrew Geissler <geissonator@yahoo.com> | Fri Jan 04 15:15:24 2019 +0000 |
| tree | 309f094712c69931fbf0d3552846238ba17c4201 | |
| parent | ff8035f8482a1ee9f8ef84ef9ee16ab3f2ba9cd2 [diff] |
Rootfs filesize analysis tool This commit checks in a tool to be used for analysing the space taken up in the rootfs, as well as an overnight run from my system. Most other tools give estimates of the space savings given when things are deleted by either xz compressing the individual file, and measuring the cost, or doing some other things. This script actually attempts to remove the file or folder in question, and rebuild the squashfs without it, then measure the size savings. It loops this over the entire filesystem (excluding symlinks) and sorts the result by size savings. It takes a _very_ long time to run (several hours on a very fast machine) but should give the most accurate answer to "what can we delete to reduce our flash usage". Some things that surprised me: 1. Deleting python would save us ~2.7MB in the rootfs size after the /usr/lib/python2.7 delete (2.2MB), and the libpython removal (500KB) 2. Redfish static data is taking up more space than originally thought with the latest revisions of the spec. Filtering the schema files down to the ones we actually use would probably save us 100KB. 3. keymaps take up 430KB! ! ! !. In comparison, this is almost exactly the same size as libc takes on the bmc. A quick look at the things shows that they're being pre-gzipped in the filsystem, which means that the xz compressor can't compress similarities between files. Might be something to look at. 4. bmcweb binary weighs in at 425KB. This can be optimised. 5. /usr/share/www weighs in at 678KB. We need to get this down. 6. cracklib takes up 217KB. This seems kinda lame. Change-Id: I5636ff22009f341a1454afd480f54701c6cf7954 Signed-off-by: Ed Tanous <ed.tanous@intel.com>
The goal of this repository is to collect the two-minute hacks you write to automate interactions with OpenBMC systems.
It's highly likely the scripts don't meet your needs - they could be undocumented, dysfunctional or utterly broken. Please help us improve!
Then this repository aims to be the default destination for your otherwise un-homed scripts. As such we are setting the bar for submission pretty low, and we aim to make the process as easy as possible.
openbmc-events: Query error events on the target serveropenbmc-sensors: Query sensors on the target serveropenbmc-sfw: Manage host and BMC firmware images on the target serveropenbmctool: A general purpose tool for user interactions with OpenBMCpretty-journal: Convert journalctl's 'pretty' output to regular outputupload_and_update: Upload a tarball to TFTP server and update BMC with itnetboot: Painless netboot of BMC kernelsobmc-gerrit: Automagically add reviewers to changes pushed to Gerritreboot: Endlessly reboot OpenPOWER hoststracing: Enable and clean up kernel tracepoints remotelywitherspoon-debug: Deploy the debug tools tarball to Witherspoon BMCscla-signers: Check if a contributor has signed the OpenBMC CLAopenbmc-autobump.py: Update commit IDs in bitbake recipes to bring in new changesPlease use gerrit for all patches to this repository:
Do note that you will need to be party to the OpenBMC CLA before your contributions can be accepted. See Gerrit Setup and CLA for more information.
So long as your patches look sane with a cursory glance you can expect them to be applied. We may push back in the event that similar tools already exist or there are egregious issues.
We don't ask for much, but you need to give us at least a Signed-off-by, and put your work under the Apache 2.0 license. Licensing everything under Apache 2.0 will just hurt our heads less. Lets keep the lawyers off our backs. ^
^Any exceptions must be accompanied by a LICENSE file in the relevant subdirectory, and be compatible with Apache 2.0. You thought you would get away without any fine print?
There's no standard way to install the scripts housed in the here, so adding parts of the repository to your PATH might be a bit of a dice-roll. We may also move or remove scripts from time to time as part of housekeeping. It's probably best to copy things out if you need stability.