☰

谁在填满我的磁盘？

tag-icon • tag-icon disk-usage
谁在填满我的磁盘？

我的主磁盘已经完全填满：

root@kodi:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           385M   12M  374M   3% /run
/dev/sda1        88G   84G     0 100% /
tmpfs           1.9G  4.0K  1.9G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sdb1       917G  429G  442G  50% /media/Cloud
/dev/sdd1       917G  813G   58G  94% /media/Tera
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           385M     0  385M   0% /run/user/1000
root@kodi:/#

/dev/sda1 是我安装 ubuntu 的主磁盘：

root@kodi:/home/fmf# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=9fab4895-7ccb-4415-b26d-311a17036cda       /               ext4    errors=remount-ro 0       1

# swap was on /dev/sda5 during installation
UUID=7b158f58-e4c1-4717-aa5f-dbeaa79ab93c       none            swap    sw              0       0

UUID=f9079f52-7661-48ad-9bc4-0d2452be66af       /media/Tera     ext2    defaults,nofail 0       0
UUID=fb1f92ee-54f5-44f8-ba92-544e90e6dfeb       /media/Cloud    ext2    defaults,nofail 0       0

root@kodi:/home/fmf#

进行了一些谷歌搜索，并找到了一些命令来测试谁是负责人，但我不知道谁在填写它：

root@kodi:/# du --exclude=/media -cksh * | sort -hr | head -n 15
du: cannot access 'proc/16360/task/16360/fd/3': No such file or directory
du: cannot access 'proc/16360/task/16360/fdinfo/3': No such file or directory
du: cannot access 'proc/16360/fd/3': No such file or directory
du: cannot access 'proc/16360/fdinfo/3': No such file or directory
1.3T    total
1.3T    media
3.5G    home
3.0G    usr
1010M   var
645M    root
630M    lib
99M     boot
17M     bin
15M     sbin
13M     etc
12M     run
196K    tmp
16K     lost+found
12K     srv
root@kodi:/#

显然没有任何文件或目录如此之大以填满我的 84G 磁盘。

几天前，我发现磁盘已满，因为 .xsession-errors 疯狂地出现。我发现这是 ubuntu 中的一个已知错误，我通过创建 crontab 行解决了这个问题，该行每十分钟删除一次 .xsession-errors。事实上，现在我的主目录中不再有它了。

请问有什么帮助吗？

答案1

您的 cronjob 的问题在于它.xsession_errors很可能仍由某些应用程序或系统服务打开，这就是为什么它在删除时会从文件系统表中隐藏，但它仍在磁盘上，并且仍然会将错误写入其中。
因此它会填满磁盘，但现在您再也看不到它了。

@rinzwind 的目标正是这种行为，他（正确地）建议删除 cronjob 并查找错误。这是正确修复此问题的唯一方法。

作为一种解决方法，你可以.xsession_errors使用这样的 cronjob 截断文件：

17 */2 * * *  truncate -cs 0 path/to/.xsession_errors

但在执行此操作之前，你真的应该尝试修复导致这些错误消息的根本问题.xsession_errors

答案2

谁在填满我的磁盘？

因为你这样做了……

我发现这是 ubuntu 中的一个已知错误，我解决了这个问题，创建了一条 crontab 行，每十分钟删除一次 .xsession-errors

这个问题无法回答。

请按照以下步骤获取我们需要看到的错误：

  • 删除您添加的删除 crontab 行.xsessions_errors。
  • .xsessions_errors重新启动，然后从命令行检查使用的内容tail -f 100 ~/.xsessions_errors。
  • 当您发现任何重复出现的问题时，请将其中一些问题复制到您的问题中。
  • 添加 crontab 行以便您可以使用您的系统。
  • 等待问题修复并应用。然后再次删除 crontab 行（.xsessions_errors应始终避免删除该文件）。

答案3

当 (以 root 身份)df -g /some/partition_root和du -gx /some/partition_root(-x告诉 du 将自身限制在同一个分区，例如检查 '/' 很有用) 之间存在很大差异时：可能仍存在一些打开的文件，某些进程仍在写入，但您在磁盘上删除了它们（因此：只要文件被进程打开，它就仍然存在，并填满磁盘空间（df -g 会看到它），但由于其 inode 不再有链接（或文件名），du -gx 会错过它们。

根据您的情况，比较一下输出：

df -g /
du -gx /

找出链接数少于 1 个的文件（即已删除但仍打开的文件）：

lsof -nP +L1  /

检查进程名称和 pid 以查看哪些进程正在写入这些“幽灵”文件，并采取相应的措施（您可能能够停止/启动某些进程，当它们停止时，文件将被释放并且其空间将被释放，其他进程可能需要适当的重新启动）

相关内容