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.
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.
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.