实战篇-典型故障排查与性能问题诊断与优化

浪潮信息KOS是浪潮信息基于Linux Kernel、OpenAnolis等开源技术自主研发的一款服务器操作系统，支持x86、ARM等主流架构处理器，性能和稳定性居于行业领先地位，具备成熟的 CentOS 迁移和替换能力，可满足云计算、大数据、分布式存储、人工智能、边缘计算等应用场景需求。详细介绍见官网链接https://www.ieisystem.com/kos/product-kos-xq.thtml?id=12126

2 文件系统损坏修复全流程（xfs_repair）

目前网上出现大量的主机输入输出错误，原因是由于主机文件系统损坏。一线人员大部分采用的是umont 和 mount的方式恢复，这种恢复方式不能真正修复已经损坏的文件系统，在后续使用过程中，仍然会再次出现主机端输入输出错误。

2.1 需要修复的场景

1	主机侧发现存在文件系统不可读写的情况，也可以通过查看主机端日志来确认是否有文件系统异常发生： xfs_force_shutdown 、I/O error
2	出现异常停电，供电恢复正常，主机和阵列系统重起之后
3	存储介质故障：出现LUN失效、RAID失效、以及IO超时或者出现慢盘，对慢盘进行更换，系统恢复正常之后
4	传输介质故障：如光纤、网线等损坏等，数据传输链路断开后又恢复正常之后

2.2 检查文件系统

注：检查文件系统必须保证将文件系统umount成功。

在根目录下输入“xfs_ncheck /dev/sdd（盘符）；echo $?”（注意：在执行此命令之前，必须将文件系统umount，否则会出现警告信 “xfs_ncheck: /dev/sdd contains a mounted and writable filesystem ”）敲回车键，查看命令执行返回值：0表示正常，其他为不正常，说明文件系统损坏，需要修复。

例如：xfs_ncheck /dev/vdc3; echo $?

2.3 修复过程

注：修复时需要暂停主机侧的业务，umount 和 mount 无法修复文件系统。

先umount要修复的文件系统的分区

然后输入 “xfs_repair /dev/sdd（盘符）”执行修复命令。

xfs_ncheck /dev/sdd; echo $?

如果为0===》成功修复。

如果不为0===》没有成功：请执行xfs_repair –L /dev/sdd命令，再执行xfs_repair（反复多修复几次）

2.4 xfs常用命令

xfs_admin	调整 xfs 文件系统的各种参数
xfs_copy	拷贝 xfs 文件系统的内容到一个或多个目标系统（并行方式）
xfs_db	调试或检测 xfs 文件系统（查看文件系统碎片等）
xfs_check	检测 xfs 文件系统的完整性
xfs_bmap	查看一个文件的块映射
xfs_repair	尝试修复受损的 xfs 文件系统
xfs_fsr	碎片整理
xfs_quota	管理 xfs 文件系统的磁盘配额
xfs_metadump	将 xfs 文件系统的元数据 (metadata) 拷贝到一个文件中
xfs_mdrestore	从一个文件中将元数据 (metadata) 恢复到 xfs 文件系统
xfs_growfs	调整一个 xfs 文件系统大小（只能扩展）
xfs_logprint	print the log of an XFS filesystem
xfs_mkfile	create an XFS file
xfs_info	expand an XFS filesystem
xfs_ncheck	generate pathnames from i-numbers for XFS
xfs_rtcp	XFS realtime copy command
xfs_freeze	suspend access to an XFS filesystem
xfs_io	debug the I/O path of an XFS filesystem

2.5 具体应用

查看文件块状况: xfs_bmap -v sarubackup.tar.bz2

查看磁盘碎片状况: xfs_db -c frag -r /dev/vdc3

文件碎片整理: xfs_fsr sarubackup.tar.bz2

磁盘碎片整理: xfs_fsr /dev/vdc3

2.6 最后方法

损失部分数据的修复方法

根据打印消息，修复失败时：
先执行xfs_repair -L /dev/sdd(清空日志，会丢失文件)，再执行xfs_repair /dev/sdd，再执行xfs_check /dev/sdd 检查文件系统是否修复成功。

说明：-L是修复xfs文件系统的最后手段，慎重选择，它会清空日志，会丢失用户数据和文件。

备注：

在执行xfs_repair操作前，最好使用xfs_metadump工具保存元数据，一旦修复失败，最起码可以恢复到修复之前的状态。

3 inode耗尽问题的预防与处理

在 Linux 操作系统中，inode 是文件系统中的一个重要概念，它用于唯一标识文件系统中的每个文件或目录。inode 的耗尽通常会导致系统无法创建新的文件或目录，这对于系统的正常运行是至关重要的。本章节将探讨导致 inode 耗尽的原因，并提出一些可能的解决策略，以及预防方案，以帮助系统管理员更好地管理和维护文件系统。

3.1 inode的定义

Linux系统下文件数据储存在"块"中，文件的元信息，例如文件的创建者、文件的创建日期、文件的大小等。这种储存文件元信息的区域就叫做inode，中文译名为"索引节点"。

inode也占用硬盘空间，硬盘格式化的时候，操作系统自动将硬盘分成两个区域。一个是数据区，存放文件数据；另一个是inode区（inode table），存放inode所包含的信息。

每个inode节点的大小，一般是128字节或256字节。inode节点的总数，在格式化时就给定，一般是每1KB或每2KB就设置一个inode。假定在一块1GB的硬盘中，每个inode节点的大小为128字节，每1KB就设置一个inode，那么inode table的大小就会达到128MB，占整块硬盘的12.8%。

3.2 inode的组成

inode 通常包含以下信息：

inode号	文件在文件系统中的唯一标识符。
文件类型	指出是文件还是目录。
权限	文件或目录的访问权限，如读、写、执行。
链接数	指向该 inode 的硬链接数量。
所有者ID	文件所有者的用户 ID。
组ID	文件所有者的组 ID。
大小	文件大小，以字节为单位。
块大小	文件系统分配给文件的数据块的大小。
时间戳	文件的创建时间、最后访问时间和最后修改时间。
数据块指针	指向文件数据实际存储位置的数据块指针。

3.3 inode的作用

inode 是文件系统高效管理文件的关键。当用户访问文件时，系统通过 inode 号快速定位到文件的数据块，而不需要遍历整个文件系统。这样可以显著提高文件访问速度，尤其是在大型文件系统中。此外，inode 还允许实现文件的硬链接，因为硬链接实际上是指向相同 inode 的多个文件名。

3.4 inode 耗尽的原因分析

inode 耗尽通常是由于文件系统的设计和管理不当导致的。以下是一些常见的导致 inode 耗尽的原因：

文件数量过多	在文件系统中，每个文件或目录都需要一个 inode。如果一个文件系统中有大量的文件或目录，那么 inode 的数量可能会迅速耗尽。特别是在一些用于存储大量小文件的系统中，如邮件服务器或版本控制系统，这个问题尤为突出。
硬链接的使用	硬链接是指向同一 inode 的多个文件名。每个硬链接都会增加 inode 的链接数。如果一个文件被频繁地创建硬链接，而没有相应的删除，那么即使文件被删除，其 inode 仍然被占用，导致 inode 无法被回收。
文件系统类型	不同的文件系统类型对 inode 的分配和管理策略不同。例如，ext4 文件系统在格式化时会预先分配一定数量的 inode。如果分配的 inode 数量不足，那么在文件系统使用过程中可能会出现 inode 耗尽的情况。
系统漏洞或错误配置	系统漏洞或错误配置也可能导致 inode 的异常使用。例如，某些应用程序可能会因为编程错误而创建大量临时文件，或者配置错误导致文件系统参数设置不当，从而加速 inode 的消耗。
文件系统损坏	文件系统损坏可能会破坏 inode 的分配记录，导致无法正确释放已删除文件的 inode，或者错误地分配 inode，从而引起 inode 耗尽的问题。