本质是可用空间被小文件、隐藏系统文件或滞留日志蚕食；需先定位隐形占用源（如vss快照、hiberfil.sys、更新残留、inode耗尽、s2d碎片等），再针对性清理或调优。
存储空间被碎片文件或隐藏日志“撑爆”，本质不是容量真不够，而是可用空间被大量小文件、不可见系统文件或长期滞留的日志持续蚕食。这类问题在Windows服务器、数据库主机、容器节点和开发工作站上尤为典型——磁盘显示已用95%，但找不到几个大文件。排查需分两步走：先定位“隐形占用源”，再针对性清理或调优。
查隐藏日志与系统级占用（尤其Windows）
很多日志根本不在资源管理器中显示，比如：
-
卷影副本（VSS）：执行
vssadmin list shadows查看是否堆积大量旧快照；用vssadmin delete shadows /all /quiet清理（管理员权限） -
休眠文件 hiberfil.sys：大小=物理内存，隐藏且受保护；运行
powercfg -h off关闭后重启即可释放 - 页面文件 pagefile.sys：默认在C盘，可能达数GB；可移至其他盘或设为“系统管理的大小”后重启生效
- Windows更新残留：在磁盘清理中勾选“Windows更新清理”“以前的Windows安装”，常释放5–20GB
查碎片化小文件与Inode耗尽（Linux/容器环境）
当磁盘使用率100%但du -sh /*加总远小于df -h显示值，大概率是Inode用尽或大量零散小文件：
- 运行
df -i看IUse%是否达100%；若是，说明有成千上万个日志、缓存、临时文件（如/var/log/journal/、/tmp/systemd-private-*） - 用
find /var/log -name "*.log" -mtime +30 -delete清理老旧日志；对journal日志，执行journalctl --vacuum-time=7d - Docker环境重点查
/var/lib/docker/overlay2和/var/lib/docker/volumes；运行docker system df -v查体积分布，再用docker system prune -a --volumes清理无主数据
查存储池与S2D中的碎片与配置偏差
若使用存储空间直通（S2D）或传统存储池，性能下降+空间异常往往源于底层碎片或配置失配：
- 运行
Get-StoragePool | Get-PhysicalDisk确认池内所有磁盘类型（HDD/SSD）、介质（HDD/SSD/NVMe）、固件版本是否一致；混用易导致写入放大与碎片加剧 - 检查虚拟磁盘复原类型：
Get-VirtualDisk | Select FriendlyName,ResiliencySettingName；奇偶校验型在小文件随机写场景下极易产生内部碎片，应改用镜像或简单类型 - 用
Get-StorageSubSystem | Get-StorageHealthReport查健康报告；若提示“FragmentationLevel: High”，需暂停IO后运行Optimize-Volume -DriveLetter X -Defrag（仅限NTFS卷）
验证真实可用空间，绕过UI误报
资源管理器的“可用空间”可能因元数据延迟、权限限制或VSS预留而失真：
- Windows下执行：
fsutil volume diskfree C:，看“Available Bytes”字段——这是内核级真实值 - Linux下对比
df -h与df -i，再用lsof +L1查已被删除但仍被进程占用的文件（常见于未轮转的守护进程日志） - 若发现某目录
du -sh很小但df显示占满，进入该目录执行ls -la | head -20，留意以点开头的隐藏目录（如.cache、.local/share/Trash）
