Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

Offload large files (4 MB+) to R2

未关闭
#217 4 条评论 1 个 reaction 已指派 1 人 在 GitHub 查看

维护者通常 1 天内回复

@aron-cf 已经在做这个了。

开始于 2026年10月8日。

评估

这个 Issue 还没有评估数据。

描述

enhancement

vfs_* tables in Durable Object SQLite hold all file content today, so a workspace is capped at the Durable Object storage limit (about 10 GB). R2 mounts are read-only, which means a writable file can't live outside that cap.

@cloudflare/shell in cloudflare/agents had a hybrid model. It kept small files inline in SQLite and moved files over a size threshold to R2. We're deprecating Shell in favour of Computer, and some agents (media, datasets, build outputs) will need large writable files.

Proposal
  • Add an optional R2 bucket to WorkspaceOptions, along with a size threshold. The default would be 4 MB.
  • When a write reaches the threshold, the content goes to R2. vfs_nodes keeps the metadata and a pointer to the R2 key. The key is scoped by workspace, using the session id or DO id.
  • Reads through workspace.fs, the worker backends, and the container sync path resolve the pointer without the caller knowing about it. A read of an R2-backed file returns a stream, so the bytes never pass through SQLite.
  • rm, overwrite, and gc() delete the R2 object they replace.
  • Without a bucket, behaviour stays as it is today.
Open questions
  • Should content-addressed blob dedup extend to R2 objects, or should R2 hold one object per file?
  • Container sync could pull large R2-backed files on demand instead of copying them into the container's in-memory VFS. Is that in scope here?
主要语言
TypeScript
星标
9.5k
派生
552
平均合并
1 天 21 小时
30 天内合并 PR
42

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

cloudflare/computer 的其他 Issue

查看 cloudflare/computer 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。