当Linux执行ls报错 ls: cannot open directory .: Input/output error的时候，或者遇到类似的问题，要考虑几个方面。
1，看看是不是ls的分区不存在或者被误删除。
2，注意看是不是ls的分区权限出现问题。
3，经常出现的是该分区所在的磁盘扇区故障。

分析：由于服务器是重IO业务所有对磁盘损坏比较大，经常出现此类错误，上述这种情况一般都是硬盘问题导致文件系统损坏

解决方案：

1.如果条件允许可以重启系统试试。
2.如果无法重启或重启无法解决问题，lsof、fuser命令查找出还在损坏磁盘进行读写的进程，全部停掉（pkill -9 xxx）进程，尝试mount和umount文件系统，以便重放日志，修复文件系统，如果不行，再进行如下操作。

3、检查文件系统：先确保umount
xfs_check /dev/sdd(盘符); echo $? 返回0表示正常

4、执行xfs_repair -n，检查文件系统是否损坏，如何损坏会列出将要执行的操作如果幸运的话，会发现没有问题，你可以跳过后续的操作。该命令将表明会做出什么修改，一般情况下速度很快，即便数据量很大，没理由跳过。

5、执行xfs_repair修复文件系统
xfs_repair /dev/sdd (ext系列工具为fsck)

6、最后方法：损失部分数据的修复方法
根据打印消息，修复失败时：
umount -l 卸载磁盘 也可以到/etc/fstab用#注释掉有问题的磁盘后重启。
先执行xfs_repair -L /dev/sdd(清空日志，会丢失文件)，

fsck -y /dev/sdd；（ext文件系统）
xfs_repair -L /dev/sdd （xfs文件系统）

再执行xfs_repair /dev/sdd，
再执行xfs_check /dev/sdd 检查文件系统是否修复成功。

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

备注：
在执行xfs_repair操作前，最好使用xfs_metadump工具保存元数据，一旦修复失败，最起码可以恢复到修复之前的状态。
xfs_metadump为调试工具，可以不管，跳过。

7.修复完成后重新挂载目录，再次进入到目录查看问题是否解决。

**PS：正常操作流程是以上流程，但是偶尔会出现分区表损坏的情况，需要重新做raid 用 MegaCli64
注：修复过程可能造成文件丢失的风险，建议执行操作前对磁盘分区进行备份。**

错误解决couldn't initialize XFS library

注意：如果使用xfs_repair修复文件系统时提示fatal error -- couldn't initialize XFS library

修复方法
1、修改/etc/fstab，将待修复的分区先注释掉
2、重启主机
3、重复执行xfs_repair命令，必要时可使用-L选项 或者 执行fsck（ext文件）
4、修改/etc/fstab，恢复被修复的分区
5、重启主机

修复的过程比较漫长，根据坏道的多少来决定时间，一般是把有坏道的区块屏蔽掉。大概的过程类似这样：

大体的修复过程

我的/www挂在/dev/sdc1上

$ umount  /www
$ xfs_repair -n /dev/sdc1
xfs_repair: /dev/sdc1 contains a mounted and writable filesystem
fatal error -- couldn't initialize XFS library

故障盘的挂载点正在被使用，无法卸载：

在/etc/fstab中去掉挂载，重启机器，用xfs_repair查看文件系统状态，发现文件系统有错，bad nblocks 56158 for inode 2149532128, would reset to 56222：

$ xfs_repair -n /dev/sdc1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - scan filesystem freespace and inode maps...
agf_freeblks 58447576, counted 58447962 in ag 2
sb_icount 1728, counted 2368
sb_ifree 120, counted 127
sb_fdblocks 249095733, counted 246415105
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
         xfs_repair -n /dev/sdc1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ALERT: The filesystem has valuable metadata changes in a log which is being
ignored because the -n option was used.  Expect spurious inconsistencies
which may be resolved by first mounting the filesystem to replay the log.
        - scan filesystem freespace and inode maps...
sb_icount 8675584, counted 8916160
sb_ifree 129, counted 78
sb_fdblocks 890654902, counted 888245030
        - found root inode chunk
Phase 3 - for each AG...
        - scan (but don't clear) agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0xfs_repair: read failed: Input/output error
corrupt block 159 in directory inode 679744
        would junk block
xfs_repair: read failed: Input/output error
bad CRC for inode 3025651
bad magic number 0x764f on inode 3025651
bad version number 0xe on inode 3025651
inode identifier 98959915202630839 mismatch on inode 3025651
bad CRC for inode 3025652
bad magic number 0x3988 on inode 3025652
bad version number 0xffffffdc on inode 3025652
inode identifier 8603558946615461376 mismatch on inode 3025652
bad CRC for inode 3025653
bad magic number 0x70bd on inode 3025653
bad version number 0xc on inode 3025653
inode identifier 15061819622903254300 mismatch on inode 3025653
bad CRC for inode 3025654
bad magic number 0x4572 on inode 3025654
    .............中间省略............
would have cleared inode 3114781
bad CRC for inode 3114782, would rewrite
bad magic number 0x6742 on inode 3114782, would reset magic number
bad version number 0x6 on inode 3114782, would reset version number
inode identifier 11503560634604463032 mismatch on inode 3114782
would have cleared inode 3114782
bad CRC for inode 3114783, would rewrite
bad magic number 0xfbe1 on inode 3114783, would reset magic number
bad version number 0x4b on inode 3114783, would reset version number
inode identifier 3493962563101581967 mismatch on inode 3114783
would have cleared inode 3114783
xfs_repair: read failed: Input/output error
bad CRC for inode 6981682
bad magic number 0xe60f on inode 6981682
bad version number 0xffffff8f on inode 6981682
.............中间省略............
bad CRC for inode 6981690
bad magic number 0xef0e on inode 6981690
bad version number 0x17 on inode 6981690
inode identifier 10168696965768647825 mismatch on inode 6981690
bad CRC for inode 6981695, would rewrite
bad magic number 0x9a80 on inode 6981695, would reset magic number
bad version number 0x38 on inode 6981695, would reset version number
inode identifier 16841286204039292245 mismatch on inode 6981695
would have cleared inode 6981695
        - agno = 1
        - agno = 2
imap claims a free inode 4390362760 is in use, would correct imap and clear inode
        - agno = 3
    data fork in ino 2149532128 claims free block 201351977
    data fork in ino 2149532128 claims free block 201351978
    bad nblocks 56158 for inode 2149532128, would reset to 56222
    data fork in ino 2149532180 claims free block 138585846
    data fork in ino 2149532182 claims free block 135500463
            - agno = 3
            - process newly discovered inodes...
    Phase 4 - check for duplicate blocks...
            - setting up duplicate extent list...
            - check for inodes claiming duplicate blocks...
            - agno = 0
            - agno = 1
            - agno = 2
            - agno = 3
    bad nblocks 56158 for inode 2149532128, would reset to 56222
    No modify flag set, skipping phase 5
    Phase 6 - check inode connectivity...
            - traversing filesystem ...
            - traversal finished ...
            - moving disconnected inodes to lost+found ...
    Phase 7 - verify link counts...
    No modify flag set, skipping filesystem flush and exiting.

尝试修复xfs文件系统：

由于中间我没有及时复制，很快过掉了，所以这里忽略了一部分内容，有一些是修复完毕后补上的，仅供参考。

xfs_repair -L /dev/sdc1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
        - scan filesystem freespace and inode maps...
        - found root inode chunk
Phase 3 - for each AG...
        - scan and clear agi unlinked lists...
        - process known inodes and perform inode discovery...
        - agno = 0
        - agno = 1
        - agno = 2
        - agno = 3
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 1
        - agno = 0
        - agno = 2
        - agno = 3
Phase 5 - rebuild AG headers and trees...
        - reset superblock...
Phase 6 - check inode connectivity...
        - resetting contents of realtime bitmap and summary inodes
        - traversing filesystem  ...
        - traversal finished ...
        - moving disconnected inodes to lost+found ...
        disconnected inode 6636821373, moving to lost+found
        disconnected inode 6636821374, moving to lost+found
        disconnected inode 6636821375, moving to lost+found
        disconnected inode 6636821376, moving to lost+found
Phase 7 - verify and correct link counts...
resetting inode 6443046240 nlinks from 0 to 2
resetting inode 13983546 nlinks from 2 to 3
Maximum metadata LSN (943271989:842280503) is ahead of log (1:2).
Format log to cycle 943271992.
done

有错误的时候，会出现大量的修复的块，我没有截图和复制，仅供参考。

修复过程的一些命令参考：

blkid  /*查看uuid
cfdisk /dev/sdb   //查看分区信息
fdisk -l /dev/sda

smartctl -x /dev/sdc
smartctl -x /dev/sdc | more

xfs_repair -L /dev/sdc1
smartctl -x /dev/sdc | more
fsck -y /dev/sda2    /*确定文件系统
fsck -y /dev/sda3    /*确定文件系统
xfs_repair -L /dev/sda2   /*修复sda2
umount /home   /*sda2在home，卸载/home分区，无法修复的时候用

xfs_repair -L /dev/sdb1
xfs_repair -L /dev/sdc1
xfs_repair /dev/sdc1
xfs_repair /dev/sdb1
mount /dev/sdb1 /home
mount /dev/sdc1 /www
df -h
ls /www
ls /home

xfs_repair使用相关说明

1.现状
目前网上出现大量的主机输入输出错误，原因是由于主机文件系统损坏。一线人员大部分采用的是umont 和 mount的方式恢复，这种恢复方式不能真正修复已经损坏的文件系统，在后续使用过程中，仍然会再次出现主机端输入输出错误。
2.需要修复的场景
<1>.主机侧发现存在文件系统不可读写的情况，也可以通过查看主机端日志来确认是否有文件系统异常发生： xfs_force_shutdown 、I/O error 
<2>.出现异常停电，供电恢复正常，主机和阵列系统重起之后
<3>.存储介质故障：出现LUN失效、RAID失效、以及IO超时或者出现慢盘，对慢盘进行更换，系统恢复正常之后
<4>.传输介质故障：如光纤、网线等损坏等，数据传输链路断开后又恢复正常之后

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

4.修复过程

注：修复时需要暂停主机侧的业务，umount 和 mount 无法修复文件系统 。
1) 先umount要修复的文件系统的分区
3) 然后输入 “xfs_repair /dev/sdd（盘符）”执行修复命令。
xfs_check /dev/sdd; echo $?
A）如果为0===》成功修复。
B) 如果不为0===》没有成功：请执行xfs_repair –L /dev/sdd命令，再执 行xfs_repair（反复多修复几次）

5.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