Issue: Excessive Btrfs Metadata Usage Caused by OpenCode #51836

Activity

1. github-actions

   assigned

   nexxeln

   on Sep 28, 2026
2. github-actions commented on Sep 28, 2026

   

   github-actionsBot

   on Sep 28, 2026 – with GitHub Actions

   Contributor

   More actions

   This report may overlap with existing OpenCode database/event-storage growth reports, particularly if the Btrfs metadata increase is driven by opencode.db or EventV2 history.

   ---

   This issue might be related to existing issues. Please check:

   • #47854: EventV2 historical snapshots can duplicate large payloads and amplify SQLite storage.
   • #47022: Database reached ~72 GB during normal use, mostly from the event table.
   • #46833: Linux database reached ~9 GB, largely from repeated message.updated.1 snapshots.
   • #33356: Unbounded event-table growth from retained message snapshots.
3. opencode-agent commented on Sep 28, 2026

   

   opencode-agentBot

   on Sep 28, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for reporting this. We'd like to distinguish Btrfs metadata used from metadata allocated, and identify which OpenCode storage component is growing. Could you share the following from the affected machine, ideally once before a session and again when the slowdown starts?

   btrfs filesystem usage -T "$HOME/.local/share/opencode"
   du -h --max-depth=2 "$HOME/.local/share/opencode" | sort -h | tail -30
   find "$HOME/.local/share/opencode/snapshot" -type f | wc -l
   ls -lh "$HOME/.local/share/opencode"/opencode.db*

   If your OpenCode data directory is elsewhere, substitute its actual path. Also, how did you arrive at the ~8 GB figure attributed to OpenCode metadata (rather than file data), and are there Btrfs/ENOSPC messages in the kernel log around the hangs? Please redact any private paths or content before sharing logs. No need to delete snapshots or the database to collect these measurements.
4. swadhinbiswas commented on Sep 29, 2026

   

   swadhinbiswas

   on Sep 29, 2026

   Author

   More actions

   Thanks for following up. Here are answers to your questions.

   Data directory

   OpenCode's data is in the default location, ~/.local/share/opencode. I moved it into its own Btrfs subvolume so its storage could be measured separately from the rest of the disk.

   The ~8 GB figure

   I got this after putting OpenCode's data in a dedicated subvolume, which has its own metadata tree. With that isolation, about 8 GB of Btrfs metadata was attributable to OpenCode's data. I measured it by [state your method, e.g. tree block count × nodesize from btrfs inspect-internal dump-tree, or the change in btrfs filesystem df metadata used while only OpenCode was writing].

   The 12 GB in my original report was the filesystem-wide allocated metadata, not OpenCode-specific. The 8 GB figure comes from the subvolume measurement.

   Kernel log(I do forget to collect that )

   BUT
   I've attached a screenshot of the crash log from around the hangs.
   

   What fixed the hangs

   I was running OpenCode from my home directory. After adding this to my config, the hangs and crashes stopped and the system is normal again:

   {
     "watcher": {
       "ignore": [
         "node_modules/**",
         ".git/**",
         "dist/**",
         ".cache/**",
         ".local/**"
       ]
     }
   }

   My interpretation

   Running from ~ likely made OpenCode watch and snapshot a very large tree. That would create many small files (heavy metadata on Btrfs) and many watches. The watcher config fixed the instability, but I haven't separated the watcher's effect from the snapshot storage growth, so both may have contributed.
5. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed write-up, @swadhinbiswas. To work out which part of OpenCode's storage is growing, could you share some numbers from your machine?

   1. Size and file count for each OpenCode data directory:

      cd ~/.local/share/opencode
      du -sh ./*
      for d in ./*/; do echo "$d $(find "$d" -type f | wc -l)"; done

      Please also run the same for ~/.cache/opencode and ~/.local/state/opencode if they exist.
   2. If snapshot/ is large, the output of the commands below for one of its folders (replace the path):

      du -sh ~/.local/share/opencode/snapshot/*/*
      git --git-dir ~/.local/share/opencode/snapshot/<project>/<hash> count-objects -v

   3. Roughly how big are the repositories you use OpenCode in (number of files, and whether they contain large or generated directories such as node_modules or build output)?
   4. The output of sudo btrfs filesystem df / (or btrfs filesystem usage /), so we can see the metadata numbers.

   You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it so we know you're done.
6. opencodejr

   added

   triaging

   on Oct 28, 2026
7. opencodejr

   closed this as not plannedon Oct 31, 2026
8. opencodejr commented on Oct 31, 2026

   

   opencodejrBot

   on Oct 31, 2026

   Contributor

   More actions

   Closing this for now: we haven't heard back with the storage details we asked for, and without them we can't tell which part of OpenCode's data is causing the Btrfs metadata growth.

   If it happens again, please reopen this issue or open a new one and include:

   • the per-directory sizes and file counts for ~/.local/share/opencode
   • the output of btrfs filesystem df /

   With those we can look into it. Thanks for the report, @swadhinbiswas!
9. opencodejr

   reopened this on Nov 3, 2026
10. neriousy

    closed this as not plannedon Nov 12, 2026