too many open files、超级的坏块

文件系统上有超级的坏块

xfs_repair /dev/sdb1 -L
#检查和修复 XFS 文件系统
#-L 选项是为了将任何损坏的文件或目录都移动到 lost+found 目录中。
#lost+found 目录是 XFS 文件系统用于存储修复过程中找到的损坏文件和目录的地方。

打开了太多的文件

sysctl -w fs.file-max=1000000
#/etc/security/limits.conf或/etc/sysctl.conf改变：
#fs.file-max = 1000000
#fs.file-max: 控制系统级别的文件描述符总数。

fs.nr_open: 控制单个进程可以打开的文件描述符的最大数量。
单个进程的文件描述符限制可以通过 ulimit 命令来设置。
/proc/sys/fs/nr_open 是一个系统级别的全局参数，表示系统中单个进程能够打开的文件描述符总数的限制。
/proc/sys/fs/file-max 系统级别，当前系统可打开的最大数量
/etc/security/limits.conf 用户级别，指定用户可以打开的最大数量

• soft nofile 65535
• hard nofile 65535
  这两个值都需要小于/proc/sys/fs/nr_open设置的值
  在许多 Linux 内核中，默认值可能是 1048576（2^20）
  关于 nr_open 的最大值，它是在 32 位系统上是 2^32 - 1，即 4294967295；
  在 64 位系统上是 2^64 - 1，即 18446744073709551615。这是因为文件描述符的数量是一个无符号整数，其最大值取决于系统的架构。这个值通常是一个非常大的数字，足够满足绝大多数的应用场景。

在实际应用中，如果你遇到了文件描述符不足的问题，可能需要优化你的应用程序或系统配置，而不是直接调整这个值。提高文件描述符总数的上限是有风险的，因为它会占用更多的系统资源。

# 当你报错
### failed to create fsnotify watcher: too many open filesfailed to create fsnotify watcher: too many open files
```bash
vi /etc/sysctl.conf

fs.inotify.max_user_instances=819200
fs.inotify.max_queued_events=1638400
fs.inotify.max_user_watches=52428800
sysctl -p
改这些就是在改 /proc/sys/fs/inotify/max_user_watches 下对应的文件

fs.inotify.max_user_instances:
含义： 限制单个用户能够创建的 inotify 实例的数量。 默认值： 取决于内核版本，通常是 128。 为什么会影响问题：
如果此值太低，用户将无法创建足够的 inotify 实例来监视文件和目录，可能导致 too many open files
错误。通过将其增加到 819200，你提高了系统同时处理的 inotify 实例的数量，从而有助于避免相关的错误。

fs.inotify.max_queued_events:
含义： 限制 inotify 队列中待处理事件的数量。 默认值： 通常是 16384。 为什么会影响问题：
如果监视的事件发生得太快，队列可能会变满，导致后续事件丢失。通过增加此值，你扩大了系统处理事件的缓冲区，有助于防止队列溢出。

fs.inotify.max_user_watches:
含义： 限制单个用户能够为其监视的文件和目录设置的监视器（watches）的总数。 默认值： 通常是 8192。 为什么会影响问题：
如果监视的文件或目录数量太多，可能会达到默认的监视器数目上限，导致 too many open files 错误。通过将其增加到
52428800，你提高了单个用户可以设置的监视器的数量，从而有助于避免相关的错误。 总体来说，通过调整这些 inotify
参数，你扩大了系统处理文件系统事件的容量，从而减少了 too many open files
错误的可能性。需要注意的是，在调整这些参数时，要确保系统资源足够，以及对应的硬件和内核版本支持所需的数值。在生产环境中，调整这些参数之前最好进行适当的测试和评估。