RHEL5.8 ext3文件系统损坏的只检测不修复(fsck -n)

[[email protected] ~]# df -Th
Filesystem    Type    Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
              ext3    872G  345G  482G  42% /
/dev/sda1     ext3    190M   13M  168M   7% /boot
tmpfs        tmpfs    2.0G     0  2.0G   0% /dev/shm
[[email protected] ~]# uname -r
2.6.18-308.el5
[[email protected] ~]# uname -a
Linux lei1 2.6.18-308.el5 #1 SMP Fri Jan 27 17:17:51 EST 2012 x86_64 x86_64 x86_64 GNU/Linux
[[email protected] ~]#
[[email protected] ~]#
[[email protected] ~]# fsck -n /dev/mapper/VolGroup00-LogVol00
fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
Warning!  /dev/mapper/VolGroup00-LogVol00 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/mapper/VolGroup00-LogVol00 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 67141633 has zero dtime.  Fix? no

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -76226569
Fix? no

Free blocks count wrong for group #643 (1459, counted=1458).
Fix? no

Free blocks count wrong for group #2326 (31294, counted=31293).
Fix? no

Free blocks count wrong (127388309, counted=137957667).
Fix? no

Inode bitmap differences:  -67141633
Fix? no

Free inodes count wrong (235607546, counted=235607894).
Fix? no

/dev/mapper/VolGroup00-LogVol00: ********** WARNING: Filesystem still has errors **********

/dev/mapper/VolGroup00-LogVol00: 158214/235765760 files (1.1% non-contiguous), 108361067/235749376 blocks
[[email protected] ~]#

再次强调,fsck -y 修复文件系统,是一件很危险的事情,我曾经遇到过fsck -y 之后,fsck直接把文件给删除了。。。

时间: 2024-12-29 23:51:35

RHEL5.8 ext3文件系统损坏的只检测不修复(fsck -n)的相关文章

Linux文件系统损坏导致无法正常启动与fsck修复工具

问题:今天在打开自己的虚拟机学习的时候,发现在文件系统检查过程中出现以下的报错:/dev/mapper/VolGroup-lv_root:UNEXPECTED INCONSISTENCY;RUN fsck MANUALLY. [FAILED]这提示意味着,Linux文件系统损坏了,导致文件系统损坏的原因可能是异常的关机,比如:突然断电.这里的提示已经很明确的说明了,"UNEXPECTED INCONSISTENCY;RUN fsck MANUALLY.":意外的不一致性导致文件系统损坏

ext3文件系统基础

http://blog.csdn.net/haiross/article/category/1488205/2 block size: 是文件系统最小的单位,Ext2/Ext3/Ext4 的区块大小可以是 1024.2048 或 4096 字节. (Compaq Alpha 可 以使用 8192 字节区块) mke2fs 一般缺省会把小于 512 MiB 的文件系统使用 1024 字节区块格式化,等于或大于 512 MiB 的文件系统使用 4096 字节区块.(实际是视乎 mke2fs.conf

ext3文件系统,reiserfs,xfs,jsf那种性能好点

ext2 是一个旧的 Linux 档桉系统,没有日志功能. 启用的时间通常需要很久.目前有许多 日志型态 的档桉系统可以以更快的速度及更好的效率完成系统启用和检查. ext3 为 ext2 的日志版,提供了 metadata 日志系统 并且可以快速地使用日志系统复原.ext3 是个相当不错并且可靠的档桉系统. 它有额外的 hashed b-tree 索引功能,开启他后几乎任何情况内都是高效能.你可以在 mke2fs 指令加上 -O dir_index 开启这个功能.简单来说,ext3 是一个很杰

Ext3文件系统及JDB介绍

Ext3介绍 对于ext3文件系统,磁盘空间划分一系列block groups,每个group有位图来跟踪inode和data块的分配和范围.其物理布局如下: Superblock:位于group内第0个block,为了保证兼容,前1024B字节为0,SB从1024B偏移处存储,大小1024B.存储的是文件系统相关信息,在多个group中有备份(0,1,3,5,7,9,25,37,49,81等).大部分信息在格式化时确定,并只读.可以用dumpe2fs命令查看: Group Descriptor

Linux ext2/ext3文件系统详解

转载: Linux ext2/ext3文件系统使用索引节点来记录文件信息,作用像windows的文件分配表.索引节点是一个结构,它包含了一个文件的长度.创建及修改时间.权限.所属关系.磁盘中的位置等信息.一个文件系统维护了一个索引节点的数组,每个文件或目录都与索引节点数组中的唯一一个元素对应.系统给每个索引节点分配了一个号码,也就是该节点在数组中的索引号,称为索引节点号. linux文件系统将文件索引节点号和文件名同时保存在目录中.所以,目录只是将文件的名称和它的索引节点号结合在一起的一张表,目

Linux磁盘分区管理--ext2和ext3文件系统逻辑结构分析

本文出自 "Pavel" 博客,请务必保留此出处http://pavel86.blog.51cto.com/8349178/1688277 Linux系统支持多种文件系统, 文件系统间的区别在于: 不同文件系统对同一块磁盘分区存储文件的结构不同. 举例来说相当于某些土豪买了500平住房: 有些工作狂会隔出1间卧室,1间客厅,1间厨房和5个工作间; 有些美食家会隔出3间卧室,3间客厅,4间厨房等等. 文件系统就相当于对于分割出不同性能的区域用于使用各自不同的方式存储数据. Ext(ext

第6章 ext3文件系统反删除利器ext3grep

第6章  ext3文件系统反删除利器ext3grep 只能用于ext3文件系统!!!!!!!高俊峰(高性能Linux服务器构建实战:运维监控.性能调优与集群应用(完整)) Linux作为企业级服务器,数据的安全性至关重要,任何数据的丢失和误删除都是不可容忍的.作为系统管理员,一定要有数据保护意识,不但要对服务器数据进行定期备份,而且还要具有误删除数据后将其快速恢复的技能.本章重点讲述Linux下的ext3文件系统中用于数据恢复的开源软件ext3grep.通过这个软件,可以快速.准确地恢复误删除的

ext3文件系统反删除利器ext3grep应用实战

一."rm –rf"带来的困惑 国外一份非常著名的Linux系统管理员守则中有这么一条"慎用 rm –rf 命令,除非你知道此命令将带来什么后果",可见,这个命令对系统管理员的重要性.在实际的工作中,由此命令带来的误删除数据案例屡见不鲜,很多系统管理员都遇到过或者犯过这样的错误.由于开发人员对命令的不熟悉,或者粗心大意.疏于管理,执行了此命令,数据在一瞬间就被清空了.Linux不具备类似回收站的功能,这就意味着数据丢失.虽然Linux自身提供了恢复数据的机制,但是这

EXT3文件系统误删除导致文件系统中的邮件丢失恢复方法

一.故障描述 由8块盘组成的RAID5, 上层是EXT3文件系统,由于误删除导致文件系统中的邮件丢失 二.镜像磁盘为防止数据恢复过程中由于误操作对原始磁盘造成二次破坏, 使用winhex软件为每块磁盘做镜像, 以后所有的数据恢复操作都在镜像盘上进行, 不会对原始磁盘造成影响镜像结果如下:图一 三.组建RAID通过分析数据在硬盘中分布的规律, 获取RAID类型, RAID条带的大小,以及每块磁盘的顺序.根据分析结果使用UFS组建RAID.结果如下:图二 四.导出目标分区 从组建好的RAID中可以看