谁在填充我的磁盘？

我的主磁盘已完全装满：

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。实际上，现在我的主目录中不再有它。

有什么帮助吗？

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

@rinzwind旨在（当正确地）建议删除cronjob并查找错误时针对此行为。这是正确解决此问题的唯一方法。

作为解决方法，您可以.xsession_errors使用cronjob 截断文件，如下所示：

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

但是在执行此操作之前，您确实应该尝试修复在这些错误消息中创建这些错误消息的潜在问题。 .xsession_errors

谁在填充我的磁盘？

因为你这样做

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

无法回答这个问题。

请按照以下说明获取我们需要查看的错误：

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

当（作为根用户）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，以查看哪些进程正在写入那些“ ghost”文件，并采取相应的措施（有些您可能能够停止/启动，而当它们停止时，文件将被释放并释放其空间，其他人可能需要正确重启）