Bug #6438
open
write_config_file() calls blocking sync()
Added by laforge 27 days ago.
Updated 22 days ago.
Description
src/vty/command.c:write_config_file() calls [potentially twice] sync() which globally syncs all files to non-volatile storage. This can take a long time, particularly on systems with a lot of I/O or slow I/O (rotating media like HDD).
As fixeria pointed out on IRC, all we really want is @fsync() semantics, i.e. ensure that this single file is committed to storage.
I'd actually go even further and do that fsync call from a separate, single-purpose thread. Once it completes, we can print a message to the telnet/vty session [if it still exists].
IIUC so far our VTY access is single-thread and not "async enabled".
Do we have a way to do VTY requests/responses in async fashion?
Do we have a mechanism where we can tell whether a VTY session is still active?
IIUC this is a new paradigm for VTY, could be a larger effort to make VTY thread-safe...
Hi Neels,
On Fri, Apr 26, 2024 at 04:19:37AM +0000, neels wrote:
IIUC so far our VTY access is single-thread and not "async enabled".
what do you even mean by this? I'm not following
Do we have a way to do VTY requests/responses in async fashion?
all VTY input from telnet sessions is processed via normal asynchrnonous non-blocking I/O,
like all of our other I/O. I already wrote this several days ago somewhere in gerrit, I believe.
Do we have a mechanism where we can tell whether a VTY session is still active?
A VTY session by definition is active
IIUC this is a new paradigm for VTY, could be a larger effort to make VTY thread-safe...
Who said anything about thread-safety? This issue is about performing a blockiong sync in code
that otherwise doesn't perform any blocking I/O.
lick here: https://osmocom.org/my/account
Also available in: Atom
PDF
