[systemd-devel] journal: How to limit the file size of runtime system.journal

[Sascha Kattelmann]

On 12/16/2013 02:30 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Dec 16, 2013 at 08:31:46AM +0100, Holger Winkelmann [TP] wrote:
>> Hi,
>>
>>>>> Is there any particular reason? I think thresold for runtime journal
>>>>> size can lower much because in initramfs it's not supposed to have much
>>>>> logs.
>>>> First, there are some data strcutures which are allocated when the file
>>>> is created, and if the file was very small, relatively more space would
>>>> wasted. Second, repeated fields are not stored, just referenced, so things
>>>> become more efficient when the file is not too small. But neither is
>>>> fundamental reason, and with some tweaking the journal could be made
>>>> to work much smaller files.
>>> I understand. These are really good points when logs are relatively
>>> large, ie. the journal is stored on a real disk.
>>>
>>> However when it's in initramfs context, journal is stored in tmpfs which
>>> is using the real memory resource as it's backend. 4 MB seems a little
>>> bit overkill especially when memory is quite limited case, like kdump.
>>> To be more specific, I think 512 KB or 1 MB is a fairly large enough
>>> nubmer when journal is stored to a volatile backend.
>> We totally agree that a minimum size must be below 1MB either on flash or
>> ramfs for embedded devices. otherwise you end up with two solutions for smaller
>> and bigger devices. Is there any reference about the overhead if you use smaller
>> file size? Is there technical limitation for a minimum size?
> No, there's no real technical limitation. Except some hero should go through
> src/jounal/journal-file.c and adjust all the constants that they also work
> with very small files.
>
> Zbyszek


Hi,

the minimum file size changed in version 203 from 64KiB to 4MiB. Is 
there a special reason for this? The relevant code line seems to be

     #define JOURNAL_FILE_SIZE_MIN (4ULL*1024ULL*1024ULL)      /* 4 MiB */

which did not change in 208.

Sascha