zellij frequent disk write activity

[fungos]

Basic information

zellij --version: 0.39.2

stty size:

uname -av or ver(Windows): Linux x 6.6.10-1-MANJARO #1 SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

Further information

Reproduction steps, noticeable behavior, related issues, etc

2. Issues with the Zellij UI / behavior / crash

Issue description

While running in foreground or even detached, the disk activity of zellij seems to do too frequent writes on disk. I have an unusual noisy disk, and I detect what I consider bad behavior on software by the noise the disk does. After trying zellij for a few days, I noted my disk was a lot more noisy than habitual. Looking at sudo iotop I can see zellij doing lots of tiny writes too frequent which is causing my disk to spin when my computer should be idle. Other software causes this kind of writes, mostly writing sessions to disk, like firefox. But the frequency of the writes is not that elevated which keeps the noise to somewhat acceptable threshold, but zellij in comparison to these other seem to be doing something between 3-5 more writes.

Minimal reproduction

Other relevant information

[pedromfedricci]

Zellij takes snapshots of all active sessions every 1sec (link). I guess that might be all the noise that you are seeing. Looking at the docs, there is no way to change the default interval, but you can disable it all together with session_serialization false (link) in your config. Try running Zellij with the serialization option disabled to see if that is the issue. Another option is that there is indeed some abnormal behavior going on. Figuring it out the root cause will require some more digging. Monitor Zellij's log at /tmp/zellij-1000/zellij-log/zellij.log while running it, look out for patterns that could hint what is the problem. It is even possible that the frequent writes you are seeing are actually Zellij writing to the log file constantly.

[fungos]

I can confirm it is the session being serialized, maybe exposing a setting to change the frequence would be nice to have.

[shanesveller]

Configuration option sounds like a welcome step forward - for example I personally would dial it down to something more like 60sec-5min on my own systems given the opportunity. If it doesn't already, maybe also ensure that the session-quit command (Ctrl-O Q?) does one last flush of the current state to the serialized copy.

[sandorex]

I believe this is already an option serilization_interval at https://github.com/zellij-org/zellij/blob/b677ffe75fb8e518441a0bd7df02abfb8dcc4989/zellij-utils/src/input/options.rs#L153C9-L153C31 But the caveat is that its a commandline argument not parsed from config from what i can see

[cristiand391]

From the code and this comment it seems it's available as a config var: https://github.com/zellij-org/zellij/issues/2946#issuecomment-1814436010

I've seen some other options undocumented (they aren't generated from code).

[cristiand391]

Also, in this PR the default serialization interval changed from 1s to 60s: https://github.com/zellij-org/zellij/pull/2923

[pedromfedricci]

PR #2923 (v0.39.1) introduced the serialization interval config (not documented yet) and PR #2951 (v0.39.2) changed the default interval from 1sec to 60sec for how often the layout is serialized into memory. But the background job still writes into both session-metadata.kdl and session-layout.kdl (only after its first flush in this case) files every second for all active sessions (code), regardless of what the serialization_interval value is. My reading so far is that this is indeed a bug.

[justinlovinger]

I disabled session_serialization, but I still see a consistent 4KB/s disk-write activity for every session, alongside constant CPU-usage, even when idle. I am on version 0.39.2.

[pedohorse]

4KB/s disk-write activity

For me it's 150-200 KB/s of read and around 80-100 KB/s of write. I have 3 sessions almost always running, each reads the whole config each second, and writes seemingly only it's part to it.

So far I was just hoping that kernel/fs-driver optimizes those writes somehow and it's not actually always writes to the device.

It would be very nice to have that thing configurable.

[imsnif]

In addition to disabling session serialization you can now also disable writing the session metadata to disk with: disable_session_metadata true/false - note that this might cause features such as the session-manager not to work properly.

[pedohorse]

I've made a little draft PR just to illustrate one possible solution to the issue - just making the poll interval configurable

3298

[shimunn]

I've made a little draft PR just to illustrate one possible solution to the issue - just making the poll interval configurable

3298

Seems like this has already found it's way into zellij as: serialization_interval

[camtauxe]

Seems like this has already found it's way into zellij as: serialization_interval

Unfortunately the serialization_interval setting also does not work: see above

[pedohorse]

there is serialization_interval, but that PR is about a different polling interval. Even when not serializing anything, zellij is loading all session data, checks it and saves it back. this is how one instance of zellij can always see all session info in the session manager.

the downside of increasing this interval is that you will not see up-to-date session information in the session manager

[vi]

Maybe it should save session information only when something is changed (i.e. still run a timer, but skip serializing when nothing has changed) and load all session data only when that session manager is being accessed?

[pedohorse]

Maybe it should save session information only when something is changed (i.e. still run a timer, but skip serializing when nothing has changed) and load all session data only when that session manager is being accessed?

i can add my opinion since noone else answered yet: (disclaimer: I've looked into the code once so this is my surface opinion) it always reads/writes the session file because it uses that file to sync session managers that are running on different zellij instances. So there is no way to know that session file was changed unless you constantly poll it (or rely on file metadata?). But it does feel that writing it back is unnecessary if nothing has changed in the current session

[Dietr1ch]

it always reads/writes the session file because it uses that file to sync session managers that are running on different zellij instances. So there is no way to know that session file was changed unless you constantly poll it (or rely on file metadata?).

Synchronising multiple instances on a file seems alright, but only as long as that file is in-memory.

I feel that writes to persistent disk are only necessary on events like shutting down or explicit user saves, but permissible under timers that let disks idle/sleep, so at least 2 minutes, preferably 5+

But it does feel that writing it back is unnecessary if nothing has changed in the current session

This would probably help unless something silly like a timestamp is sneaking in and changing the file every time.