☰

服务器上缺少磁盘空间

tag-icon • tag-icon linux centos disk-usage xfs
服务器上缺少磁盘空间

我的一台服务器遇到了一个奇怪的问题。我的磁盘空间几乎丢失了一半。

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       271G  122G  149G  46% /
devtmpfs        3.8G     0  3.8G   0% /dev
tmpfs           3.8G  8.0K  3.8G   1% /dev/shm
tmpfs           3.8G  8.6M  3.8G   1% /run
tmpfs           3.8G     0  3.8G   0% /sys/fs/cgroup
/dev/sda1       497M  120M  378M  24% /boot
tmpfs           778M     0  778M   0% /run/user/600

另一方面，du 显示仅使用了 6GB：

du -hs /
6.0G    /

这是一台日志经常将磁盘填满至 100% 的服务器，因此我的第一反应是重新启动 rsyslog 守护进程，但这没有效果。我还尝试重新启动服务器，因此不可能是某些文件被删除但仍在某些进程中使用。我在看https://serverfault.com/questions/299839/linux-disk-space-missing有人建议重新fsck启动，但这没有帮助。在同一页面上，有人建议在其他安装点上查找文件，但没有。我正在寻找更多建议。

的输出fdisk：

fdisk -l /dev/sda

Disk /dev/sda: 299.5 GB, 299506860032 bytes, 584974336 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 65536 bytes / 65536 bytes
Disk label type: dos
Disk identifier: 0x000f1d8a

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     1026047      512000   83  Linux
/dev/sda2         1026048    17018879     7996416   82  Linux swap / Solaris
/dev/sda3        17018880   584974335   283977728   83  Linux

lsblk输出：

lsblk -f /dev/sda
NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
sda                                                      
├─sda1 xfs          78e8f824-1a2a-4c60-ab7b-6126a192932d /boot
├─sda2 swap         bdbe969d-c59d-4956-ae69-71e2825f93dc [SWAP]
└─sda3 xfs          a9c9da10-5e99-4a14-a207-490e3f676617 /


`xfs_quota -x -c 'free -h -b'` output:
Filesystem     Size   Used  Avail Use% Pathname
/dev/sda3    270.7G 127.1G 143.5G  47% /
/dev/sda1    496.5M 119.0M 377.5M  24% /boot
Filesystem     Size   Used  Avail Use% Pathname
/dev/sda3    270.7G 127.1G 143.5G  47% /
/dev/sda1    496.5M 119.0M 377.5M  24% /boot

xfs_quota -x -c 'quota -h'不返回任何内容。没有人设定任何配额。这是我们分支机构部署的数百台具有相同配置和分区布局的服务器中的一台，但只有这台存在这个问题。由于某些特定原因，它是唯一一个定期将磁盘填满至 100% 的磁盘。我们每隔一两周手动删除一些日志。

答案1

似乎有大量文件隐藏在boot、dev、run、sys挂载点目录之一下，由于挂载了其他文件系统，这些文件通常无法访问。尝试从您正在运行的系统访问它们：

mkdir /mnt/root
mount --bind / /mnt/root
du -hs /mnt/root/

如果du返回的值明显多于您报告的 6 GB 使用量，那么这几乎肯定是问题所在。使用它来识别丢失的文件隐藏的位置：

du -hs /mnt/root/{boot,dev,run,sys}

请记住，这/mnt/root实际上是您的根/文件系统，因此请务必小心对待删除或其他文件操作。在任何情况下，都不要尝试直接删除/mnt/root可能用作挂载点的任何目录。

答案2

找出 fs 上占用空间的最佳工具（但不是已删除但仍打开的文件）是ncdu.尝试ncdu -qx /诊断您的 rootfs。

由于您的问题在重新启动后仍然存在，因此您似乎不是“已删除但仍然打开的文件”的受害者。

答案3

在运行的系统上，您应该以 root 用户身份检查磁盘使用情况，以便能够访问所有文件和目录。

也许您的根文件系统已启用配额。查看xfs_quota -x -c 'free -hi' /

从 live cd (gparted、systemrescue) 启动并mount /dev/sda3 /mnt检查du -csh /mnt/* 和df -H.

然后卸载 /dev/sda3 并检查 /dev/sda3 上已卸载的 xfs 文件系统xfs_repair -n /dev/sda3。

读https://mankier.com/8/xfs_repair了解它执行哪些检查。

答案4

这是 100 台具有相同配置和分区的服务器中的 1 台

您能估计一下 fs 的实际使用情况吗？ 6GB 是不是太小了？

df获取信息statvfs()wich 报告来自超级块的空闲块的数量，因此“使用量”是计算值。

默认情况下，du还计算每个文件及其找到的目录使用的块。

因为 du < df 文件系统有

接下来考虑：

另外，由于某些特定原因，它是唯一一个定期将磁盘填充至 100% 的软件。我们每隔一两周手动删除一些日志。

如果删除打开的文件，带有文件名的目录条目就会消失，但索引节点仍然存在，并且当文件句柄关闭时，内核会删除索引节点并释放块。

正常运行时间较长的计算机可能有大量孤立的 inode，因此重新启动应该会有所帮助。

重新启动时 fsck 并没有帮助。

由于某些原因，此类孤立的 inode 可能不会被内核从错误、断电、以前的目录损坏中删除，因此重新启动并没有帮助。

我建议xfs_repair /dev/sda3最后一次手动检查已卸载的文件系统。

如果它没有帮助，可能文件系统已损坏，xfs_repair 无法正确更新 freemap。

大多数情况下你应该信任du。

接下来也检查一下。

du -h与之比较du -bh /。

查找稀疏文件：

find / -type f -printf "%S\t%p\n" | gawk '$1 < 1.0 {print}'

也许存在大量小于 fs 块大小的小文件。

xfs_info / | grep bsize
find / -type f -size -4096c | wc -l00

相关内容