Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-4446GitHub issuePublicReceived

omarchy-walker: elephant-files indexer causes sustained disk I/O storm (load avg ~8, 30+GB writes) on btrfs/LUKS

Reported by faik · filed Jun 2, 2026Closed upstream on 2026-07-18 by dhh. GitHub close reason: completed. No closing PR or commit is recorded — "completed" alone is not evidence of a fix.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
Not yet mapped to any requirement or component.
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

omarchy-walker: elephant-files indexer causes sustained disk I/O storm (load avg ~8, 30+GB writes) on btrfs/LUKSrevision 1 · captured 2026-10-04 11:56 UTC via poll

System details

Intel Core i7-1165G7, Intel Iris Xe Graphics (integrated), Omarchy 3.8.1, Hyprland 0.54.3, kernel 7.0.3-arch1-2

What's wrong?

What happened

On an idle machine the load average sat at ~8 while CPU was 95% idle — i.e. pure I/O-wait, not compute. Tracing it down:

  • The culprit is the `elephant-files` provider (shipped by the omarchy-walker meta-package), which maintains a SQLite filesystem index at

~/.cache/elephant/files.db.
- On this machine that DB grew to 1.6 GB, and the elephant process had accumulated ~34 GB of disk writes over ~11 days uptime, with active WAL
(files.db-wal) churn ongoing even while the machine was idle.
- On a btrfs-over-LUKS setup this is amplified — the indexer's reads/writes fan out into a swarm of kcryptd and btrfs-endio-meta kworkers, dragging the whole
system's interactivity down.

### Why this is surprising

  • The files provider is not in the default provider set in ~/.config/walker/config.toml — it's only reachable via the . prefix. So Omarchy indexes the

entire filesystem for a feature most users rarely (or never) invoke.
- ~/.config/elephant/files.toml already ships with watch=false, yet the provider still generates tens of GB of writes — suggesting periodic full re-scans / WAL
checkpointing rather than just inotify watching.

### Versions

  • omarchy-walker 1.0.0-2
  • walker 2.16.2-1
  • elephant / elephant-files 2.21.0-1
  • Filesystem: btrfs on LUKS (dm-crypt)

### Impact

Sustained background disk I/O, multi-GB daily writes (SSD wear), high load average, and degraded interactivity on encrypted/btrfs systems — with no visible feature
benefit for users who don't use .-prefix file search.

### Suggested fixes (any of)

  1. Don't ship `elephant-files` enabled by default, or make it opt-in, since it's only behind the . prefix.
  2. Constrain the files provider's index scope (e.g. $HOME minus caches/node_modules/.git, with a max depth) instead of a broad crawl.
  3. Investigate why watch=false still produces large sustained writes — looks like it's doing repeated full re-indexing / unbounded WAL growth rather than incremental

updates.
4. Document how to disable it: sudo pacman -Rdd elephant-files + remove the . prefix from ~/.config/walker/config.toml.

### Workaround

  systemctl --user stop elephant
  rm -f ~/.cache/elephant/files.db*
  sudo pacman -Rdd elephant-files          # removes only the files provider
  # remove the [[providers.prefixes]] '.' → files block from ~/.config/walker/config.toml
  systemctl --user start elephant

  Walker continues to work fully for apps, calc, clipboard, websearch, symbols, etc. — only .-prefix file search is lost.
View raw text
### System details

Intel Core i7-1165G7, Intel Iris Xe Graphics (integrated), Omarchy 3.8.1, Hyprland 0.54.3, kernel 7.0.3-arch1-2

### What's wrong?

### What happened

  On an idle machine the load average sat at **~8 while CPU was 95% idle** — i.e. pure I/O-wait, not compute. Tracing it down:

  - The culprit is the **`elephant-files`** provider (shipped by the `omarchy-walker` meta-package), which maintains a SQLite filesystem index at
  `~/.cache/elephant/files.db`.
  - On this machine that DB grew to **1.6 GB**, and the `elephant` process had accumulated **~34 GB of disk writes** over ~11 days uptime, with active WAL
  (`files.db-wal`) churn ongoing even while the machine was idle.
  - On a **btrfs-over-LUKS** setup this is amplified — the indexer's reads/writes fan out into a swarm of `kcryptd` and `btrfs-endio-meta` kworkers, dragging the whole
  system's interactivity down.

  ### Why this is surprising

  - The `files` provider is **not in the default provider set** in `~/.config/walker/config.toml` — it's only reachable via the `.` prefix. So Omarchy indexes the
  **entire filesystem** for a feature most users rarely (or never) invoke.
  - `~/.config/elephant/files.toml` already ships with `watch=false`, yet the provider still generates tens of GB of writes — suggesting periodic full re-scans / WAL
  checkpointing rather than just inotify watching.

  ### Versions

  - omarchy-walker 1.0.0-2
  - walker 2.16.2-1
  - elephant / elephant-files 2.21.0-1
  - Filesystem: btrfs on LUKS (dm-crypt)

  ### Impact

  Sustained background disk I/O, multi-GB daily writes (SSD wear), high load average, and degraded interactivity on encrypted/btrfs systems — with no visible feature
  benefit for users who don't use `.`-prefix file search.

  ### Suggested fixes (any of)

  1. **Don't ship `elephant-files` enabled by default**, or make it opt-in, since it's only behind the `.` prefix.
  2. Constrain the files provider's index scope (e.g. `$HOME` minus caches/`node_modules`/`.git`, with a max depth) instead of a broad crawl.
  3. Investigate why `watch=false` still produces large sustained writes — looks like it's doing repeated full re-indexing / unbounded WAL growth rather than incremental
  updates.
  4. Document how to disable it: `sudo pacman -Rdd elephant-files` + remove the `.` prefix from `~/.config/walker/config.toml`.

  ### Workaround

  ```bash
  systemctl --user stop elephant
  rm -f ~/.cache/elephant/files.db*
  sudo pacman -Rdd elephant-files          # removes only the files provider
  # remove the [[providers.prefixes]] '.' → files block from ~/.config/walker/config.toml
  systemctl --user start elephant

  Walker continues to work fully for apps, calc, clipboard, websearch, symbols, etc. — only .-prefix file search is lost.

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

No decision has been recorded yet.