commit 8d36279de013793cd3cf01af72f3044192112486
author Andrew Geissler <andrewg@us.ibm.com> Tue Oct 10 14:08:17 2017 -0500
committer Brad Bishop <bradleyb@fuzziesquirrel.com> Mon Oct 30 21:45:27 2017 +0000
tree 42195ab57dbac3ba941196c07d07f47aac4eb3b9
parent 74cb437b8c4c4a5c7ebdc68d09de377bece59e5e

Write journal to persistent storage

Currently the journal is written to a RAM based
filesystem which is lost on BMC reboots. This commit
will move the journal to a persistent filesystem location
so it will be available after BMC reboots for debug.
This change is only being done by default on
witherspoon systems with this commit. Other systems
may use this as a reference if they wish to move.

By default, journald uses 10% of the filesystem
(default is /var/log/journal/) and it will ensure 15%
of the filesystem space is left free. Specific machine
configs in openbmc can override these defaults if
they wish. For witherspoon, we will use 3MB max and use
the 15% left free default.

Due to the way openbmc mounts its filesytems, a
systemd-journald.service file override is required to
ensure journald does not start until the /etc/ filesystem
is fully mounted.

journald uses /etc/machine-id to create a directory
in which it stores its journal data. journalctl uses
/etc/machine-id to know which directory to look into
when a user requests the data. Without this override,
journald will end up making a random machine-id
and using that because /etc/machine-id is not available
when systemd-journald.service is started. journalctl
looks up the /etc/machine-id when its run, so it will
use the correct one (but not the one journald is using).

Witherspoon uses the new UBI filesystem, and only
has a total of 4MB available within /var. Ensure the
journal only ever uses 3MB of that space to leave room
for other applications.

In testing it was found that the persistence of journald
had minor impacts to overall flash erase blocks. With
persistence enabled or disabled, it was noted that the
UBI maximum erase count value incremented by 1 for every
10-20 boots of the host. Our CI system, which gets a
lot of activity (new image flashing, REST api testing,
and host boots) average 10-12 erase counts a day. A worst
case of 15 erase blocks a day would mean 18.2 years before
hitting the 100,000 erase block limit.

Resolves openbmc/openbmc#1627

Change-Id: I30211108f26bd9cd758800f457c17ed03d13e802
Signed-off-by: Andrew Geissler <andrewg@us.ibm.com>