为什么Linux内核实际上不在智能节点上时报告“磁盘空间不足”

我的一个朋友喜欢在Linux环境中编程，但对Linux的管理了解不多，最近遇到了一个问题，即他的操作系统（Ubuntu）报告“ XXX卷上的磁盘空间不足”。但是当他去检查卷时，仍然还有700 GB的空间。经过大量的时间浪费之后，他最终能够确定自己没有使用inode。（他在此卷上存储了来自备份系统的许多小增量更新，并通过所有inode进行了刻录。）

他问我为什么Linux内核报告错误消息（“磁盘空间不足”）而不是正确报告（“索引节点不足”）。我不知道，所以我想问一下StackExchange。

有人知道为什么会这样吗？以及为什么这些年来没有得到解决？（我记得1995年有一位朋友告诉我这个问题。）

单个错误号ENOSPC用来报告这两种情况，因此是相同的错误消息。

为了保持与ISO C和POSIX标准的一致性，内核开发人员别无选择，只能对两个事件使用单个错误号。添加新的错误号将破坏现有程序。

但是，由于坚持使用传统错误消息并不是AFAIK的强制要求，因此，例如，例如 out of disk/inode space

从技术上讲，是用inode空间还是用数据空间都是相同的，即，这意味着没有足够的可用磁盘空间来使系统调用成功。

我想您不会抱怨在仍然有可用的inode插槽的情况下磁盘是否已满。

需要注意的是文件系统，如JFS，XFS，ZFS和btrfs分配inode动态这么做没有表现出这个问题了。

我假设您的朋友正在使用ext fs，因为它是少数可能用尽inode的明智fs之一。

看来您的朋友要么摆弄了他的文件系统，然后就破坏了它，要么是拥有几TB的可笑的大容量。索引节点不是一劳永逸的东西。如果他真的用尽了inode，则意味着他拥有许多文件和目录，这简直荒唐可笑……这可能发生在大于4TB（根据经验的猜测）的卷上，而“只有” 700GB是免费的。对于fs的ext系列，创建fs时将确定inode的数量。从mkfs.ext4手册页：

-i bytes-per-inode
          Specify  the  bytes/inode ratio.  mke2fs creates an inode for every bytes-per-inode
          bytes of space on the disk.  The larger the bytes-per-inode ratio, the fewer inodes
          will  be  created.  This value generally shouldn't be smaller than the blocksize of
          the filesystem, since in that case more inodes would be made than can ever be used.
          Be  warned  that  it is not possible to expand the number of inodes on a filesystem
          after it is created, so be careful deciding the correct value for this parameter.

为了简化此答案的其余部分：这意味着mkfs要么提供了这样的比率，要么将采用该比率。如果您的朋友使用fs的方式与假设的使用方式不同，那么所选的比率可能不适用于他的用例，而他得到了这个错误...用数吨的小文件填充单个多TB的卷可能会算作错误。

您的朋友是否使用某种桌面环境来实现文件的“垃圾桶”概念或可能创建大量文件的任何其他形式的备份？也许他可以通过摆脱不必要的文件来解决问题。

我记得大约在内核2.4还很新的时候ext2就出现了这个问题。根据经验，与当前常见卷相比，我始终将XFS用于非常大的卷。目前，我将单个卷称为250GB到1TB之间的所有公用空间，我们可以购买4TB HDD。因此，对于> 3TB的所有内容，我宁愿使用XFS而不是ext。只是一个经验法则，但是很长一段时间都没有用尽inode ...