块设备突然满了;无法确定单个文件是罪魁祸首,SMART 没有显示驱动器错误

块设备突然满了;无法确定单个文件是罪魁祸首,SMART 没有显示驱动器错误

设置

  • Ubuntu 20.04
  • 戴尔 PowerEdge R820
  • [PERC H710] 2 个虚拟驱动器(RAID-1 启动、RAID-0 工作驱动器)
  • 六个月来一切都很好
  • 没有任何先例,只是突然间,车子就开满了。

细节...

这台机器用于绘制 Chia(加密货币)——它已经连续运行了几个月,没有出现问题。

我注意到绘图过程崩溃了(bladebit)——这种情况很少见,大概每 2 个月发生一次——所以我重新启动它,结果立即开始出现device full各种错误。

我快速df -h查看了一下发生了什么,得到了以下信息:

Filesystem          Size  Used Avail Use% Mounted on
udev                252G     0  252G   0% /dev
tmpfs                51G  2.9M   51G   1% /run
/dev/sda2           549G  512G  8.7G  99% /
tmpfs               252G  4.0K  252G   1% /dev/shm
tmpfs               5.0M     0  5.0M   0% /run/lock
tmpfs               252G     0  252G   0% /sys/fs/cgroup
/dev/sda1           511M  5.3M  506M   2% /boot/efi
tmpfs                51G     0   51G   0% /run/user/1000
<... SNIP ...>

/dev/sda2是启动驱动器 - 它实际上是由服务器中的 H710 RAID 卡处理的 RAID-1(2 磁盘)虚拟磁盘,但我认为这并不是太相关。

通常情况下该驱动器已满 3%,它只安装了可启动的 Ubuntu Server 20.04,没有其他任何东西。

我不得不删除根目录中的 tmp 文件和其他一些垃圾文件,以释放足够的空间让一切再次运行,但它已经快满了。

我遵循了无数来自这里和网络上的“找到服务器上最大的文件”的提示,例如这个,命令sudo du -a / 2>/dev/null | sort -n -r | head -n 20返回:

$ sudo du -a / 2>/dev/null | sort -n -r | head -n 20
[sudo] password for user: 
1010830919685   /
1010823681740   /mnt
<...SNIP...>

好吧,那么显然有什么大人物坐在那里/?一个简单的例子ls显示那里没有什么有趣的东西:

$ ls -lFa /
total 84
drwxr-xr-x   20 root root  4096 Jan 12 17:45 ./
drwxr-xr-x   20 root root  4096 Jan 12 17:45 ../
lrwxrwxrwx    1 root root     7 Aug 24 08:41 bin -> usr/bin/
drwxr-xr-x    4 root root  4096 Jan  6 06:22 boot/
drwxr-xr-x    2 root root  4096 Sep 28 14:04 cdrom/
drwxr-xr-x   21 root root  6920 Jan  5 16:05 dev/
drwxr-xr-x  105 root root  4096 Jan  5 01:54 etc/
drwxr-xr-x    3 root root  4096 Sep 28 14:18 home/
lrwxrwxrwx    1 root root     7 Aug 24 08:41 lib -> usr/lib/
lrwxrwxrwx    1 root root     9 Aug 24 08:41 lib32 -> usr/lib32/
lrwxrwxrwx    1 root root     9 Aug 24 08:41 lib64 -> usr/lib64/
lrwxrwxrwx    1 root root    10 Aug 24 08:41 libx32 -> usr/libx32/
drwx------    2 root root 16384 Sep 28 14:03 lost+found/
drwxr-xr-x    2 root root  4096 Aug 24 08:42 media/
-rw-r--r--    1 root root  6678 Jan  9 00:59 MegaSAS.log
drwxr-xr-x   64 root root  4096 Jan  5 01:48 mnt/
drwxr-xr-x    3 root root  4096 Nov 30 18:14 opt/
dr-xr-xr-x 1356 root root     0 Jan  3 04:40 proc/
drwx------    7 root root  4096 Nov 30 18:07 root/
drwxr-xr-x   34 root root  1100 Jan 12 08:04 run/
lrwxrwxrwx    1 root root     8 Aug 24 08:41 sbin -> usr/sbin/
drwxr-xr-x    9 root root  4096 Sep 28 22:06 snap/
drwxr-xr-x    2 root root  4096 Aug 24 08:42 srv/
dr-xr-xr-x   13 root root     0 Jan  3 04:40 sys/
drwxrwxrwt   13 root root  4096 Jan 12 17:15 tmp/
drwxr-xr-x   15 root root  4096 Aug 24 08:46 usr/
drwxr-xr-x   13 root root  4096 Aug 24 08:47 var/

使用sudo ncdu -x /关联) 奇怪的是,没有显示任何有趣的内容:

    2.4 GiB [##########] /usr                                                                                                                                                                                                                 
    1.5 GiB [######    ] /var
  732.5 MiB [##        ] /home
  202.8 MiB [          ] /boot
    5.5 MiB [          ] /opt
    5.4 MiB [          ] /etc
    1.9 MiB [          ] /root
  168.0 KiB [          ] /tmp
<...SNIP...>

这约 510GB 的已用空间位于哪里?

启动一个sudo lsof | grep deleted来查看是否有一些巨大的文件被保存,我得到了这个:

systemd-j    1134                               root   36u      REG                8,2 134217728    5246838 /var/log/journal/771d7f1addf64a7b930191976176149e/system@ae2f8b2397c441f7a286d25144be755f-0000000000315312-0005d4e51ab8f8e9.journal (deleted)
unattende    3932                               root    3w      REG                8,2       113    5246631 /var/log/unattended-upgrades/unattended-upgrades-shutdown.log.1 (deleted)
unattende    3932    3943 gmain                 root    3w      REG                8,2       113    5246631 /var/log/unattended-upgrades/unattended-upgrades-shutdown.log.1 (deleted)

好的,它保存着一个 134mb 的日志文件,但这仍然不能解释为什么突然有 510GB 的驱动器被占用。

我还尝试了一些其他搜索,例如这个,但也没有带来任何帮助。

我最终用于megacli检查 RAID-0 阵列中 2 个驱动器的 SMART 数据,它们报告了 0 个错误,因此看起来阵列没有损坏。

有什么想法或额外的挖掘技巧可以让我尝试弄清楚是什么占用了那个空间?

更新 #1- 我输入时注意到top,这buff/cache几乎与根驱动器上消耗的 GB 大小完全相同。我知道空间不算在内used,但我决定快速启动:

sudo sh -c "/usr/bin/echo 3 > /proc/sys/vm/drop_caches"

运行大约需要 3 分钟,但最终返回 -top现在显示buff/cache为 < 1k,但df -h磁盘使用情况没有变化。

我曾希望它是磁盘上的一个神秘缓存文件或类似的东西。

答案1

事实证明,一旦我将根目录重新绑定到子目录并执行

sudo du /tmp/fake-root/ | sort -n -r | head -20 

在上面,我立即发现了一些巨大的文件,这些文件被不应该在那里的支架“隐藏”了。

https://serverfault.com/questions/275206/disk-full-du-tells-different-how-to-further-investigate

相关内容