Thanks for providing details @bendavis
Do you have a way to access the Theia app backend log? It’s the container’s entrypoint, so it’s probably also the container’s log. I wonder if there might be clues at to what’s happening. Please also check in the frontend app, in the dev tools’s console, for any suspicious errors or warnings.
In my experience, this can introduce nothing but problems, when used in a Linux context. E.g. permissions not quite mapping well. Do you know if the whole container’s storage is on that SMB mount or only the workspace? Would file operations in /tmp or writing system logs in /var/log count towards these metrics? Would the file reads required to start the Theia application count?
I do not know if the inotify
kernel-level file-watcher mechanism we use on Linux, through the nsfw
library, works well on a SMB mount.
A theory:
In Theia apps, we use inotify
to watch the workspace folder, recursively. But there a few important config files that are watched individually, like settings.json
on the current workspace and in the user’s home ~/.theia/settings.json
I think. As well task.json
and maybe a few others. We rely on the watching mechanism to re-rad these files, when notified they were modified.
IIRC, with nsfw
on Linux, individually-watched files do not rely on inotify
and instead use a poling mechanism to detect changes or deletion. If we have let’s say 5 of these files watched by polling, each polled e.g. every second, that’s at least ~300 operations a minute. It’s quite possible that e.g. one poll operation, e.g. using the “stat” system call, needs to be translated into multiple SMB operations, each poll then potentially triggering multiples of the listed counters. If hypothetically 4 NFS counters were triggered, on average, each times a nsfw poll happens, we then get close to what you’re observing.