我遇到了以下问题：
df -h显示：
ubuntu@:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 32G 9.6G 21G 33% /
udev 819M 12K 819M 1% /dev
tmpfs 331M 200K 331M 1% /run
none 5.0M 0 5.0M 0% /run/lock
none 827M 0 827M 0% /run/shm
在这里我可以看到 32G 分区中有 21GB 可用/。
然而，当我尝试时，df -i我得到
ubuntu@:~$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda1 2097152 2096964 188 100% /
udev 209564 382 209182 1% /dev
tmpfs 211573 274 211299 1% /run
none 211573 4 211569 1% /run/lock
none 211573 1 211572 1% /run/shm
这里我看到使用率是 100%。我不确定为什么两者显示的使用率不同。
其次，这个/root文件夹对我来说看起来很奇怪：
ubuntu@:/$ ls -al
total 132240
drwxr-xr-x 24 root root 4096 Jan 8 15:04 .
drwxr-xr-x 24 root root 4096 Jan 8 15:04 ..
drwxr-xr-x 2 root root 4096 Mar 27 2013 bin
drwxr-xr-x 3 root root 4096 Mar 21 2013 boot
drwx------ 5 root root 135319552 Apr 1 14:11 root
drwxr-xr-x 18 root root 640 Apr 1 14:03 run
drwxr-xr-x 2 root root 4096 Mar 27 2013 sbin
为什么根目录这么大？如果我进入目录/root并在ls终端中输入，它甚至没有响应。所以我对此感到困惑。
任何建议都会有帮助。
谢谢。
答案1
对于您的第一个问题，df -h以人性化的形式报告文件系统磁盘空间使用情况。人性化是因为它以 kb、mb 或 gb 为单位报告大小，而不是单纯以字节为单位，而df -i报告的是 inode 信息而不是块使用情况。
索引节点通俗地说，就是有关文件的数据。文件系统中需要一些空间来存储有关文件的数据。因此，如果这个空间已满，即使您可能有空间，也无法在文件系统中存储文件，因为没有空间来存储有关要存储的文件的数据。
其次，你需要超级用户权限查看/root文件夹中存储的内容，所以我不太清楚你是如何进入该/root文件夹的。失败的原因ls是它没有读取权限来读取内容/root并向你报告。要查看为什么/root占用了太多空间，你需要超级用户权限来调查，除非你有超级用户权限，否则我不确定你是否能读取里面的内容。
文件夹的大小为 4096，因为这是存储其内容信息所需的最小大小。如果超过此大小，则意味着它有很多文件，而这些文件的信息需要那么多空间。
我建议您调查文件夹的内容，因为这似乎是显示 100% 利用率/root的原因。df -i
答案2
好吧，我弄清楚了问题所在，下面是解释：
我们有一些运行 PHP 脚本的 crob 作业正在运行，我们使用了wget -q。由于某种原因，这会以 php 脚本的名称创建一个日志文件/root，文件名只有 0 个字节。
关于文件是 *.php。不确定为什么会发生这种情况。但我们需要修复 cron 的运行方式。自从我昨天修复了这个问题以来，已经创建了几千个文件 :/
该 cron 作业每分钟运行大约 10 个脚本。这意味着每分钟有 10 行条目。因此，一年内它创建了：10 x 60 x 24 x 365 = 超过 520 万个文件。这导致目录大小异常大（130MB）/root
这也解释了为什么df -u显示有可用的“空间”，但没有更多节点可以自由地自己写入文件名。
然后find . -name '*.php*' | xargs rm -v我删除了所有 php 日志文件。花了将近 30 分钟，一切都很完美。磁盘使用率降至仅 9%！
/root是正常的，但是 130MB 目录大小保持不变。不确定这是否会改变。但目前这不是一个大问题。必须修复这个crontab问题，我们有一年的时间来修复它 :)