On Tue, Sep 27, 2022, at 12:13 PM, Daniel P. Berrangé wrote:
On Tue, Sep 27, 2022 at 10:12:57AM -0600, Chris Murphy wrote:
> Fedora uses systemd-journald for system logging. By default it is a
> persistent log kept on /var, and uses up to 4G disk space, although
> in certain circumstances it can go a bit higher. See 'man journald.conf'
> for details.
> The obvious bike-shedding questions are:
> Is 4G is too much or too little? If so what amount it should be?
> Is size still the correct approach? Or should we consider a max
> retention time? And if so, what would it be and how granular
> should it be?
In context of modern physical machines, 4G is probably barely
noticeable for most people, given common physical disks measure
100's of GBs as a starting point.
Dual-boot is pretty common, and so are 128G NVMe drives in new laptops. So it's
"sufficiently not rare" that Fedora is being installed into less than 50G that
it needs to be accounted for.
Some people run Fedora on pretty old hardware where disk sizes
may be more limited.
Virtual machines are probably the place with the biggest disk
usage constraints where, 4GB could be pretty impactful when
a VM may only have a few 10's of GB of storage purchased.
Agree. It is possibly similar to the small storage cheap dual-boot baremetal case.
You mentioned '10%' earlier, is that is another existing
limit that's already applied, in addition to the 4GB absolute
size limit ?
Yes. SystemMaxUse= defaults to 10% of the file system size, capped to 4G. I'm not
certain this is a hard limit, i.e. I think if journals take up just under 4G and a new
journal file can be created, it's allowed to grow to the max size which I think is
128M (I've only ever seen 128M sized journals, so it's anecdotal evidence not man
page or code based). So it could plausibly grow to ~4.1GiB?
If so that'd obviously benefit the small disk
scenarios. A relative limit is going to be way oversized
for large disk scenarios though.
Both absolute and relative size limits look complementary
Currently SystemKeepFree= is 15% of file system size. Once free space goes below that
limit, systemd will stop growing its usage, but won't reduce its usage.
I wonder if max retention is actually useful at all though,
at least for generic out of the box usage
For systems with low rate of logging, the size of the journal
will grow slowly enough that max retention won't have a notable
impact for along time.
For systems with high rate of logging, a generic max retention
probably won't be aggressive enough to constrain the disk usage
quickly enough to stop problems arising.
Max rentention time doesn't take into account available disk
storage in any way.
Correct, it allows a significant float based on usage, consider space consumption
relatively less important than the value reduction of the journal entries over time. This
is what rsyslogd does, which I think its default retention is two weeks (?) and is
configurable. If you think most users most of the time have no need or expectation of
needing journal entries beyond X weeks, then you'd presumably be a proponent of a
relatively more dominant retention time policy (while still allowing for the max use
While there might a sweet spot, its effectiveness looks to
be somewhat limited, narrow in scope & unlikely to please a
broad enough userbase. IOW, combination of abs+rel size limits
look a more generally effective OOTB setting to avoid storage
Max retention time looks most relevant/useful as a mechanism for
implementing organizational policies on data record keeping times,
and quite site specific.
True but also pretty common in the era before systemd-journald in which it really was
predominately time based rentention.