文件系统损坏解决实例
实例 解决 文件系统 损坏
2023-09-27 14:28:18 时间
客户系统早晨突然掉电,再启动,发现没法启动应用程序,报文件系统损坏。前辈帮忙解决了,记录下来解决步骤,自己学习:
客户系统早晨突然掉电,再启动,发现没法启动应用程序,报文件系统损坏。前辈帮忙解决了,记录下来解决步骤,自己学习: [root@erp02 ~]# mount /devdb
mount: wrong fs type, bad option, bad superblock on /dev/sdc2,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
以上,断电使得/dev/sdc2分区出错,不能mount: 查看开机启动的信息:
[root@erp02 ~]# dmesg | tail -n 20
ADDRCONF(NETDEV_UP): eth1: link is not ready
Bluetooth: Core ver 2.10
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8
ext3: No journal on filesystem on sdc2
Bluetooth: HIDP (Human Interface Emulation) ver 1.1
eth0: no IPv6 routers present
hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xec
FS-Cache: Loaded
ext3: No journal on filesystem on sdc2
ext3: No journal on filesystem on sdc2
ext3: No journal on filesystem on sdc2
进行修复操作,先查询Superblock位置信息:
[root@erp02 ~]# dumpe2fs /dev/sdc2 | grep -i superblock
dumpe2fs 1.39 (29-May-2006)
Primary superblock at 0, Group descriptors at 1-15
Backup superblock at 32768, Group descriptors at 32769-32783
Backup superblock at 98304, Group descriptors at 98305-98319
Backup superblock at 163840, Group descriptors at 163841-163855
Backup superblock at 229376, Group descriptors at 229377-229391
Backup superblock at 294912, Group descriptors at 294913-294927
Backup superblock at 819200, Group descriptors at 819201-819215
Backup superblock at 884736, Group descriptors at 884737-884751
Backup superblock at 1605632, Group descriptors at 1605633-1605647
Backup superblock at 2654208, Group descriptors at 2654209-2654223
Backup superblock at 4096000, Group descriptors at 4096001-4096015
Backup superblock at 7962624, Group descriptors at 7962625-7962639
Backup superblock at 11239424, Group descriptors at 11239425-11239439
Backup superblock at 20480000, Group descriptors at 20480001-20480015
Backup superblock at 23887872, Group descriptors at 23887873-23887887
根据查询得到的backup superblock位置号,进行修复:
[root@erp02 ~]# fsck.ext3 -y -b 98304 /dev/sdc2
e2fsck 1.39 (29-May-2006)
/dev/sdc2 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
... ...
/dev/sdc2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc2: 86343/31326208 files (0.4% non-contiguous), 53066211/62647263 blocks
[root@erp02 ~]# mount /dev/sdc2
mount: wrong fs type, bad option, bad superblock on /dev/sdc2,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
以上,发现还是不能mount。
检查:
[root@erp02 ~]# fsck.ext3 /dev/sdc2
e2fsck 1.39 (29-May-2006)
/dev/sdc2: clean, 86343/31326208 files, 53066211/62647263 blocks
[root@erp02 ~]# umount /dev/sdc2
umount: /dev/sdc2: not mounted
[root@erp02 ~]# mount /dev/sdc2
mount: wrong fs type, bad option, bad superblock on /dev/sdc2,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
检查完后变成ext2文件系统,所以不能mount为ext3文件系统。
[root@erp02 ~]# mount /dev/sdc2 /devdb
[root@erp02 ~]# mount
/dev/sdc2 on /devdb type ext2 (rw)
[root@erp02 ~]# umount /devdb
转为ext3文件系统
[root@erp02 ~]# /sbin/tune2fs -j /dev/sdc2
[root@erp02 ~]# mount /devdb
成功mount /devdb
启动DEV数据库和应用。 下面转载几篇重要的修复实例: http://blog.csdn.net/cymm_liu/article/details/36185733
http://blog.csdn.net/cymm_liu/article/details/36185805
http://blog.csdn.net/cymm_liu/article/details/36185881
http://blog.csdn.net/cymm_liu/article/details/36186127
服务器存在多个数据盘的情况下挂载点和磁盘对应关系 如果均为不可卸载的磁盘,控制台挂载点和磁盘是对应的,但是如果多个磁盘(大小一致)都可卸载,控制台和磁盘挂载点对应关系可能并不正确。 下文就是讲如何在服务器内判断磁盘和控制台ID对应关系。
XFS文件系统的备份、恢复、修复 XFS文件系统是硅谷图形公司(Silicon Graphics Inc,简称SGI)开发的用于IRIX(一个UNIX操作系统)的文件系统,后将XFS移植到Linux操作系统上
数据卷挂载问题快速恢复 本文阐述的是业务快速恢复方案:当Pod因为数据卷挂载重启失败时,暂不去解决节点挂载的问题,而是让pod先在其他节点启动成功,快速恢复业务,待业务恢复后再去分析出问题的节点。
客户系统早晨突然掉电,再启动,发现没法启动应用程序,报文件系统损坏。前辈帮忙解决了,记录下来解决步骤,自己学习: [root@erp02 ~]# mount /devdb
mount: wrong fs type, bad option, bad superblock on /dev/sdc2,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
以上,断电使得/dev/sdc2分区出错,不能mount: 查看开机启动的信息:
[root@erp02 ~]# dmesg | tail -n 20
ADDRCONF(NETDEV_UP): eth1: link is not ready
Bluetooth: Core ver 2.10
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.8
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.8
ext3: No journal on filesystem on sdc2
Bluetooth: HIDP (Human Interface Emulation) ver 1.1
eth0: no IPv6 routers present
hda: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hda: drive_cmd: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xec
FS-Cache: Loaded
ext3: No journal on filesystem on sdc2
ext3: No journal on filesystem on sdc2
ext3: No journal on filesystem on sdc2
进行修复操作,先查询Superblock位置信息:
[root@erp02 ~]# dumpe2fs /dev/sdc2 | grep -i superblock
dumpe2fs 1.39 (29-May-2006)
Primary superblock at 0, Group descriptors at 1-15
Backup superblock at 32768, Group descriptors at 32769-32783
Backup superblock at 98304, Group descriptors at 98305-98319
Backup superblock at 163840, Group descriptors at 163841-163855
Backup superblock at 229376, Group descriptors at 229377-229391
Backup superblock at 294912, Group descriptors at 294913-294927
Backup superblock at 819200, Group descriptors at 819201-819215
Backup superblock at 884736, Group descriptors at 884737-884751
Backup superblock at 1605632, Group descriptors at 1605633-1605647
Backup superblock at 2654208, Group descriptors at 2654209-2654223
Backup superblock at 4096000, Group descriptors at 4096001-4096015
Backup superblock at 7962624, Group descriptors at 7962625-7962639
Backup superblock at 11239424, Group descriptors at 11239425-11239439
Backup superblock at 20480000, Group descriptors at 20480001-20480015
Backup superblock at 23887872, Group descriptors at 23887873-23887887
根据查询得到的backup superblock位置号,进行修复:
[root@erp02 ~]# fsck.ext3 -y -b 98304 /dev/sdc2
e2fsck 1.39 (29-May-2006)
/dev/sdc2 was not cleanly unmounted, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
... ...
/dev/sdc2: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdc2: 86343/31326208 files (0.4% non-contiguous), 53066211/62647263 blocks
[root@erp02 ~]# mount /dev/sdc2
mount: wrong fs type, bad option, bad superblock on /dev/sdc2,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
以上,发现还是不能mount。
检查:
[root@erp02 ~]# fsck.ext3 /dev/sdc2
e2fsck 1.39 (29-May-2006)
/dev/sdc2: clean, 86343/31326208 files, 53066211/62647263 blocks
[root@erp02 ~]# umount /dev/sdc2
umount: /dev/sdc2: not mounted
[root@erp02 ~]# mount /dev/sdc2
mount: wrong fs type, bad option, bad superblock on /dev/sdc2,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
检查完后变成ext2文件系统,所以不能mount为ext3文件系统。
[root@erp02 ~]# mount /dev/sdc2 /devdb
[root@erp02 ~]# mount
/dev/sdc2 on /devdb type ext2 (rw)
[root@erp02 ~]# umount /devdb
转为ext3文件系统
[root@erp02 ~]# /sbin/tune2fs -j /dev/sdc2
[root@erp02 ~]# mount /devdb
成功mount /devdb
启动DEV数据库和应用。 下面转载几篇重要的修复实例: http://blog.csdn.net/cymm_liu/article/details/36185733
http://blog.csdn.net/cymm_liu/article/details/36185805
http://blog.csdn.net/cymm_liu/article/details/36185881
http://blog.csdn.net/cymm_liu/article/details/36186127
服务器存在多个数据盘的情况下挂载点和磁盘对应关系 如果均为不可卸载的磁盘,控制台挂载点和磁盘是对应的,但是如果多个磁盘(大小一致)都可卸载,控制台和磁盘挂载点对应关系可能并不正确。 下文就是讲如何在服务器内判断磁盘和控制台ID对应关系。
XFS文件系统的备份、恢复、修复 XFS文件系统是硅谷图形公司(Silicon Graphics Inc,简称SGI)开发的用于IRIX(一个UNIX操作系统)的文件系统,后将XFS移植到Linux操作系统上
数据卷挂载问题快速恢复 本文阐述的是业务快速恢复方案:当Pod因为数据卷挂载重启失败时,暂不去解决节点挂载的问题,而是让pod先在其他节点启动成功,快速恢复业务,待业务恢复后再去分析出问题的节点。
相关文章
- java调用c库实例
- [置顶] Cocos2d-x 实例源码分析之二 小实例的主框架
- android小程序开发实例!这些年我所经历的所有面试,社招面试心得
- Vue 简单实例 地址选配8 - 确认地址 - 设为默认地址
- Vue + ElementUI的电商管理系统实例18 解决serve命令中的ESLint语法错误
- Spring+Mybatis+SpringMVC后台与前台分页展示实例
- MATLAB实例:散点密度图
- service手动实例化(new)导致类中的spring对象无法注入的问题解决
- Halcon缺陷检测实例转OpenCV实现(五)混合颜色药片缺陷检测
- 3D-BoNet:3D 点云实例分割的新框架
- 解决C# WINFORM程序只允许运行一个实例的几种方法详解
- iptables实例2-state模块
- 关闭表空间的热备份实例重新启动重现错误和解决
- ORACLE 数据库名、实例名、ORACLE_SID的区别
- Oracle实例名,服务名等概念区别与联系
- JAVA new流程(实例化过程)
- vue 双项绑定的实例 货币转换
- 无法反序列化的java.util.ArrayList实例出来VALUE_STRING的(Can not deserialize instance of java.util.ArrayList out of VALUE_STRING)
- 最终一致性解决实例
- 目前为止最全的微信小程序项目实例
- Java连接Oracle数据库简单实例