Re: minimum space needed for reload/reexec

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

e65;6401;1cOn Mi, 30.06.21 11:39, CHEN, Jack (zenghuchen@xxxxxxxxxxx) wrote:

> Hi,
>
> I happen to see to a fix in system, which adds a space checking before reload/reexec.
> >From the code:
> Require 16MiB free in /run/systemd for reloading/reexecing. After all we need to serialize our state there, and if
> * we can't we'll fail badly
> #define RELOAD_DISK_SPACE_MIN (UINT64_C(16) * UINT64_C(1024) * UINT64_C(1024))
> And I got further explanation from poettering:
> it's a "safety buffer", see commit msg of the fix. It's set to 16M because it has to be set to something, and it sounded like a reasonably value, and so far we got no feedback to the contrary
>
> However, just for “serialize our state there”, literally, there is
> no need for such a big space (16M).

We can't precisely estimate that, since the space required for tmpfs
inodes is not clear to us from userspace in advance.

Note that 16M is a safety limit. It doesn't mean that we actually
intend to use that much. it just says, let's better not try if there's
less than this available. Much likely we'll use much less than the
16M. Hence, please don't misunderstand this as "this is how much we'll
use", but as "let's not try if less than this is available".

There's simply no Linux kernel API for querying in advance explicitly
how much space would be subtracted from the current free space of a
tmpfs instance if we'd write a single file of size X with a filename
of Y there.

> There is no problem for PC. But for embedded devices, 16M is quite prodigal.
> And in my test, even 1M free space would allow reloading/reexecing
> to work normally.

Bigger systems have bigger state serializations though.

> Shall we remove this restriction? (Removing I mean we just check if there is free space or not) Or at least lower the threshold.
> It is not good to forbid reloading/reexecing when there is enough free space, just because it is smaller than the threshold (16M)。

Removing is not an option. We added it for a reason: people filled up
their /run/ by accident and then issued "systemctl daemon-reload"
which would fail half-way because the file system was full.

I'd be willing to take a patch that changes this to

MIN(16*1024*1024, physical_memory_scale(2, 100));

or something like this.

This would mean we'd scale the safety net by the amount of physical
memory in the system. i.e. 2% of physical RAM, but 16M at most. This
should then cover your case too? i.e. enforce a lower limit on smaller
systems, and the existing 16M limit on bigger ones?

(I pulled the 2% out of my hat, whatever makes sense..)

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel