我纯粹是出于好奇才问这个问题。
在系统分区上创建无数的空文件是否会彻底导致操作系统陷入瘫痪？
理论上它们的大小为 0 字节，但实际上它们有助于文件系统的元数据，因为它们具有名称、修改时间等。
我曾经创建了大约 6500 个 1MB 大小的文件，以测试rsync处理大量小文件时的速度是否比处理几个大文件时慢得多。我注意到，每当我访问包含所有文件的目录时，文件管理器都会冻结很长时间，试图列出所有文件。删除它们也花了很长时间。
我想知道这是否可以用于发起网络攻击，以及是否可以防御它。
我做了一个小测试，用 创建了 100 000 个空文件touch。这花了 3 分 10 秒，并创建了一个据说大小为 2.1 兆字节的目录。之后我的文件管理器 Dolphin 就冻结了。
删除整个目录rm -rf仅需 1 秒。
我想知道这是否会扩大到导致操作系统无法使用？
我正在运行带有 EXT4 文件系统的 GNU/Linux（Linux Mint），但我想知道不同的操作系统和文件系统如何处理这个问题。
答案1
实际上，不存在“0 字节长的文件”。一个文件至少占用一个 inode。inode 的大小是固定的，更重要的是，它们的数量是有限的。如果文件系统的 inode 已满，则文件系统已满，即使它仍报告一些（甚至很多）可用空间。
然而，出于多种原因，上述行为对系统的影响微乎其微。请注意，我们这里讨论的是普通用户——如果某个拥有 root 权限的陌生人可以写入您的文件系统，那么您就完蛋了。
用户无法填满文件系统（或者更确切地说：他们不应该这样做），因为每个文件系统都是这样创建的：如果文件系统已满到一定程度，它将向所有非 root 用户报告其已满。系统为 root 用户保留的磁盘空间大小是在创建文件系统时选择的（对于 ext2-4，默认值为 5%）。理论上，用户可以将文件系统填满到 95%，然后等待 root 进程（例如 syslog）用完剩余空间，但通常也不会发生这种情况，因为用户只能使用自己的磁盘空间（或者至少应该如此），因此通过创建过多的文件，他们可以填满分区，/home这可能会造成麻烦，但根本不会对系统造成任何影响。
服务器上的文件系统通常与其他一切一起受到监控。文件系统以可疑的速度耗尽可用空间肯定会引起注意，问题将立即得到调查。
只有当某些程序试图读取所有文件时，许多文件的存在才会成为问题，几乎所有 GUI 程序和一些基于文本的工具（例如 mc）都是这样。简单地从 shell 进入目录通常不会很慢，因为那时不会读取文件。因此，处理这种情况通常很简单，尽管有点不舒服。
答案2
正如您自己所说，即使是空文件也会消耗一些元数据，因此原则上，通过创建太多空文件，可能会使文件系统无法使用（细节取决于文件系统，通常您至少无法向其中写入更多数据，但即使删除文件也可能会成为问题（请参阅 btrfs），在空间耗尽之前性能可能会下降等等）。应该可以删除文件并回收使用的空间（同样，细节取决于文件系统）并恢复性能。这种攻击可能会扰乱底层驱动器 - 如果分区位于 SSD 上并且与 SSD 一样大，则应该可以通过使用每个空块来降低性能（由于 Nand Flash 的工作方式，这可能在驱动器已满之前很久发生（驱动器上的页面被分组为更大的块，只有当整个块为空时才有可能直接写入页面，否则该块将被读取、修改并再次写入.. 您可能明白为什么这会降低性能））理论上，您也可以引起足够多的写入来真正杀死驱动器，但这种情况极不可能发生，因为即使是 2d tlc 闪存也比大多数人想象的要耐用得多（https://techreport.com/review/26523/the-ssd-endurance-experiment-casualties-on-the-way-to-a-petabyte）。
Lacek 还正确地指出，如果系统配置正确，普通用户不应该使用任何对系统正常运行很重要的分区上的所有空间，因此他们可能引起的问题应该是有限的。