linux操作系统故障处理-ext4文件系统超级块损坏修复   背景 前天外面出差大数据测试环境平台有7台服务器挂了,同事重启好了五台服务器,但是还有两台服务器启动不起来,第二天回来后我和同事再次去机房检查,发现两台服务器都显示superblock的报错,经过一番处理后两台服务器都正常进系统了,现决定重现superblock故障并将此类问题故障处理思路写下来方便后面新同事参考. 硬盘的结构 硬盘的物理结构侧视图和俯视图,这两张图传递出来的比较重要的信息如下: 磁盘划分为磁头(Head),柱面(C

1.故障发生背景 Ext4文件系统没有umount下来,之后做了fsck操作检查一致性,结果导致Ext4文件mount不上(有时也会表现为导致目录变成了文件). 报错提示信息:mount: wrong fs type, bad option, bad superblock 2.故障原理分析 某故障时,日志和数据不一致造成的正常文件系统数据被覆盖的现象.这种故障在Ext3.Ext4文件系统常有发生,好在.journal日志文件留有缓冲,恢复时可以从.journal日志文件里找到相应信息,并粘贴回相

我们今天介绍的数据恢复案例是一起 v7000存储文件系统损坏导致的数据丢失,首先简单介绍一下设备基本情况:发生文件系统损坏的是一台挂载在Windows2003服务器上的v7000存储,划分了一个容量为7个TB的分区,使用NTFS文件系统,里面是oracle数据库.引起这次故障的直接原因是服务器宕机重启服务器时系统自动进行磁盘扫描修复时客户强制关机断开了存储和服务器之间的链接,直接导致这台存储文件系统损坏,报错信息为"文件或目录损坏且无法读取".下面我们将详细介绍这次v7000存储数据恢

本文描述Ext4文件系统磁盘布局和元数据的一些分析,同样适用于Ext3和Ext2文件系统,除了它们不支持的Ext4的特性外.整个分析分两篇博文,分别概述布局和详细介绍各个布局的数据结构及组织寻址方式等.感兴趣的看官敬请留意和指导! 1. Ext4文件系统布局综述 一个Ext4文件系统被分成一系列块组.为减少磁盘碎片产生的性能瓶颈,块分配器尽量保持每个文件的数据块都在同一个块组中,从而减少寻道时间.以4KB的数据块为例,一个块组可以包含32768个数据块,也就是128MB. 1.1 磁盘布局 Ex

昨天追踪EXT4文件系统的过程中出了点问题,就是找不到文件,于是试了一下追踪FAT32文件系统的,成功之后有了点信心,今天继续嗑EXT4文件系统,终于找到啦,记录一下. 操作系统:linux(centos 6.5) 文件系统:EXT4 工具:hexdump,windows自带计算器 参考资源:<数据重现-文件系统原理精解与数据恢复最佳实践>(马林 著) <基于EXT4文件系统的数据恢复方法研究>(徐国天) 题为<Ext4文件系统架构分析>的系列博客 题为< 深入理

接着上一篇博文,继续分析Ext4磁盘布局中的元数据. 1.7 超级块 超级块记录整个文件系统的大量信息,如数据块个数.inode个数.支持的特性.管理信息,等待. 如果设置sparse_super特性标志,超级块和块组描述符表的冗余备份仅存放在编号为0或3.5.7的幂次方的块组中.如果未设置sparse_super特性标志,冗余备份存在与所有的块组中.以下是2.6.32.18内核中对Ext4超级块的描述: 3.0的内核中,Ext4的超级块加入了以下相关元数据:快照.文件系统错误处理相关.挂载选项

ioctl源码分析之交换两个文件的物理extents 1. 交换两个文件的extents Ext4 的EXT4_IOC_MOVE_EXT命令用于交换两个文件的extents,实际上是交换两个文件的对应逻辑长度的数据的物理存储空间(见下图),也是EXT4文件系统碎片整理的基础. 用户可以通过ioctl函数使用Ext4文件系统的Ioctl命令EXT4_IOC_MOVE_EXT将用户指定交换的两个文件及交换的范围的相关信息struct move_extent的地址传给ioctl的第三个参数unsign

首先说明: [root@CentOS6 ~]# rm -rf / //这条命令不可以执行 [root@CentOS6 ~]# rm -rf /* //这条命令可以执行,别去试 ext4文件系统上误删除文件,可以用extundelete恢复.ext3恢复使用ext3grep.Windows恢复使用final data v2.0汉化版和easyrecovery等. 误删除文件后,第一件事是避免误删除的文件内容被覆盖,这时可以卸载需要恢复文件的分区或以只读的方式挂载. (1).下载extundelet

在ubuntu中(以16.06为例),stat filename 可以查看文件的inode数值,但是如何确定该inode项具体在哪个块组下的inode Table中不是那么容易,接下来通过一步步计算来获取该inode具体在哪个块组下的inode Table的第几项. 1.首先可以通过dumpe2fs查看当前ext4文件系统的结构信息,命令为 dumpe2fs /dev/sdax             其中sdax为linux系统分区 可获取如下类似信息: Filesystem volume n

Ext4文件系统修复 目录 一. super block................................................................................................................................................. 二.查看分区设备信息..................................................................

恢复ext4文件系统superblock 1. Create ext4 文件系统. [root@localhost ~]# mkfs.ext4 /dev/vdb1 [root@localhost ~]# partprobe /dev/vdb 2. 挂载文件系统 [root@localhost ~]# grep vdb2 /etc/fstab /dev/vdb1    /ext4    ext4    defaults    0 0 [root@localhost ~]# mount -a [ro

1.修改/etc/fstab文件,使ext4文件系统支持磁盘配额. UUID="9e6dc1e8-4fc1-4984-be38-524573572d41" /mnt/ext ext4 defaults,usrquota 0 0 2.重新加载fstab文件 mount -o remount /dev/sdb1 3.查看mount挂载详细 mount ,可以看到其中有一条 /dev/sdb1 on /mnt/ext type ext4 (rw,relatime,seclabel,quota

最近我们的服务进程遇到kill -15后处于Z的状态,变为了僵尸进程,经过/proc/{thread_id}/stack查看其上线程的栈,发现是卡在了fwrite的过程中,而我们的系统中所有文件系统挂载参数都使用了delalloc参数,怀疑是这个原因:ext4挂载的时候打开了delalloc选项,然后系统在没有分配磁盘块的情况下写写写,到page cache被回写到磁盘时,发现磁盘已经满了,没办法分配新的磁盘块了,就Hang住了. 这篇文章是淘宝内核组的刘峥同学在内部技术论坛上发表的一篇文章,但

ext4作为Linux下的文件系统因其简单性.易管理性.兼容性强等特定,深受大多数用户喜欢,并且作为大多数Linux发行版中的默认文件系统.但是随着现在文件数目的增多以及文件数据的增大,ext4文件系统显得力不从心, 虽然ext4添加了很多的新的特性, 比如extent.bigalloc等,但是比不上XFS等文件系统,目前RedHat中的默认文件系统更改为了XFS,XFS在目前大数据环境下表现性能优于ext4,原始的XFS是针对于高端计算机用户,当然其他优秀的文件系统Btrfs.ZFS正在不断开

最近在帮一个研究生弄一个虚拟化环境下的基于Innodb的日志文件的读写优化的实验,实验的具体详细内容就不说了,其中有一个步骤需要将MySQL的日志文件放置在一块单独的硬盘里面,这块硬盘要么是ext2,要么是ext4,ext4的性能据说比前面的ext系列的要高,所以选择了ext4.但是ext4具备有日志的功能,如果开启了这个日志功能的话,到时又会有多个虚拟机同时跑,那么这个ext4的日志功能会对我们的实验数据产生一定的影响,并且我们在实验中并不需要到这个日志功能,所以需要将这个日志功能关闭.具体如

方法1: ambarella/rootfs目录下有skeleton(骨架)目录,此目录下就是文件系统的各个目录, [root@jz4775dev]# ls skeleton/ bin debug dev etc home lib linuxrc mnt opt proc root sbin sys tmp usr var 把相关的文件和二进制程序放进skeleton里的各个目录下,在ambarella/boards/h2_everest/ 目录下执行make -j8,在 ambarella/ou

本文转载自:http://blog.csdn.net/u011784994/article/details/53816976 make_ext4fs用于Android平台上制作ext4文件系统的镜像.用法举例: make_ext4fs -l 512M -s -a system system.ext4img system 之后再使用simg2img制作镜像. 有一个问题是,使用这样制作的镜像,system分区文件的权限都是预定的,即使先修改system目录文件权限后在制作镜像,烧入设备后,其权限仍

转载http://www.cnblogs.com/cobbliu/p/5603472.html 最近我们的服务进程遇到kill -15后处于Z的状态,变为了僵尸进程,经过/proc/{thread_id}/stack查看其上线程的栈,发现是卡在了fwrite的过程中,而我们的系统中所有文件系统挂载参数都使用了delalloc参数,怀疑是这个原因:ext4挂载的时候打开了delalloc选项,然后系统在没有分配磁盘块的情况下写写写,到page cache被回写到磁盘时,发现磁盘已经满了,没办法分配

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

记一次机房断电,导致xfs文件系统损坏处理方法 挂载时报以下错误: mount: mount /dev/sdb on /dev/sdb failed: Structure needs cleaning 参考:http://www.voidcn.com/article/p-wsxhjhzb-bty.html