案例_XFS文件系统故障处理方法

案例：某客户服务器因机房断电，导致多台设备无法进入 Linux *** 作系统，报错 XFS 文件系

统损坏。如图：
故障原因：

维护 Linux 服务器时会面临这样一种错误，即显示文件系统变成(Read Only System)，即

文件系统变成只读的方式，产生这一问题的原因可能有两种，一种是多机写入时同步机制出

现问题，另一种方式是单机写入时出现服务器掉电的情况

而本案例故障演员则为后者：单机写入时出现服务器掉电的情况。
名称解析:

XFS 文件系统:

            文件系统的定义：

                        文件系统是 *** 作系统用于明确存储设备（常见的是磁盘，也有基于 NAND Flash

的固态硬盘）或分区上的文件的方法和数据结构；即在存储设备上组织文件的方法。
            xfs 文件系统：

                                是一个日志型文件系统

日志文件系统？加一个日志来记录文件系统的更改，即使在断电或者是 *** 作系

统崩溃的情况下也能保证文件系统一致性

怎么保持的？

要向磁盘写数据的时候，肯定要改变元数据，日志就要在这之前记录要怎么去

改元数据的，当发生异常掉电或者文件系统崩溃后，进行修复时会检查文件系统的一致性，

当出现不一致时，可通过它来恢复。
故障处理方法:

第一步：使用#lsblk 查找挂载路径，用#umount 将其卸载；确保分区处于 umount 状态

(xfs_check /dev/sdb(盘符); echo $返回 0 表示正常)，进行下一步；
第二步：检测文件系统是否损坏：执行 xfs_repair -n，检查文件系统是否损坏。
第三步：修复文件系统：

xfs_repair /dev/sdb 以本案例为例。

注: XFS 文件系统在异常断电后发生文件系统报错概率很高。若仅仅因为断电导致文件系统

报错，通常是可以通过命令修复的。执行以上 repair *** 作不会对数据产生进一步损坏风险，

如发生修复失败是由于文件系统损坏严重，而不是此 *** 作导致
第四步：强制修复（会造成文件丢失,需要与客户说明数据安全&得到客户允许下才能 *** 作。）

先执行 xfs_repair -L /dev/sdb(清空日志，会丢失文件)，再执行 xfs_repair

/dev/sdb，再执行 xfs_check /dev/sdb 检查文件系统是否修复成功
说明：-L 是修复 xfs 文件系统的最后手段，慎重选择，它会清空日志，会丢失用户数据和文

件。
备注：在执行 xfs_repair *** 作前，最好使用 xfs_metadump 工具保存元数据，一旦修复失败，

最起码可以恢复到修复之前的状态

注:仅用作经验分享。
参考文献：

>1、需要注意DFS(分布式文件系统)根目录的放置。当用户访问WEB网页时，他们只知道要访问某个网站，而不知道网站后面可能还有其他服务器的存在。用户要访问的WEB服务器其实就是DFS根目录所在的主机。网络管理员要实现分布式文件系统，必须要先将网络中一台服务器内的共享文件夹设置为DFS根目录。这个DFS根目录主要用来存储分布式文件系统的映射关系。网络管理员要为该根目录取一个简约的名字，其他用户就可以通过这个名字访问这个分布式文件系统根目录下的文件。可见DFS根目录的安全性直接跟WEB服务器的安全相关。而且其也跟WEB应用服务的稳定性息息相关。因为如果这个目录出现了问题，映射关系遭受到破坏，则用户将无法正常访问文件资源。为了提高这个根目录的安全性，笔者建议是要把这个根目录部署在微软的NTFS文件系统上，并对此配置一定的安全措施。由于NTFS文件系统要比FAT32文件系统安全的多。无论是加密技术或者数据还原上，NTFS文件系统都有比较突出的表现。故笔者觉得，使用NTFS文件系统当作分布式文件系统的根目录，则其安全性与稳定性会更有保障一点。

如何让CentOS服务器磁盘io性能翻倍
这一期我们来看一下有哪些办法可以减少linux下的文件碎片。主要是针对磁盘长期满负荷运转的使用场景（例如>，仅完成安装系统、应用程序并上架后便拍拍屁股离开，远不能发挥服务器性能。服务器需要通过周期性的监控来确保硬件投资得到了预期回报--并对潜在问题提出告警，比如资源不足或硬件故障。性能监控工具可以提供大量的可用信息，但需要确保工具被正确安装与运行。本文将介绍可以帮助管理员们从系统性能监控中获得最大利益的技巧。
实现精确的性能监控
如果采集的信息存在错误，监控便毫无用处，所以确保数据的准确性是你得采取的第一步。准确性包括许多方面，如互通性、采样窗口、工具架构、虚拟化感知与校准。
互通性。在此讨论中，互通性是性能监控工具的基本功能，能够从数据中心内各种硬件与部件中访问与读取数据源。在部署了同一厂商产品线设备的同质环境内，利用集成在硬件中的内置挂钩，监控工具可以发挥极大优势。通过这些挂钩，工具可以抓取设备的详细运行信息。
在异质环境下，监控则成为了另外一种挑战，因为工具与硬件可能无法很好匹配。产商提供的工具可能可以提供一些硬件部件的特殊信息，而其他工具可能无法保障一致性。第三方性能监控工具可能无法检测每个监控器或硬件的细微差别，它们更依赖于 *** 作系统级的数据，而这些数据通常缺乏足够的颗粒度。在某些情况下，监控数据可能丢失或失真，从而降低系统性能监控的可用性。
工具与硬件之前的数据差异需要全面测试。例如，在购买工具之前，先测试并验证兼容性，在经过较长时间的可用性验证项目后，再开始将工具由测试环境部署至生产环境中。但问题同样从开始购买延伸至未来产品升级或技术刷新周期。当你更换硬件或升级工具，你需要测试监控工具的互通性来确保性能监控工具依旧可以正常工作并提供准确数据。
采样。准确性同样依赖于收集数据用的采样窗口。当负载与运行参数可能一直处于波动状态时，数据准确性将十分重要。理想情况下，性能监控工具可以捕捉整台服务器的运行周期。技巧在于决定运行周期是怎样的。这依赖于每个负载与宿主主机是如何被使用的。例如，每台服务器的内存性能可能需要极快的采样率，而采样窗口需要跨越好几分钟。与此相反，观察某个合作HR系统的CPU使用情况可能需要已较低的频率捕捉数值，但采样窗口周期需要长达30天甚至更长。如何正确采样并没有标准答案，不同属性的 *** 作系统同样需要通过不同的比率与窗口灵活定义。
工具架构。性能监控工具通常需要在受监控系统上安装代理或额外驱动(即使是虚拟机)。代理具有优势也有不足。首先，它们十分有用，因为代理可以收集并传输许多重要信息，比无代理的监控工具提供更多监控参数。尽管如此，代理通常被作为软件客户端，将所有数据报告给中央服务器，中央服务器将收集与处理这些数据。所以每个代理都需要占用一定的计算资源，这可能在一定程度上影响整台服务器的负载性能。
我所在环境下所有计算机拥有两个代理， Chris Steffen，Kroll Factual Data的首席技术架构师说。一个应用程序代理监控我们所有应用程序的健康状况，而且我们还有System Center [Virtual Machine Manager]代理安装在所有虚拟机宿主上。
这些年来，关于代理的负面影响一直在降低，但它们所产生的影响一直在被评估，尤其在执行关键任务或对性能要求十分苛刻的负载上。不仅如此，Steffen同样表示，新兴的监控工具可以提供更多功能，包括自动化安装，重装或维护运行环境中的代理。
虚拟化感知。
虚拟化软件把应用负载从硬件中抽象化。当传统性能监控工具试图在虚拟化环境中报告，抽象层常常发生错误结果，因为老工具是同直接监控硬件，而不是通过控制计算资源的hypervisor。考虑到虚拟化技术的人气和重要性，管理员应该选择能监控虚拟化的监控工具。这样能让性能监控同时管到物理目标和虚拟目标，管理员可以才可以收集到精确的数据。
管理员们有时候还需要采集虚拟机与承载虚拟机的宿主服务器指标，Kleyman说。这种情况下，需要在虚拟化与物理层级别进行性能监控以确保最佳负载性能并保障用户体验。
传感器校准。需要忽视传感器本身的重要性。来自网络交换机或服务器的数字信信号常都是十分准确的。但是某些传感器，例如温度，湿度，空气流或其他环境类型的传感器通常是通过模拟信号传输，可能需要经常校对并定期更换电池来保证其长期稳定的工作。
最大化性能监控工具价值
如果没有正确使用，工具是无法产生价值的。在许许多多的案例中，性能监控工具已经被部署，但是没有清晰的规划来使用与分析所收集到的海量数据。工具则变成了管理员们用来抽查或不定期故障处理的简单工具;这是一种投资浪费。
性能监控工具报告同样可以作为能力规划的基础参考，或协助完成技术刷新项目。性能指标可以帮助展示RIO[投资回报率],Kleyman说。通过了解旧系统性能，并比对新款服务器性能，我们可以决定是否将钱投资在新设备上已提升计算性能并获得更长远的利益。
但Steffen同样建议用户多留个心眼，秉着信任，但要核查的态度来对待性能监控工具，有可能某些服务器监控工具已经被验证，与其他工具相比可以获得十分准确的数值，但如果用来监控网络设备则可能出现一些异常。好的业务决策需要有优质的数据进行支撑，而且若工具无法提供准确、可验证的结果，那样将很难给业务决策提供有力支持。
lg=t

大致结果类似下图：

Mem行（单位均为M）：

(-/+ buffers/cache)行：

Swap行指交换分区。

实际上不要看free少就觉得内存不足了，buffers和cached都是可以在使用内存时拿来用的，应该以(-/+ buffers/cache)行的free和used来看。只要没发现swap的使用，就不用太担心，如果swap用了很多，那就要考虑增加物理内存了。

大致结果类似下图：

上方文字部分的红框为总的CPU占用百分率，下方的表格是每个进程的CPU占用率，在表格第一行可以看到红框中占用率超过了150%，这是因为服务器是多核CPU，而该进程使用了多核。

大致结果类似下图：

表格中会显示显卡的一些信息，第一行是版本信息，第二行是标题栏，第三行就是具体的显卡信息了，如果有多个显卡，会有多行，每一行的信息值对应标题栏对应位置的信息。

需要注意的一点是显存占用率和GPU占用率是两个不一样的东西，类似于内存和CPU，两个指标的占用率不一定是互相对应的。

在下面就是每个进程使用的GPU情况了。

大致结果如下图：

表格中每一行代表一个文件系统，各列意义如下：

要查看具体某个文件或者文件夹的大小的话，可以使用下面的命令：

du命令可以查看文件或文件夹的磁盘使用空间，而-h参数的意思是使用GB、MB等易读的格式。如果不带--max-depth参数，那么将循环列出文件夹下所有文件和文件夹占用的空间，带此参数，则是指定深入目录的层数。

如果要看文件夹下所有文件的大小，可以使用：

查看作者首页

---