Skip to content

[Feature] 自动/显式使用内存/磁盘缓冲文件上传 #3073

Open

Description

@vxtls

请确认以下事项

  • 我已确认阅读并同意 AGPL-3.0 第15条 。
    本程序不提供任何明示或暗示的担保,使用风险由您自行承担。

  • 我已确认阅读并同意 AGPL-3.0 第16条 。
    无论何种情况,版权持有人或其他分发者均不对使用本程序所造成的任何损失承担责任。

  • 我确认我的描述清晰,语法礼貌,能帮助开发者快速定位问题,并符合社区规则。

  • 我已确认阅读了OpenList文档。

  • 我已确认没有重复的问题或讨论。

  • 我认为此问题必须由OpenList处理,而非第三方。

  • 我已确认此功能尚未被实现。

  • 我已确认此功能是合理的,且有普遍需求,并非我个人需要。

  • 我没有阅读这个清单,只是闭眼选中了所有的复选框,请关闭这个 Issue 。

需求描述

CacheFullAndWriter 在某几个驱动下,包括

  1. terabox
  2. weiyun
  3. degoo
  4. mopan
  5. wps
  6. mediatrack
  7. netease_music
  8. alias (仅多目标存储时)
    会将大文件读入内存,在低内存机器上,此默认行为将导致程序OOM并退出。
    CacheFullAndHash 方法在特定条件下也会调用 CacheFullAndWriter 方法
    以上为driver端问题。
    在S3上传端,使用gofakes3时,multipart上传存在死代码(初步看下来是这样,如果不对欢迎指正), S3 上传的流永远没有 hash:
    server/s3/backend.go:246 putStream 构造的是:
obj := model.Object{Name: ..., Size: ..., Modified: ..., Ctime: ...}

GetHash() 返回空串(len("") != Width),所以程序中所有"缺 hash 才缓存"的判断对 S3 上传全部成立 -> 全部走整文件缓存,导致内存multipart从未被使用,这部分不会导致此次issue的OOM,但是理论上增加磁盘读写,期望可以真正实际使用到这部分功能,采用显示指定memory/disk/auto来设置。

实现思路

修改/重构 CacheFullAndWriter 和与其相关的 NewHybridCache方法
支持显示配置 memory(总是使用内存),disk(总是使用磁盘临时文件),auto(根据内存情况选择采用内存/存储)。默认auto,用户无需新增/显示配置任何内容
当前NewHybridCache 逻辑为从 f.GetSize() + MinFreeMemory > 0直接选择采用内存,这个判断在我看来是不可靠的

对于gofakes3,当前实际上有in-memory multipart buffer,也有基于磁盘的缓存,由于multipart upload 的时候不要求知道对象最终总大小,所以在实现auto的时候直接选择disk,而不是memory,除非显示选择memory。

对于自动选择,使用内存,使用存储,可以抽象为公共方法,供driver和其他的模块使用

附加信息

  • 使用AI工具阅读代码并定位问题 模型为GPT 6 Astra High & Codex,issue为人工撰写
  • 这个issue的创建目的是占个位,之后我会提交PR,有意见欢迎讨论
  • 文档将会在后续添加

AI生成内容

  • 我使用了AI工具生成此内容
  • 我没有使用AI工具生成此内容

AI模型是

gpt-6-astra

Activity

  1. changed the title [-][Feature] 自动/显示使用内存/磁盘缓冲文件上传[/-] [+][Feature] 自动/显式使用内存/磁盘缓冲文件上传[/+] on Sep 12, 2026
  2. vxtls commented on Sep 12, 2026

    @vxtls
    ContributorAuthor

    Related: #2460
    重新看了一下,HybridCache 本身的 mechanism 已经比较完整,问题主要在 policy 和覆盖范围。
    当前策略更接近“只要当前还有可用内存就继续扩容,失败后再 spill 到 disk”,而不是在开始缓存前基于对象大小和内存预算决定 backing store。这在并发上传、container/cgroup/swap 等场景下可能导致判断过于乐观。这很有可能导致意外的OOM,希望给用户显式配置的接口,如果用户有足够的内存可以减少磁盘读写。
    目前有的调用路径不会经过 HybridCache,部分调用方仍然有自己的缓存实现/选择逻辑,因此 #2460 实际上没有覆盖全部上传/下载路径。
    这个 issue 会尽量复用现有 HybridCache,主要补充统一的 auto / memory / disk policy

  3. reopened this on Sep 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions