| |
客户名称 |
辽宁某通信科技有限公司 NAS RAID5 XFS文件系统数据恢复成功 |
设备类型 |
直联式存储NAS |
故障描述 |
RAID信息丢失,硬盘有坏道,数据无法访问 |
介质类型 |
硬盘 |
介质品牌 |
SEAGATE |
介质型号 |
ST31000340NS |
介质序列号 |
9QJ39F54 9QJ3K5VW
9QJ2JHM5
9QJ2LS21
9QJ3CC4B
JQJ3CC54
9QJ3CC5F
JQJ3CC58 |
介质接口 |
SATA |
介质容量 |
1000G*8 |
操作系统 |
LINUX |
分区大小 |
7T |
文件系统 |
XFS |
数据丢失原因 |
RAID问题 |
解决方案 |
沈阳凯文工程师手工算法分析原RAID参数,对坏道硬盘进行相应处理,成功恢复所有数据 |
修复结果 |
100%恢复 |
恢复所用时间 |
因数据量太大,,共6T数据,拷贝比较费时,共用时5天5夜. |
备 注 |
因客户要求保密,不让拍照,所以无照片
相关知识点:什么是XFS文件系统
XFS 是 Silicon Graphics,Inc. 于 90 年代初开发的。它至今仍作为 SGI 基于 IRIX
的产品(从工作站到超级计算机)的底层文件系统来使用。现在,XFS 也可以用于 Linux。XFS 的 Linux
版的到来是激动人心的,首先因为它为 Linux
社区提供了一种健壮的、优秀的以及功能丰富的文件系统,并且这种文件系统所具有的可伸缩性能够满足最苛刻的存储需求。 主要特性包括:
数据完全性 采用XFS文件系统,当意想不到的宕机发生后,首先,由于文件系统开启了日志功能,所以你磁盘上的文件不再会意外宕机而遭到破坏了。不论目前文件系统上存储的文件与数据有多少,文件系统都可以根据所记录的日志在很短的时间内迅速恢复磁盘文件内容。
传输特性 XFS文件系统采用优化算法,日志记录对整体文件操作影响非常小。XFS查询与分配存储空间非常快。xfs文件系统能连续提供快速的反应时间。笔者曾经对XFS、JFS、Ext3、ReiserFS文件系统进行过测试,XFS文件文件系统的性能表现相当出众。
可扩展性 XFS
是一个全64-bit的文件系统,它可以支持上百万T字节的存储空间。对特大文件及小尺寸文件的支持都表现出众,支持特大数量的目录。最大可支持的文件大小为263
= 9 x 1018 = 9 exabytes,最大文件系统尺寸为18 exabytes。 XFS使用高的表结构(B+树),保证了文件系统可以快速搜索与快速空间分配。XFS能够持续提供高速操作,文件系统的性能不受目录中目录及文件数量的限制。
传输带宽 XFS
能以接近裸设备I/O的性能存储数据。在单个文件系统的测试中,其吞吐量最高可达7GB每秒,对单个文件的读写操作,其吞吐量可达4GB每秒。 XFS
设计: 分配组(allocation groups) 当创建 XFS
文件系统时,底层块设备被分割成八个或更多个大小相等的线性区域(region)。您可以将它们想象成“块”(chunk)或者“线性范围(range)”,但是在
XFS
术语中,每个区域称为一个“分配组”。分配组是唯一的,因为每个分配组管理自己的索引节点(inode)和空闲空间,实际上,是将这些分配组转化为一种文件子系统,这些子系统正确地透明存在于
XFS 文件系统内。
xfs内部结构部分介绍:
1 XFS INODE number:变长的位数表示,三部分组成:起始块组号+起始块号+块内INODE号。起始块号与块内INODE号的位长由SUPERBLOCK中参数指定。
2 XFS EXT number:变长的位数表示,对于32位系统版本,首先用4个4字节表示EXT
编号,EXT编号由两部分组成:起始位置和大小。EXT编号的起始位置为L1(0-32)连接L2(0-32)连接L3(31-21)构成中间值(暂定为TEMP)然后TEMP又由两部分组成:块组号与块组内部块号,结构为后agblklog位表示内部块号,其余高位表示块组号。
分配组与可伸缩性 那么,XFS 到底为什么要有分配组呢?主要原因是,XFS 使用分配组,以便能有效地处理并行
IO。因为,每个分配组实际上是一个独立实体,所以内核可以 同时与多个分配组交互。如果不使用分配组,XFS
文件系统代码可能成为一种性能瓶颈,迫使大量需求 IO 的进程“排队”来使索引节点进行修改或执行其它种类的元数据密集操作。多亏了分配组,XFS
代码将允许多个线程和进程持续以并行方式运行,即使它们中的许多线程和进程正在同一文件系统上执行大规模 IO 操作。因此,将 XFS
与某些高端硬件相结合,您将获得高端性能而不会使文件系统成为瓶颈。分配组还有助于在多处理器系统上优化并行 IO
性能,因为可以同时有多个元数据更新处于“在传输中”。 B+ 树无处不在 分配组在内部使用高效的 B+
树来跟踪主要数据,譬如空闲空间的范围和索引节点。实际上,每个分配组使用 两棵 B+
树来跟踪空闲空间;一棵树按空闲空间的大小排序来存储空闲空间的范围,另一棵树按块设备上起始物理位置的排序来存储这些区域。XFS
擅长于迅速发现空闲空间区域,这种能力对于最大化写性能很关键。 当对索引节点进行管理时,XFS 也是很有效的。每个分配组在需要时以 64
个索引节点为一组来分配它们。每个分配组通过使用 B+ 树来跟踪自己的索引节点,该 B+ 树记录着特定索引节点号在磁盘上的位置。您会发现 XFS
之所以尽可能多地使用 B+ 树,原因在于 B+ 树的优越性能和极大的可扩展性。 日志记录 当然,XFS
也是一种日志记录文件系统,它允许意外重新引导后的快速恢复。象 ReiserFS 一样,XFS 使用逻辑日志;即,它不象 ext3
那样将文字文件系统块记录到日志,而是使用一种高效的磁盘格式来记录元数据的变动。就 XFS
而言,逻辑日志记录是很适合的;在高端硬件上,日志经常是整个文件系统中争用最多的资源。通过使用节省空间的逻辑日志记录,可以将对日志的争用降至最小。另外,XFS
允许将日志存储在另一个块设备上,例如,另一个磁盘上的一个分区。这个特性很有用,它进一步改进了 XFS 文件系统的性能。 象 ReiserFS
一样,XFS 只对元数据进行日志记录,并且在写元数据之前,XFS 不采取任何专门的预防措施来确保将数据保存到磁盘。这意味着,使用 XFS(就象使用
ReiserFS)时,如果发生意外的重新引导,则最近修改的数据有可能丢失。然而,XFS 日志有两个特性使得这个问题不象使用 ReiserFS
时那么常见。 使用 ReiserFS
时,意外重新引导可能导致最近修改的文件中包含先前删除文件的部分内容。除了数据丢失这个显而易见的问题以外,理论上,这还可能引起安全性威胁。相反,当
XFS 日志系统重新启动时,XFS 确保任何未写入的数据块在重新引导时 置零。因此,丢失块由空字节来填充,这消除了安全性漏洞 ―
这是一种好得多的方法。 现在,关于数据丢失问题本身,该怎么办呢?通常,使用 XFS 时,该问题被最小化了,原因在于以下事实:XFS 通常比
ReiserFS 更频繁地将暂挂元数据更新写到磁盘,尤其是在磁盘高频率活动期间。因此,如果发生死锁,那么,最近元数据修改的丢失,通常比使用
ReiserFS 时要少。当然,这不能彻底解决不及时写数据块的问题,但是,更频繁地写元数据也确实促进了更频繁地写数据。 延迟分配
研究一下 延迟分配这个 XFS 独有的特性,然后我们将结束关于 XFS 的技术概述。正如您可能知道的,术语
分配(allocation)是指:查找空闲空间区域并用于存储新数据的过程。 XFS 通过将分配过程分成两个步骤来处理。首先,当 XFS
接收到要写入的新数据时,它在 RAM 中记录暂挂事务,并只在底层文件系统上 保留适当空间。然而,尽管 XFS 为新数据保留了空间,但
它却没有决定将什么文件系统块用于存储数据,至少现在还没决定。XFS 进行拖延,将这个决定延迟到最后可能的时刻,即直到该数据真正写到磁盘之前作出。
通过延迟分配,XFS 赢得了许多机会来优化写性能。到了要将数据写到磁盘的时候,XFS
能够以这种优化文件系统性能的方式,智能地分配空闲空间。尤其是,如果要将一批新数据添加到单一文件,XFS 可以在磁盘上分配一个
单一、相邻区域来储存这些数据。如果 XFS
没有延迟它的分配决定,那么,它也许已经不知不觉地将数据写到了多个非相邻块中,从而显著地降低了写性能。但是,因为 XFS
延迟了它的分配决定,所以,它能够一下子写完数据,从而提高了写性能,并减少了整个文件系统的碎片。
在性能上,延迟分配还有另一个优点。在要创建许多“短命的”临时文件的情况下,XFS
可能根本不需要将这些文件全部写到磁盘。因为从未给这些文件分配任何块,所以,也就不必释放任何块,甚至根本没有触及底层文件系统元数据。 |
|
| |
|
|