从接触 SeaweedFS 到现在我遇到过不少朋友问同一个问题集群跑着跑着想看看 volume 到底占了多大磁盘结果有人贴df -h有人贴 master 的 volume 列表还有人直接把数据目录整个du -sh出来——不能说谁错但这种片段式信息放到排障和容量规划里根本不够用。这篇是 SeaweedFS 系列的第 5 节内容专门把“查看 volume 磁盘占用”这件事拆开讲清楚包括不同视角的数据口径、几个常用查询方式、以及占用数字异常时的排查和回收方法。先说结论SeaweedFS 里“磁盘占用”不是一个单一数字而是要分三层看。1. 明确三层占用口径逻辑数据、文件空洞、物理块1.1 为什么df -h和 master 看到的数字经常对不上很多人第一反应是登录 volume server 敲df -h看一下挂载点还剩多少。这个操作本身没毛病但它反映的是整个数据目录甚至整块磁盘的使用率包含了索引文件、日志、临时文件、快照文件还有其他业务可能共用的空间。而 master 的/vol/status接口返回的是每个 volume 文件的相关统计两者口径差得很远。更本质的原因是一个 volume 在 volume server 本地并不是一个文件夹而是以 volume id 命名的一组文件核心是xxx.dat和xxx.idx。.dat是数据文件追加写入.idx是索引文件记录每个文件片段的偏移量。你通过 Filer 的挂载路径看到的是文件、目录这些逻辑结构而 volume server 硬盘上躺着的是一堆编号文件它们之间没有一一对应的关系。所以直接拿df的输出去回答“volume 占了多少”只能得到一个很粗的磁盘水位得不到 volume 颗粒度的答案。想要准确回答这个问题至少要看三个层面的数据查看层面数据含义典型来源逻辑数据量每个 volume 里实际存了多少有效字节master 的 volume 状态接口文件空洞量已逻辑删除但还在 .dat 文件里占位的字节本地文件ls与du对比物理磁盘占用数据文件真正消耗的文件系统块du、df等本地命令1.2 先记住 volume 状态接口里的几个关键字段不同版本 SeaweedFS 对返回结果里字段名的写法略有差异但出现次数最高的几个字段含义是稳定的。只要你看过一遍/vol/status的输出后面排查就会熟练很多Idvolume 编号也就是对应本地xxx.dat里的 xxx。Sizevolume 数据文件的当前大小通常可以理解为文件逻辑长度。DataSize当前仍有效的文件数据字节数也就是真正“活着”的内容。FileCount该 volume 里文件片段的数量注意它不是业务上的用户文件数量而是 chunk 层面的数量。DeleteCount与DeletedBytes已标记删除的文件片段数量和字节数。这两个数字是判断 volume“虚胖”的关键指标。一个 volume 的Size明显大于DataSize且DeletedBytes不低时基本可以判定这个 volume 处于“空间膨胀”状态常见于大量删除但未做 vacuum 回收的场景。1.3 从顶层理解master、volume server、本地文件系统的三角关系在动手敲任何命令之前把三角关系理清楚能省下很多时间master 只负责 volume 的元信息和调度决策它知道每个 volume 分布在哪台 volume server 上、副本数是多少、每个 volume 的统计状态是什么但它不直接掌握本地文件的物理块分配情况volume server 负责读写数据和维护本地文件但它向 master 上报的数据也只是统计值不是du结果真正决定磁盘可用空间的是下游的文件系统。所以完整排查一条链路是先通过 master 的接口拿到全局逻辑视图再到对应的 volume server 上确认物理文件大小最后对比两者的差值定位异常。下面一个个来。2. 从 master 拿全局视图/vol/status接口用法2.1 请求方式和最小可用命令master 默认监听在 9333 端口最简单的一条命令curl -s http://127.0.0.1:9333/vol/status?prettyy不加prettyy也可以只是输出会被压缩成一大行肉眼不太好看。如果你只关心机器可读的 JSON不关心排版用?formatjson或者在请求头带上正常 JSON 解析就行。生产环境我一般写成curl -s http://127.0.0.1:9333/vol/status?formatjson如果集群有多个 master最好把请求发到当前 leader 上或者在 master 前面挂了负载均衡就发到负载均衡地址避免连到非 leader 节点拿不到最新状态。具体怎么找 leader可以直接看 master 的日志输出或者通过weed shell进去看集群状态后面会提到。2.2 返回结构怎么读以新一点的版本为例响应体里通常包含版本号、volume 总数、空闲 volume 列表、最大 volume 数量限制以及核心的Volumes数组。我调过不少版本字段大小写在不同版本间有小幅变化但大体结构是稳定的。一个典型条目类似{ Id: 5, Collection: , Size: 1073741824, ModifiedAtSecond: 1712839234, FileCount: 8321, DeleteCount: 1203, DeletedBytes: 214748364, ReadOnly: false, CompactRevision: 4, DataSize: 858993459 }这里Size是 1 GiBDataSize只有约 800 MiBDeletedBytes约 200 MiB说明有约 20% 的空间已经被逻辑删除。如果你要快速统计整个集群的逻辑数据总量把DataSize求和就是如果想知道磁盘上实际被 volume 文件占掉多少把Size求和只能算一个近似值因为文件系统还有稀疏空洞的问题这部分得看本地du。2.3 一个能直接用的统计脚本因为接口返回的是 JSON拿jq或 Python 处理都很快。我平时用的一个巡检片段是这样curl -s http://master:9333/vol/status?formatjson | jq -r .Volumes[] | [.Id, .Collection, .Size, .DataSize, .FileCount, .DeleteCount, .DeletedBytes] | tsv | sort -t $\t -k7 -n -r | head -20jq字段名如果和你版本不一致把Volumes换成实际返回的键名就行。跑出来的结果会按DeletedBytes从大到小排序排在最前面的基本就是要特别关注的 volume。如果你的环境里没有jq用 Python 同样可以实现curl -s http://master:9333/vol/status?formatjson | python3 -c import sys, json data json.load(sys.stdin) vols data.get(Volumes) or data.get(volumes) or [] for v in vols: deleted v.get(DeletedBytes, 0) if deleted and deleted 0: print(v.get(Id), v.get(Size), v.get(DataSize), v.get(FileCount), deleted) 需要提醒一句当集群里的 volume 数量很多时这个接口返回的 JSON 会很大哪怕只是正则过滤也可能吃几十 MB 内存建议用流式解析或加上筛选条件不要无脑全量拖到浏览器里看。2.4 辅助手段weed shell里的快捷命令如果你手边有weed shell进入交互终端后可以敲volume.list查看所有 volume 的基本信息输入volume.disk能直观看到各 volume server 的磁盘使用情况。相比直接请求 HTTP 接口weed shell的好处是它会自动处理 master 连接和部分格式转换适合不想写脚本的场景。当然内部拿到的数据源仍然是 master 的 volume 状态信息所以它给出的Size、DataSize这些字段都是同一口径。2.5 顺手把指标接到 prometheus 的思路如果你已经在用 Prometheus 监控 SeaweedFS会发现 volume server 和 master 都开了/metrics端点。拉到指标里可以画出每个 volume server 的磁盘水位趋势曲线。曲线的好处是能发现“逻辑删除但物理没回收”的渐进过程如果DeletedBytes持续上涨而业务删文件的量并没有那么大就要检查是不是有应用在批量覆盖写或者临时文件反复创建删除。这种趋势问题只看一次快照很容易漏掉。3. 到 volume server 本地确认物理真相du与ls的差值就是空洞3.1 用两个命令快速判断 volume 文件有没有“虚胖”如果说 master 接口告诉我们的是“应该有多少”那本地文件系统告诉我们的是“实际占了多少”。二者一旦对不上问题就在文件空洞上。先看单卷文件ls -l /data/volumes/25.dat du -h /data/volumes/25.datls -l显示的 Size 是文件的逻辑长度du -h显示的是文件实际占用的磁盘块大小。对 SeaweedFS 的数据文件来说如果曾经写入大量数据后又做了很多删除.dat文件会在中间留下大量空洞文件系统不会自动回收这些已经被“挖掉”的块于是ls的结果可能远大于du。反过来如果一个刚创建不久还没写满的 volume 文件du和ls的差距也可能存在因为文件系统按块分配尾部有未写满的块。但只要差距比例明显异常就说明空洞率不低。批量检查整个数据目录更常用cd /data/volumes for f in *.dat; do ls_size$(stat -c %s $f) du_blocks$(stat -c %b $f) blk_size$(stat -c %B $f) echo $f ls$ls_size du$((du_blocks * blk_size)) done这个循环会把每个 volume 文件的逻辑大小和物理占用按字节打出来差值大的文件后面往往跟着高DeletedBytes基本可以锁定 target。实际生产环境中我见过一个 2 GiB 的.dat文件du之后只有 800 MiB空洞率超过 50%这就是批量删除后一直没做 vacuum 的典型结果。3.2 分清数据目录里还有哪些东西找一个 volume server 的数据目录用ls -lh看一下通常会有以下几种文件total 47G -rw-r--r-- 1 root root 11G 5月 11 23:12 0.dat -rw-r--r-- 1 root root 231M 5月 11 23:12 0.idx -rw-r--r-- 1 root root 11G 5月 12 01:03 1.dat -rw-r--r-- 1 root root 230M 5月 12 01:03 1.idx占磁盘空间的大头永远是*.dat*.idx只是索引数据一般占数据量的几个百分点但如果文件数量非常多索引的体积也会明显膨胀。个别版本或开启 WAL 后还会出现日志文件这类日志大小相对可控不过排查磁盘占用时也不能完全无视。专门的 “查看 volume 磁盘占用” 场景下先盯住所有.dat文件总和就够了因为它决定了磁盘使用量的绝大部分。3.3 空间分布不均时怎么快速定位热点目录数据目录可能不是一块盘volume server 支持配置多个目录。配置多目录后du -sh每个目录对比能找到哪个盘已经告急、哪个盘还很空。如果你不想一层层du直接从/vol/status拿到每个 volume 所在的 server 和磁盘位置也会更快但 master 接口不一定直接给出目录路径所以最终还是得回到本地确认。如果数据目录的文件数量非常多直接du -sh /data/volumes可能等得人着急。这时候我一般会先看df -h确定整体水位再按du -h --max-depth1分批看尽量减小一次扫描的范围。另外记得用ionice或nice降低 du 对线上读写的影响尤其在高负载集群上这也是一个容易被忽略的细节。4. 数据膨胀的典型根因与排查链路4.1 根源在追加写和删除标记机制先说一个反直觉的事实在 SeaweedFS 里删除一批文件volume 占用的磁盘空间通常不会马上下降。原因是数据写入.dat文件时是追加写删除动作只是把索引条目标记为 deleted数据本身还在文件里相当于在文件里挖了一个或几个“坑”。这样的设计保证了写入性能的高效和简单但也把空间回收的动作延后到了 compact / vacuum 阶段。这个机制和很多传统文件系统删除后立即释放空间的经验不一样所以新手最容易在这里踩坑。你从 Filer 挂载目录里把文件删掉df上却看不出什么变化这不是删除失败而是回收时机还没到。4.2 一次批量删除后磁盘不降反升的完整排查过程我之前处理过一个实际案例场景是业务侧做了一轮历史数据清理预计删掉约 700 GB 的数据清理完成以后却发现集群某台 volume server 的磁盘水位不降甚至在 vacuum 之前还略有上升。排查步骤如下第一步先看整体视图。登录 master拉取/vol/status?formatjson把DataSize和Size各求一个总和发现Size总量和清理前的数据总量差不多而DeletedBytes总量突然涨了一截这说明删除确实执行了但只是逻辑删除。第二步定位具体 volume。用上面那个按DeletedBytes排序的脚本找到删除字节数最大的几个 volume。同时去对应 volume server 本地执行ls -l和du -h对比果然那几个 volume 的.dat文件逻辑大小没有缩小用stat算出的实际块占用也没变。第三步和业务侧确认。查了清理任务的日志发现业务方通过 Filer 的 Delete API 删除了对象符合预期问题不在业务代码而是维护流程里没有把“删除后的 vacuum” 纳入例行操作。第四步在低峰期执行 vacuum。等到凌晨访问量很低的时候对这几个膨胀 volume 所在集群做了一次 vacuum操作完成后DeletedBytes明显下降Size总和也随之缩水磁盘水位真正降下来了。这个过程里最值得注意的教训是只看 Filer 的目录结构或业务成功日志容易产生“数据已经清理完”的假象只有把 master 的逻辑统计和本地的物理统计对上才能确认空间是否真正释放。4.3 其他容易造成误判的几种情况除了删除不回收还有几个情况容易让磁盘占用看起来“不合常理”复制副本数。同一个 volume 会在多台 volume server 上各有一份数据文件/vol/status返回的每条记录是按 volume 实例来的统计时如果忘乘以副本数会把总占用低估一到两倍具体取决于副本配置。collection 的隔离效果。不同 collection 的数据集中在各自的 volume 编号段里统计时如果不按 collection 分组很难看出哪一个业务在快速吃空间。临时 compact 文件。vacuum 或 compact 过程中volume server 会生成临时文件如果进程被中断或临时文件没清理干净磁盘占用会残留一份不大不小的副本。遇到磁盘占用异常时可以在数据目录里扫一下临时文件开头或结尾命名的文件。5. 空间回收实操vacuum 与 volume 均衡5.1 三种触发 vacuum 的方式SeaweedFS 的 vacuum 机制简单说就是 master 找出垃圾比例达到阈值的 volume通知 volume server 把有效数据重写到一个新文件完成后再用新文件替换旧文件这样空洞就被压缩掉了磁盘空间才能归还给文件系统。这个动作官方文档里叫 compact vacuum本质是同一套流程。常用的触发方式有三种第一种HTTP 接口触发curl -X POST http://master:9333/vol/vacuum?garbageThreshold0.3第二种weed shell会话内执行weed shell volume.vacuum -garbageThreshold 0.3第三种老版本提供独立命令行工具weed vacuum -garbageThreshold 0.3新版本我更推荐weed shell的方式因为它会输出详细日志还能看到 master 对每个 volume 的筛选结果。garbageThreshold默认是 0.3意思是垃圾比例超过 30% 才会对这个 volume 做 compact。如果遇到磁盘告急想激进回收可以临时调低比如 0.1但不建议一直设置很低的值否则每次小规模删除都会触发全量 compactIO 放大很严重。5.2 vacuum 过程中发生了什么执行 vacuum 时master 会先遍历所有 volume选出满足垃圾比例的候选然后并行向这些 volume 所在的 volume server 发送 compact 请求。volume server 收到请求后会把该 volume 中仍有效的文件片段读出来写入一个新的临时数据文件同时重建索引。这个过程中有几个实际影响单个 volume 在 vacuum 期间需要额外的临时磁盘空间存放新文件如果磁盘已经接近写满执行 vacuum 可能因空间不足而失败。compact 期间该 volume 的读写会有短暂锁定对在线业务一般影响不大但如果集群容量很小、请求并发很高还是能感知到延迟波动。操作完成后旧的.dat文件被删除新文件生效master 上的Size字段会明显下降。我通常会在 vacuum 前后各拉一次状态做对比确认回收效果。5.3 执行前后的对比验证以我常用的流程为例。vacuum 前先抓一下关键值curl -s http://master:9333/vol/status?formatjson | jq [.Volumes[].Size] | add curl -s http://master:9333/vol/status?formatjson | jq [.Volumes[].DataSize] | add跑到磁盘水位告急的那台 volume server再记录du -sh /data/volumes执行完 vacuum 后重复同样的命令。如果一切正常Size总和会明显下降DataSize总和基本不变或略有下降本地du也会释放出一块空间。如果你的DataSize总和也出现明显变化先看看是不是有业务在删除数据或者有 compaction 之外的临时文件没清理。5.4 空间分布不均时用 volume 迁移均衡有时候磁盘占用大不是因为总量超了而是集中在少数几台机器上。此时单纯 vacuum 只能解决空洞问题解决不了分布问题。可以通过weed shell里的volume.balance或手动把某个 volume 迁移到空闲节点。均衡操作要谨慎评估第一步还是先看分布volume.disk如果某台 server 的已用空间明显高于其他节点且还有大量空闲 volume 可以写入可以利用 balance 命令把一部分 volume 迁移过去。迁移是复制数据再切换的过程会占用一定的网络带宽和临时空间建议结合业务低峰期进行。有时候手动指定迁移比全量 balance 更可控特别是你已经定位到某个 collection 的 volume 集中在一台机器上时。6. 顺着这个需求延伸出的巡检与维护建议6.1 一条 cron 就能防住大部分“虚胖”问题做完整套排查之后我把这台集群的巡检固化成了一个定时任务频率不高每 10 分钟跑一次只拉关键字段并把DeletedBytes高、Size与DataSize比值大的 volume 打印出来。一旦比值连续多次超过阈值就说明删除后没有及时回收有必要安排 vacuum 或检查业务删除模式。一个可以快速上手的 cron 脚本片段#!/bin/bash MASTERhttp://127.0.0.1:9333 ALERT60 curl -s $MASTER/vol/status?formatjson | jq -r .Volumes[] | select((.Size 0) and ((.Size - .DataSize) * 100 / .Size) 60) | [.Id, .Size, .DataSize, .DeletedBytes] | tsv | while read -r id size datasize deleted; do echo volume $id 空洞/删除占比过高: size$size data$datasize deleted$deleted done阈值按你的业务场景调。默认 60% 算比较宽松如果集群本来就经常删除可以放宽到 75% 再告警避免告警风暴。6.2 vacuum 节奏和触发时机的经验vacuum 不是越频繁越好。频繁 compact 会带来明显的读写放大尤其在大容量 HDD 上一次全量 vacuum 可能要跑几十分钟甚至更久。建议节奏是这样日常删除量小每周固定一次低峰 vacuumgarbageThreshold保持默认。批量清理任务后次日低峰做一次定向 vacuum把该 collection 或相关 volume 的垃圾尽快回收。磁盘水位告急临时调低阈值立即处理但处理完恢复默认并检查是否有删除流程异常。还有一个细节compact 过程中生成的临时文件在异常中断时可能会残留如果发现 vacuum 结束后磁盘空间没有完全恢复建议去数据目录扫一下临时文件并手动清理。这是我在一次虚拟机意外断电后踩过的坑后来在维护文档里专门加了这条备注。6.3 最后一个小技巧别只看峰值要看垃圾回收趋势排查磁盘占用如果只看某一天的快照很可能会忽略“这个 volume 是不是每天都在膨胀”的事实。我建议至少把下面三个指标纳入日常观察曲线所有 volume 的DataSize总和代表集群的真正有效数据。所有 volume 的Size总和代表数据文件占用的逻辑大小。各 volume server 数据目录的du总和代表实际物理占用。当三条曲线的间距拉大时基本就是删除后回收不及时的信号。反之如果Size和du曲线趋势正常只是DataSize在涨说明是正常写入增长不需要特殊处理。SeaweedFS 的 volume 磁盘占用这个问题其实只要把“逻辑数据量、文件空洞、物理块”这三个概念分清楚再配上 master 接口和本地du两把尺子日常维护就不会再有什么糊涂账。从我做这套集群的经验来看大部分“磁盘莫名其妙没了”的疑问最后的答案都在聚合删除未回收和副本数统计错误这两个坑里。希望这篇能帮你少走几步弯路。