我注意到在 dmesg 和 syslog 中有类似这样的内容：
EXT4-fs warning (device sda3): ext4_dx_add_entry: Directory index full!
我也检查了 df -i：
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sda3 182943744 27534820 155408924 16% /
我看到 IUse% 是 16%。我重启了服务器，但又出现了这种情况。我检查了哪里的文件太多了，最大的一个文件夹里有 3200 个文件。是不是太多了？
我在 Google 上发现 - 我可以尝试 fsck，但是如何在挂载系统上执行此操作。我认为这是不可能的，否则可能会破坏我的数据。
你有想法吗？
非常感谢您的帮助。
拉法尔
答案1
我在 Google 上发现 - 我可以尝试 fsck，但是如何在挂载系统上执行此操作。我认为这是不可能的，否则可能会破坏我的数据。
是的，这是我推荐的。听起来你的文件系统可能损坏了。
fsck无法修复已安装的文件系统。您需要在文件系统安装运行之前启动并停止启动过程fsck（这可能或不可能，具体取决于您的配置）或从其他媒体（如安装程序光盘或 LiveCD）启动以检查和修复您的根文件系统。
答案2
我在 Google 上发现 - 我可以尝试 fsck，但是如何在挂载系统上执行此操作。我认为这是不可能的，否则可能会破坏我的数据。
有几种不同的选项，它们都需要重新启动。下面的选项 3 是我最喜欢的，因为它给了我最大的控制权，但这取决于你的控制台访问权限。
但首先，请阅读警告：
警告＃1：确保在运行 fsck 之前备份数据，有时 fsck 可能会使情况变得更糟！
警告 #2：如果这是在数据中心，并且您没有远程控制台访问权限（如 iDRAC、iLO、iKVM 等），那么请有人随时准备在控制台上提供帮助。有时在启动时强制执行 fsck 会在出现错误时提示用户输入并需要用户干预——而您不想被锁定！
如果它是根分区（并且就您的情况而言是这样的）那么 #1 或 #2 可能会起作用：
- 您可以尝试
touch /forcefsck重新启动 - 或者在 grub 中编辑内核命令行在启动时（或者如果没有控制台访问直接编辑 grub.cfg
fsck.mode=force），并可选地添加fsck.repair=yes并让 systemd-fsck 执行此操作。- 如果您直接编辑了 grub.cfg，请在完成后将其放回原处！
如果是不是根分区（或者如果上面的#1、#2 不起作用）那么您需要控制台访问：
- 启动到
init=/bin/sh模式并绕过一切：- 第一的在 grub 中编辑内核命令行在启动时添加
init=/bin/sh - 当它启动时它可能会启动到如下提示：
bash-4.2# - 您可能需要设置路径：
PATH=/sbin:/bin:/usr/sbin:/usr/bin - 然后您可以按如下方式测试 fsck：
fsck.ext4 -fn /dev/your/device - 如果错误数量看起来不太可怕，请运行修复：
fsck.extr -fy /dev/your/device
- 第一的在 grub 中编辑内核命令行在启动时添加
- 使用 Live CD这个答案