“磁盘空间突然不足，先找最大的文件删掉”只在空间确实被可见文件占用、且文件确认可以清理时才成立。对日本服务器，建议先用 df -hT 看文件系统容量和挂载点，再用 df -i 查 inode；随后以 du 按挂载点定位目录，并检查日志是否持续增长。若 df 显示已满、du 却找不到相应文件，重点排查已删除但仍被进程打开的文件、挂载点差异或文件系统元数据，而不是继续盲目删除。

排查时应先记录 df 结果和告警时间，再比较一段时间后的变化，确认是容量持续增长、inode 耗尽，还是 I/O 延迟导致业务误报。以下命令适用于常见 Linux 系统；需要管理员权限的操作请使用 sudo，执行前先核实目标路径和业务影响。不同发行版的工具选项可能有差异，遇到不支持的参数时先查看 命令 --help，不要直接改用未经确认的清理命令。

先确认是哪个文件系统告急

df -hT
df -i

df -hT 展示各挂载文件系统的总量、已用空间、可用空间、使用率、文件系统类型和挂载点；df -i 展示 inode 使用情况。两者关注的是不同资源：

• 容量使用率接近满载、可用空间持续下降，说明文件数据或文件系统开销正在占用空间。
• inode 使用率接近满载，即使 df -hT 仍显示有容量，也可能无法创建新文件。常见原因是大量小文件，例如缓存、队列文件、会话文件或按请求拆分的日志。
• 只有某个挂载点告急时，应围绕该挂载点排查；不要只看根目录 /。例如 /var、应用数据目录可能单独挂载。
• 若告警页面显示满载，但当前 df 正常，先确认监控检查的是同一台主机、同一挂载点和同一容器环境，并检查告警是否存在延迟。

可以用 findmnt 核对挂载关系：

findmnt -T /
findmnt -T /var
findmnt -T /实际业务目录

将“实际业务目录”替换为真实路径。findmnt -T 用于确认指定路径落在哪个挂载点，避免把目录所在文件系统判断错。若命令不可用，可查看 df -hT /实际业务目录 的结果。

用 du 缩小范围，注意它和 df 统计口径不同

确认挂载点后，再逐层查看目录占用。以下示例以根文件系统为例，-x 表示不跨越其他文件系统，避免把单独挂载的目录混入统计：

sudo du -xhd1 / 2>/dev/null | sort -h

如果系统的 du 不支持 -h 或 -d 组合，可尝试 GNU 常见写法：

sudo du -x -h --max-depth=1 / 2>/dev/null | sort -h

然后对占用明显的目录继续下钻，例如：

sudo du -xhd1 /var 2>/dev/null | sort -h
sudo du -xhd1 /var/log 2>/dev/null | sort -h

命令可能因权限不足而漏报；输出中的 Permission denied 不能解释为目录没有文件。需要完整统计时使用管理员权限，并确认检查范围不会跨到其他挂载点。遍历大型文件系统也可能产生额外 I/O，繁忙业务环境应缩小到可疑目录，或在负载较低时执行。

df 与 du 不一致并不必然表示工具出错：

文件系统可能为自身管理保留空间，因此 df 的“可用”与普通用户实际可用空间也可能不同；不同文件系统的显示和保留策略并不完全相同。不要仅凭两种工具的数字不一致就调整保留参数。

分辨大文件增长和 inode 耗尽

找到可疑目录后，先看一级子目录，再定位近期变大的文件。下面是 GNU find 常见环境下的示例：

sudo find /var/log -xdev -type f -printf '%s %TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null \
  | sort -n | tail -30

输出中的第一个字段是字节数，末尾是路径。这里的 -xdev 用于限制在同一文件系统；如果实际日志不在 /var/log，将路径换成已确认的日志目录。此命令只列出信息，不会修改文件。部分精简系统的 find 不支持 -printf，可先用 find --help 或系统手册确认选项，不能直接套用。

判断文件是否正在异常增长，可隔一段合理时间重复同一条统计命令并比较结果，同时查看文件修改时间。单次看到一个大文件，不足以证明它就是故障原因：它可能是正常数据文件、已完成的归档，或者属于另一挂载点。应结合文件用途、所属服务、增长速度和业务日志判断。

若 df -i 显示 inode 接近耗尽，查看大量小文件所在目录时，可以按目录统计数量。下面的命令会遍历目标目录，可能对文件数量极多的路径产生较大负载，建议先从已缩小的范围开始：

sudo find /可疑目录 -xdev -type f 2>/dev/null | wc -l
sudo find /可疑目录 -xdev -type d 2>/dev/null | wc -l

目录项数量只能帮助定位，不能单独代表 inode 使用量；硬链接、特殊文件和文件系统实现都会影响统计关系。优先找出产生小文件的服务或任务，并核对其保留策略。不要用“批量删除所有小文件”作为处理方式，缓存或队列目录中的文件可能仍被业务进程使用。

日志增长：找来源，不要先删正在写入的文件

日志突然变大，通常需要同时确认“哪个文件在增长”和“哪个进程在写”。先查看日志目录占用和大文件，再结合服务日志、应用配置及日志轮转规则确定来源。若系统使用 systemd-journald，可查看日志占用：

sudo journalctl --disk-usage

这条命令仅查询占用。若占用主要来自系统日志，需要进一步检查日志保留设置和近期错误是否重复产生；若主要来自应用日志，则应核对应用的日志级别、异常重试、请求记录量和轮转配置。不要未经验证就修改全局日志级别，过度降低日志会削弱故障诊断能力。

检查日志轮转配置时，先确认配置文件对应哪个服务、轮转周期、保留数量、压缩规则，以及服务是否需要重新打开日志文件。不同系统和应用配置路径可能不同，可先检查工具是否安装及其配置：

command -v logrotate
sudo logrotate --version

具体配置路径应以当前系统和服务实际使用的配置为准。不要为了立即腾空间就对仍在写入的日志执行 rm：进程可能继续向已删除文件对应的文件描述符写入，du 看不到它，但 df 仍会计算其占用。直接截断日志也会丢失排障证据，并可能影响正在写入的服务。

当文件系统已满且必须释放空间时，先确认日志内容不涉及仍需保留的审计或故障证据，评估服务影响并留存必要副本；再按该服务支持的方式轮转或让进程重新打开日志。任何清理都应限定到已确认的文件，不要对通配路径执行删除或截断。操作后检查 df -hT 是否恢复、服务是否仍能写日志，并确认后续增长速度是否回归正常。

df 已满而 du 找不到：查已删除但仍打开的文件

Linux 中，文件名被删除后，只要仍有进程持有该文件，数据占用就可能继续保留。可用 lsof 检查已删除但仍打开的文件：

sudo lsof +L1

如果没有安装 lsof，先按当前发行版的软件管理方式确认是否可用；不要仅为执行一次查询就盲目安装或运行来源不明的工具。输出中重点核对文件大小、进程名称、进程号和文件路径，并确认该文件所在的文件系统与告警挂载点一致。某些容器或受限运行环境中，当前命令看到的进程范围可能不完整。

确认占用确由该进程持有后，处理方式通常是让对应服务通过受支持的方式重新打开文件，或在评估影响后按维护流程重启相关服务。不能只根据进程名称就终止进程，也不应随意关闭文件描述符：这可能中断请求、任务或数据写入。操作前确认服务负责人、业务影响和恢复方式；执行后重新检查 df -hT，并验证服务功能和日志写入正常。

I/O 延迟或文件系统异常也要纳入判断

“磁盘空间不足”有时是业务侧对写入失败的概括，并不一定意味着容量真的用尽。若 df -hT、df -i 均有余量，但应用仍报告写入慢、超时或失败，应继续检查 I/O 等待和内核记录。

系统安装了 iostat 时，可查看设备利用和延迟指标：

iostat -xz 1 3

该命令连续采样设备状态；具体字段含义会受工具版本和设备类型影响。持续偏高的等待时间或设备繁忙程度，提示需要进一步核对当时的业务负载、读写模式及系统日志，但不能仅凭某一项指标断定磁盘故障。若没有 iostat，可先检查工具是否存在，不要把其他系统的安装命令直接照搬。

也可查看内存与 I/O 等待概况：

vmstat 1 5

重点观察采样期间的 I/O 等待和系统负载，并与业务异常时间对照。短时间的高值可能由备份、批处理、集中写入等任务造成；判断是否异常，应结合持续时间、应用响应和设备监控，不要用单次采样下结论。

检查内核近期记录：

sudo dmesg -T | tail -100

若出现文件系统错误、设备 I/O 错误或被切换为只读等记录，应停止高风险写入和清理操作，先保存相关日志并核实文件系统类型、挂载状态和系统维护流程。不要在文件系统仍挂载且业务运行时自行运行修复工具；修复方式取决于文件系统类型和运行状态，错误操作可能造成数据损坏。遇到只读挂载或重复 I/O 错误，应由具备相应权限的维护人员评估离线检查、备份与恢复方案。

判断结果后再处理，并复核是否真正解决

排查结果可按以下方式分流：

1. 容量确实被可见文件占满：确定文件归属和保留要求，优先通过应用自身的轮转、归档或清理机制处理；完成后复查对应挂载点。
2. inode 接近耗尽：定位大量小文件的目录和生产进程，核对队列、缓存或临时文件的生命周期；先确认文件不再被使用，再按应用规则清理。
3. df 明显高于 du：检查已删除但仍打开的文件、权限盲区、挂载点和运行环境差异，不要重复清理可见目录。
4. 容量与 inode 都正常，但写入异常：对照 I/O 采样、内核日志和业务时间点，确认是否为延迟、只读状态或其他写入错误。
5. 处理后数字下降但很快再次升高：说明释放空间没有消除增长源，应继续追踪持续写入的进程、日志配置或任务。

处理完成后，至少复核 df -hT、df -i 和相关目录 du；确认业务可以正常写入，并观察一段时间内占用是否稳定。若只释放了空间却没有调整持续增长的来源，告警很可能再次出现。反过来，若 df 已有余量、应用也恢复正常，而目录统计暂时不一致，应先确认统计范围和打开文件状态，不必为了让两组数字完全相等而进行高风险操作。