fix(storage): invalid storage details cache after writing operations - #2018
fix(storage): invalid storage details cache after writing operations#2018hcrgm wants to merge 2 commits into
Conversation
…enaming/copying/removing/puting Signed-off-by: hcrgm <hcrgm@qq.com>
hcrgm
changed the title
…an error Signed-off-by: hcrgm <hcrgm@qq.com>
| details, err, _ := detailsG.Do(storage.GetStorage().MountPath, func() (*model.StorageDetails, error) { | ||
| ret, err := wd.GetDetails(ctx) | ||
| if err != nil { | ||
| Cache.InvalidateStorageDetails(storage) |
There was a problem hiding this comment.
此时Cache中还没有storage的容量信息，该语句产生的效果一定是什么也不做
| if storage.Config().NoCache { | ||
| return nil, nil | ||
| } | ||
| Cache.InvalidateStorageDetails(storage) |
There was a problem hiding this comment.
绝大多数情况下创建文件夹、移动、重命名都不会影响空间占用，不需要删除缓存
| Cache.linkCache.DeleteKey(stdpath.Join(dstKey, srcRawObj.GetName())) | ||
| } | ||
| if !storage.Config().NoCache { | ||
| Cache.InvalidateStorageDetails(storage) |
| Cache.linkCache.DeleteKey(stdpath.Join(dirKey, dstName)) | ||
| } | ||
| if !storage.Config().NoCache { | ||
| Cache.InvalidateStorageDetails(storage) |
a31fd53 to
7bea29c
Compare
pikachuren
left a comment
pikachuren
left a comment
There was a problem hiding this comment.
🙏 感谢 @hcrgm 提交！
🤖 AI 自动审核声明：本评审报告由 AI 自动生成，当前使用 Claude Opus 5 模型进行分析。
🎯 结论
✅ 建议 Approve（由维护者人工确认）— 改动一致性好，仅需确认高频写入下的性能影响
📖 概要
fix(storage): invalid storage details cache after writing operations · 修复写操作后存储容量信息仍显示旧缓存的问题。
核心改动：在 MakeDir / Move / Rename / Copy / Remove / Put / PutURL 成功后调用 Cache.InvalidateStorageDetails，并在 GetDetails 失败时清理缓存。
🧭 整体方案
技术路线直接明了：所有会改变存储占用的写操作在成功后主动失效容量缓存，下次查询自然重新探测。改动点覆盖完整、位置一致（都在 !storage.Config().NoCache 保护内），方案合理。
📊 变更统计
2 个文件（+8 / -0 行） | 功能 ⭐⭐⭐⭐⭐ | 最小改动 ⭐⭐⭐⭐⭐ | 前向兼容 ⭐⭐⭐⭐⭐ | 方案设计 ⭐⭐⭐⭐
🚨 关键问题
P0（阻塞合并）：无
P1（建议修复）：无
P2（可选）：
- 💡
internal/op/fs.go— 批量场景（例如一次上传数百个文件）会对同一存储高频触发失效，导致后续每次查询都重新探测容量。对于探测代价高的网盘驱动（需要额外 API 调用），可能带来额外压力。是否考虑加一个轻量的合并窗口（例如失效后 N 秒内不重复探测）？不过这与 #2950 引入的 cooldown 机制存在重叠，建议两个 PR 的作者对齐一下~ - 💡
internal/op/storage.go— 在GetDetails返回错误时调用InvalidateStorageDetails，意味着一次网络抖动就会清掉本来还有效的旧数据，前端可能从「显示旧容量」退化为「显示-」。是否考虑仅在明确的鉴权/存储失效类错误时才清缓存，普通网络错误保留旧值呢？ - 💡 与 #2950 在
internal/op/storage.go同区域均有改动，合并时可能产生冲突，建议维护者留意先后顺序~
📂 逐文件分析
internal/op/fs.go
改动意图：写操作后让容量缓存失效。
代码逻辑：7 处写操作成功分支中统一插入 Cache.InvalidateStorageDetails(storage)。
问题分析：插入位置一致且都在 NoCache 判断保护内，无遗漏；Remove 处放在 err == nil 内也正确。唯一可讨论的是高频写入下的探测放大（见 P2）。
详细建议：无需改动，若采纳合并窗口建议可与 #2950 统一实现。
internal/op/storage.go
改动意图：探测失败时不保留可能已失效的缓存。
问题分析：策略偏激进，建议区分错误类型（见 P2）。
✅ 待处理清单
- [P2] 评估批量写入场景下的探测放大，考虑与 #2950 的 cooldown 机制对齐
- [P2] 评估
GetDetails失败时是否应保留旧缓存 - [P2] 与 #2950 协调
internal/op/storage.go的合并顺序
🎯 结论：✅ 建议 Approve — 覆盖完整、实现一致的合理修复，建议项均为可选优化。
|
建议修复P2问题后合并 |
5 participants
Description / 描述
对存储驱动写操作成功后（上传、删除等），清除存储驱动的详情缓存，使容量数据更实时、准确。
Motivation and Context / 背景
发生上传、删除等写入操作后，容量信息没有发生变化，需要重新加载存储、根目录刷新或等缓存自然过期才发生变化。
How Has This Been Tested? / 测试
Checklist / 检查清单
我已阅读 CONTRIBUTING 文档。
go fmtor prettier.我已使用
go fmt或 prettier 格式化提交的代码。我已为此 PR 添加了适当的标签（如无权限或需要的标签不存在，请在描述中说明，管理员将后续处理）。
我已在适当情况下使用"Request review"功能请求相关代码作者进行审查。
我已相应更新了相关仓库（若适用）。