首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >Linux文件系统故障,Input/output error

Linux文件系统故障,Input/output error

作者头像
小陈运维
发布2021-10-13 11:11:20
发布2021-10-13 11:11:20
8.9K0
举报
文章被收录于专栏:小陈运维小陈运维

事情是这样的,在启动某一个应用程序的时候,出现 Input/output error 的报错,磁盘以及目录无法使用的情况下,进行了重启,重启完成后是可以正常使用的,过一段时间后就会再次出现这个问题,一番Google之后怀疑是磁盘出现问题,根据网友的解决方案尝试之后发现,这个方法可行,下文是命令及回显:

使用ls命令查看的时候出现这个报错

代码语言:javascript
复制
[root@webc ~]# ls /data/
ls: 无法访问/data/: 输入/输出错误
[root@webc ~]#

这个是xfs的文件系统,所以使用如下命令进行修复

代码语言:javascript
复制
[root@webc ~]# xfs_repair /dev/sdc1
xfs_repair: cannot open /dev/sdc1: 设备或资源忙

这时这个问题,不要慌,先把磁盘卸载了在进行修复

代码语言:javascript
复制
[root@webc ~]# umount /dev/sdc1
[root@webc ~]# xfs_repair /dev/sdc1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
[root@webc ~]# 
[root@webc ~]# 
[root@webc ~]# xfs_repair /dev/sdc1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
[root@webc ~]# xfs_repair /dev/sdc1 -L
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
destroyed because the -L option was used.
        - scan filesystem freespace and inode maps...
agi unlinked bucket 31 is 7620063 in ag 5 (inode=10745038303)
sb_icount 533632, counted 533568
sb_ifree 617, counted 614
sb_fdblocks 2852137932, counted 2860186916
        - 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
        - agno = 4
        - agno = 5
correcting bt key (was 91997, now 92001) in inode 10745038303
    data fork, btree block 1343129285
correcting bt key (was 226254, now 226257) in inode 10745038303
    data fork, btree block 1345535075
correcting bt key (was 241554, now 241557) in inode 10745038303
    data fork, btree block 1345535075
correcting bt key (was 795517, now 795515) in inode 10745038303
    data fork, btree block 1343659983
data fork in regular inode 10745038303 claims used block 1353137709
correcting nextents for inode 10745038303
bad data fork in inode 10745038303
cleared inode 10745038303
        - agno = 6
        - agno = 7
        - agno = 8
correcting nextents for inode 17197661037, was 870903 - counted 870911
        - agno = 9
        - agno = 10
correcting bt key (was 1923723, now 1923730) in inode 21481716216
    data fork, btree block 2687659655
correcting bt key (was 1997785, now 1997794) in inode 21481716216
    data fork, btree block 2687659655
correcting nextents for inode 21481716216, was 918874 - counted 918898
        - process newly discovered inodes...
Phase 4 - check for duplicate blocks...
        - setting up duplicate extent list...
        - check for inodes claiming duplicate blocks...
        - agno = 0
        - agno = 3
        - agno = 4
        - agno = 2
        - agno = 5
        - agno = 6
        - agno = 1
        - agno = 7
        - agno = 9
        - agno = 8
        - agno = 10
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 ...
Phase 7 - verify and correct link counts...
Maximum metadata LSN (15:166217) is ahead of log (1:2).
Format log to cycle 18.
done
[root@webc ~]#

修复完成后在把磁盘挂上,即可生效

代码语言:javascript
复制
[root@webc ~]# mount /dev/sdc1 /data/

查看一下这个磁盘是否可以正常使用

代码语言:javascript
复制
[root@webc ~]# cd /data/vm/
[root@webc vm]# ls
CentOS7-Clone-1  CentOS7-Clone-3  CentOS7-Clone-4  CentOS7-Clone-5  CentOS8  Ubuntu

此刻文件系统已修复完毕

注意:

修复其他文件系统使用fsck命令进行修复

例如ext4文件系统

代码语言:javascript
复制
fsck -t ext4 -y /dev/sda1

不同的文件系统,命令会有些许不同,灵活变通一下

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-06-19,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Linux运维交流社区 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档