• Linux下几种常用文件系统Ext4、XFS、ZFS以及Btrfs的简介及优缺点对比

什么是文件系统（filesystem），用一两句话解答出来，实在有点困难，这个问题只能留给文件系统的设计者或对文件系统精通的专业人士来答复；

下面是关于filesystem的定义是我从 Google.com 上搜索到的；下面我们分析一下，对我们来说，了解一下也有好处。

文件系统是包括在一个磁盘（包括光盘、软盘、闪盘及其它存储设备）或分区的目录结构；一个可应用的磁盘设备可以包含一个或多个文件系统；

如果您想进入一个文件系统，首先您要做的是挂载（mount）文件系统；为了挂载（mount）文件系统，您必须指定一个挂载点；

文件系统是在一个磁盘（包括光盘、软盘、闪盘及其它存储设备）或分区组织文件的方法，如NTFS或FAT；

文件系统是文件的数据结构或组织方法。在Unix中，文件系统涉及两个非常独特的事情，目录树或在磁盘或分区上文件的排列；

文件系统是基于操作系统的，建立在磁盘媒质上的可见体系结构，例如这种结构对于一个Unix用户来说可以用ls 或其它工具可以看到；

文件系统是基于被划分的存储设备上的逻辑上单位上的一种定义文件的命名、存储、组织及取出的方法；

在计算机业，一个文件系统是有组织存储文件或数据的方法，目的是易于查询和存取。

文件系统是基于一个存储设备，比如硬盘或光盘，并且包含文件物理位置的维护；也可以说文件系统也是虚拟数据或网络数据存储的方法，比如NFS；

文件系统是基于操作系统的，建立在磁盘媒质上的可见体系结构，可以在划分的存储设备上的逻辑上单位上定义文件的命名、存储、组织及取出的方法，目的是有组织存储文件或数据的，易于查询和存取。

LOSF（Losts Of Small Files）问题是工业界和学术届工人的难题。尤其是在人工智能大数据领域，对于数据读写的性能要求很高，但是存储的文件大小很小。

通常我们认为大小在1MB以内的文件称为小文件，百万级数量及以上称为海量，由此量化定义海量小文件问题，也就是LOSF。

LOSF应用场景目前在实际中越来越常见，如社交网站、电子商务、广电、网络视频、高性能计算，这里举几个典型的应用场景。

• Facebook存储了600亿张以上的图片，推出了专门针对海量小图片定制优化的Haystack进行存储。
• 淘宝目前应该是最大的C2C电子商务网站，存储了超过200亿张图片，平均大小仅15KB，也推出了针对小文件优化的TFS文件系统存储这些图片。
• 歌华有线可以进行图书和视频的在先点播，图书每页会扫描成一个几十KB大小的图片，总图片数量超过20亿；
• 视频会由切片服务器根据视频码流切割成1MB左右的分片文件，100个频道一个星期的点播量，分片文件数量可达1000万量级。
• 动漫渲染和影视后期制作应用，会使用大量的视频、音频、图像、纹理等原理素材，一部普通的动画电影可能包含超过500万的小文件，平均大小在10～20KB。
• 金融票据影像，需要对大量原始票据进行扫描程图片和描述信息文件，单个文件大小为几KB至几百KB的不等，文件数量达到数千万乃至数亿，并且逐年增长。

目前的文件系统，包括本地文件系统、分布式文件系统和对象存储系统，都是主要针对大文件设计的，比如xfs/extx、Lustre、GlusterFS、GPFS、ISLION、GFS、HDFS，在元数据管理、数据布局i、条带设计、缓存管理等实现策略上都侧重大文件，而海量小文件应用在性能和存储效率方面要大幅下降，甚至无法工作。

针对LOSF问题，出现一些勇敢的挑战者。

• ext4主要针对ext3进行了两方面的优化：一是inode预分配，这使得inode具有很好的局部性特征，同一目录文件inode尽量放在一起，加速了目录寻址与操作性能。因此在小文件应用方面也具有很好的性能表现。二是extent/delay/multi的数据块分配策略，这些策略使得大文件的数据块保持连续存储在磁盘上，数据寻址次数大大减少，显著提高I/O吞吐量。因此，EXT4对于大小文件综合性能表现比较均衡。
• Reiserfs对小文件作了优化，并使用B* tree组织数据，加速了数据寻址，大大降低了open/create/delete/close等系统调用开销。Reiserfs的tail package功能可以对一些小文件不分配inode，而是将这些文件打包，存放在同一个磁盘分块中。对于小于1KB的小文件，Rerserfs可以将数据直接存储在inode中。因此， Reiserfs在小文件存储的性能和效率上表现非常出色。
• Facebook 推出了专门针对海量小文件的文件系统Haystack，通过多个逻辑文件共享同一个物理文件、增加缓存层、部分元数据加载到内存等方式有效的解决了Facebook海量图片存储问题。
• 淘宝推出了类似的文件系统TFS(Tao File System)，通过将小文件合并成大文件、文件名隐含部分元数据等方式实现了海量小文件的高效存储。
• FastDFS针对小文件的优化类似于TFS。
• 国防科学技术大学对Lustre进行了小文件优化工作，在OST组件中设计并实现了一种分布独立式的小文件Cache结构：Filter Cache，通过扩展Lustre的OST端的数据通路，在原有数据通路的基础上，增加对小对象I/O的缓存措施，以此来改善Lustre性能。

对于LOSF而言，IOPS/OPS是关键性能衡量指标，造成性能和存储效率低下的主要原因包括：

从理论分析以及上面LOSF优化实践来看，优化应该从元数据管理、缓存机制、合并小文件等方面展开，而且优化是一个系统工程，结合硬件、软件，从多个层面同时着手，优化效果会更显著。

请参考http://www.suse.de/~aj/linux_lfs.html

目前正在开发的最重要的 Linux 文件系统是ext4，它是专门为 Linux 开发的原始的扩展文件系统(ext 或 extfs)的第四版。由于继承了以前版本，ext4 在不久的将来很可能会成为一个重要的 Linux 标准文件系统(可能是标准文件系统)。

高性能文件系统，比如PanFS、Sun QFS、Quantum StorNext、IBM GPFS和HP File Services，可以为存储实施带来很大的好处。

以DigitalFilm Tree为例子，这家公司位于好莱坞，为娱乐业提供后期处理和视觉特效（VFX）服务。它最近必须对它的系统进行改进，以便处理如下影视的视觉特效：Showtime出品的《单身毒妈（Weeds）》，CW出品的《人人都恨克里斯》，NBC出品的《实习医生风云（Scrubs）》，以及李连杰的电影《功夫之王》。

在该公司所使用的存储系统中，有苹果的Xsan和惠普的StorageWorks阵列、QLogic的交换机，以及其他几家存储厂商的设备。该公司同时还使用了几种不同操作系统，工作人员使用的是苹果机和普通个人电脑。

DigitalFilm Tree的创始人兼首席执行官Ramy Katrib 说：“我们电视制作工作需要速度，因此工作流是非线性的，而且我们还要管理好多达100TB的数据。StorNext文件系统极大地提升了我们的工作速度，而且我们还不需要增加很多员工。”

但是随着文件系统协议逐渐升级到NFS（网络文件系统），以及并行式NFS（pNFS），NFS是否有可能最终取代其他的专有文件系统？在预测未来发展方向之前，让我们先来看看Sun和NetApp的另外两个高性能文件系统。

Sun微系统公司把Lustre文件系统描述成“世界上最具有可扩展性的并行式文件系统”。在全球10大超级计算机中，有6个使用这个文件系统，而在前100的超级计算机中，使用该文件系统的比例也达到了40%。

Sun Lustre部门主管Peter Bojanic表示：“通过Lustre文件系统，用户可以在一致的命名空间内将容量扩展到PB级，而且还可以为2.5万个以上的客户端提供超过100GB/秒的速度。Lustre的用户已经包括Livermore超级计算机、橡树岭国家实验室、Sandia国家实验室等。对于这些单位来说，大型文件I/O和稳定的高带宽都是非常重要的。”

Lustre文件系统还在石油和天然气、富媒体、内容发布网络等领域得到了推广，这些领域都需要处理包含大文件和小文件的混合工作负荷。

Lustre的一个特色就是它可以在Linux操作系统中作为开源式软件来使用。这也就是为什么Lustre文件系统会和其他HPC（高性能计算）厂商的存储产品整合在一起的缘故，这些HPC厂商包括SGI、戴尔、惠普、Cray和Terascala。

Lustre是一个基于对象的集群式文件系统，它的对象是水平地分布于各个服务器。这就需要一个Lustre MetaData Server（元文件服务器）和数个Lustre Object Storage Servers（对象存储服务器）。文件操作可以绕过元文件服务器，并使用并行的数据路径与集群中的对象服务器相连接。服务器采用了故障备份替换式布置。它可以在多种网络上运行，包括IP网络和InfiniBand。

NetApp有一个名为WAFL（任意位置写入文件布局）的文件系统。这个文件系统整合了CIFS（通用互联网文件系统）协议、NFS（网络文件系统）协议、HTTP协议、FTP协议、光纤通道协议和iSCSI（互联网小型计算机系统接口）协议，并可以在NetApp的Data ONTAP操作系统下工作。WAFL整合了RAID-DP（独立磁盘冗余阵列－双校验码）。RAID-DP是NetApp所推出的RAID-6的高性能版本。通过RAID-DP，即使两个硬盘同时故障，WAFL也不会损失数据。

WAFL采用了非易失性内存（NVRAM），允许一个存储访问协议目标端在数据写入磁盘之前就对访问请求做出回应，从而提高了访问速度。在WAFL文件系统下，访问请求被记录到NVRAM，而文件系统的修改则被保存在了易失性内存中。在易失性内存写满之后，WAFL会将结果写到 “一致点”（基本上是一个快照），并将一致点写到文件系统所配置的RAID组。

“如果在硬件或软件发生故障之前，一致点没有被写入磁盘，那么在Data ONTAP重启后，NVRAM的日志内容就会指导WAFL做相应的操作，并将一致点写入磁盘”，NetApp NFS部门的高级技术总监Michael Eisler说，“NetApp大部分竞争对手都有快照功能，但是NetApp使用自己的快照技术构建了多种功能，比如文件系统层镜像、备份整合、复制、重复数据删除、数据保留、跨网络存储设备的数据条带分割以及灵活卷等。”

灵活卷（FlexVol）是一种可以和其他灵活卷共享存储池的卷。这种卷可以根据需要随时扩展或收缩——被释放出来的空间则返回到存储池，以便被其他灵活卷所使用。

一种名为BTRFS(Better FS)的文件系统被Oracle的工程师开发团队所研制出来，并在未来可能会取代Ext3文件系统。

导读：

1. http://www.ibm.com/developerworks/cn/linux/l-cn-btrfs/?ca=drs-tp4608
2. http://www.inanu.net/post/393.html
3. Btrfs应用笔记
4. 利用 Snapper 实现 btrfs 自动定时备份

关键词： BTRFS Linux Ext3 文件系统

每一个操作系统的核心都是文件系统，文件系统提供了对数据读写的途径，自2001年开始，Ext3成为了主流的Linux文件系统（这个系统在Red Hat和Unbuntu等Linux版本都很常见），但是，现在看起来出现了一种更好的文件系统。

一种名为BTRFS（Better FS）的文件系统被Oracle的工程师Chris Mason领导的开发团队所研制出来，而得益于英特尔、Red Hat、惠普和IBM等多厂商的支持，BTRFS将成为新一代Linux文件系统的生力军。

“主要的目标就是扩展Linux系统的可用存储空间，”身为Oracle公司Linux核心的开发主管Chris Mason表示，“扩展并不仅仅是数据寻址的问题，而且还意味着对于管理员来说获得了能够更清晰管理数据的能力，还可以提高系统的可靠性。”除此以外，虽然现在硬盘驱动器的容量越来越大，但是驱动器上的错误率却并未改善。

“我们需要能够简单的了解磁盘什么时候出现错误信息，”Mason谈到，“而且我们需要能够做连续的文件系统的检查，并且以更稳定的方式恢复数据，”Mason认为，他所领导的小组已经做到了这一点。

对于目前的Ext3 Linux文件系统，扩展以满足大容量存储空间对用户来讲是一种挑战，而这其中有很多原因。

在诸多原因中的一点是，Ext3从最开始就不是为了企业和消费级桌面用户现在所创建的大型数据存储池所设计的，Mason认为，在Ext3系统中，每4k的数据就有一个元数据来指向4k数据在驱动器中的所在位置。所以，当文件容量变得越来越大，元数据也就越来越多，这样一来效率就很低。

“BTRFS使用了被称作extents的技术，这是一种将同一个初始位置的硬盘使用同一块磁盘位置的技术。”
extents方法比Ext3系统4k数据块指向的方法更高效、更具可扩展性，这也是新的Ext4文件系统（即将推出的2.6.28 Linux内核的组成部分）的一部分。虽然已经为Ext4已经增加了extents但是Mason仍然为BTRFS增加了一些其他的未来特性，比如说快照、在线的文件连续性检查，以及快速的增量备份。

“我们认为，BTRFS是一种具有成为下一代主流Linux文件系统的潜力的文件系统。”Red Hat公司的Ric Wheeler。

他表示，现在Red Hat的工程师正在积极的考查这个项目，而英特尔公司也对此感兴趣，英特尔公司开源技术中心主管Imad Sousou表示英特尔公司对BTRFS很感兴趣，并且正在积极支持其开发。

英特尔公司认为，BTRFS是一项很优秀的技术，有能力作为解决Linux文件系统的架构升级替代品，并支持未来性能和容错等方面的需求。

惠普公司也成为了这其中的关键厂商，很可能在其传统的UNIX系统，如HP-UX中加入BTRFS。

“惠普现在对BTRFS很感兴趣，因为他的目标是提供一个与惠普现在已经有的Tru64 AdvFS的内核相似的核心，以及其他的具有未来特性的系统。”惠普开源和Linux部门首席技术官Bdale Garbee表示

#snapper -c snap_mysql create-config /mnt
# /etc/snapper/configs/snap_mysql 

#snapper list-configs
Config     | Subvolume
-----------+----------
snap_mysql | /mnt     

#snapper -c snap_mysql create --description=sql-201909212300 -p
#snapper -c snap_mysql status 1..3

# snapper -c snap_mysql diff 1..2
--- /mnt/.snapshots/1/snapshot/adjust_centos7.sh        2018-03-08 02:17:57.543261000 +0800
+++ /mnt/.snapshots/2/snapshot/adjust_centos7.sh        2019-09-21 23:38:35.972336658 +0800
@@ -9,7 +9,6 @@
 echo -e 'nameserver 192.168.12.10\nnameserver 192.168.21.20\nnameserver 114.114.114.114' > /etc/resolv.conf
 
 set enforce 0
-exit
 sed -r -i  '/^SELINUX=/s^=.*^=disabled^g' /etc/selinux/config
 sed -r -i '/^[^root]/s:/bin/bash:/sbin/nologin:g' /etc/passwd
 sed -r -i '/#Port 22/s^.*^Port 65422^g;/^PasswordAuthentication/s^yes^no^g' /etc/ssh/sshd_config

# snapper -c snap_mysql diff 1..3 /mnt/adjust_centos7.sh
#systemctl start snapper-cleanup.timer ; systemctl enable snapper-cleanup.timer 
#systemctl start snapper-timeline.timer ; systemctl enable snapper-timeline.timer 

SquashFS是一个即时解压缩的档案系统，如同Cloop、CramFS一般。只是，SquashFS的压缩比更高、速度更快，又不像CramFS有单一档案大小或整体档案系统大小的限制，在LiveCD的应用上非常有用。

这里有人写了评比，我摘一小段下来：

5.1 Ubuntu liveCD compression results

ext3 uncompressed size 1.4 GB 
ISO9660 uncompressed size 1.3 GB 
Zisofs compressed size 589.81 MB 
Cloop compressed size 471.89 MB 
Squashfs2.0 compressed size 448.58 MB 
Squashfs2.1 compressed size 448.58 MB 

5.2 Damn Small Linux liveCD compression results

ext3 uncompressed size 126 MB 
CRAMFS compressed size 52.19 MB 
Squashfs2.0 compressed size 46.52 MB 
Squashfs2.1 compressed size 46.52 MB 

那种东西压到剩原来的 30~40 % 大小。通常 LiveCD 上面这种空间非常要求的东西，有这个帮忙真是不赖。

同时也提到squashfs + lzma 组合是最好的。

squashfs default use gzip, but you can try to patch it to use lzma, of course you have to change mksquashfs to use lzma too.

看起来是 lzma 最小了，不过不知道在「即时读取」的时候会不会慢到？

PS:

1. squashfs 在 去年的时候还没进到 kernel 2.6 裡面，但是现在 Ubuntu 6.10 的 kernel 已经到了 2.6.17-50-generic ，所以就直接下 modprobe squashfs 就可以用了。
2. Linux Kernel 2.6.29 RC 1 发布，加入 Btrfs 和 Squashfs 文件系统

1. 把三国志(是陈寿写的文言本啦)文档压成 dir.sqsh 档 mksquashfs /home/anton/三国志/ dir.sqsh
2. 用 loop device 挂载 dir.sqsh 上来。 mount /home/anton/html dir.sqsh -o loop

http://www.sun.com/bigadmin/hubs/multilingual/simp_chinese/content/zfs-whatis.jsp

Sun Microsystems公司正式发布的ZFS（Zettabyte File System）文件系统是第一个128位的文件系统，同时ZFS又被Sun Microsystems称作史上最后一个文件系统。因为这个文件系统含有多项创新技术，不仅成功地解决现有文件系统的问题和陋习，而且前瞻性地考量了未来对存储空间的需求，单个文件系统可以达到256 quadrillion（264） Zettabytes（221）。

ZFS不仅符合POSIX文件系统的标准，而且提供了许多高级功能比如：Quota(配额)，Reservation(预留), Compression(压缩)， Snapshot(快照)，Clone（克隆）等。如果你还在坚持使用现有32位或者64位的文件系统，如果你还在“痛并不快乐着”地用着各式各样的 Volume Manager，那就很值得看看这里列出的使用ZFS的十条理由。

不管你是在用Linux，UNIX还是Windows，相信大家都有过类似的体会：当系统意外断电或者非法关机，系统重起后发现文件系统有inconsistent的问题，这时候就需要fsck或者scandisk 来修复，这段时间是非常耗时而且最后不一定能够修复成功。更糟糕的是，如果这是一台服务器需要做fsck的时候，只能offline（下线），而且现有应用往往都是大硬盘，相应fsck修复时间也很长，这对许多使用该服务器的用户来说几乎不能忍受的。

使用ZFS后大家可以彻底抛弃fsck这种工具，因为ZFS是一个基于COW（Copy on Write）机制的文件系统。COW是不会对硬盘上现有的文件进行重写，保证所有硬盘上的文件都是有效的。所以不会有这种inconsistent的概念，自然就不需要这种工具了。

ZFS作为一个全新的文件系统，全面抛弃传统File System + Volume Manager + Storage的架构，所有的存储设备是通过"ZFS Pool"进行管理，只要把各种存储设备加入同一个ZFS Pool，大家就可以轻松的在这个ZFS Pool管理配置文件系统。大家再也不用牢记各种专业概念，各种命令newfs, metinit及各种Volume Manager的用法。

在ZFS中我们只需要两个命令，zpool(针对ZFS Pool管理)和zfs(针对ZFS文件系统的管理)，就可以轻松管理128位的文件系统。举个例子，我们经常会遇到系统数据增长过快，现有存储容量不够，需要添加硬盘，如果依照传统的Volume Manager管理方式，那我们需要预先要考虑很多现有因素，还要预先根据应用计算出需要配置的各种参数。在ZFS情况下，我们的系统管理员可以彻底解放，再也不需要这种人为的复杂 考虑和计算，我们可以把这些交给ZFS，因为ZFS Pool会自动调节，动态适应需求。

我们只需一个简单的命令为 这个ZFS Pool加入新的硬盘就可以了

zpool add zfs_pool mirror c4t0d0 c5t0d0

基于这个动态调节的ZFS Pool之上的所有的文件系统就可以立即使用到这个新的硬盘，并且会自动的选择最优化的参数,而且ZFS同时也提供图形化的管理界面。

下面是一个ZFS图形化管理的一个截屏：

ZFS（Zettabyte File System）文件系统就如其名字所预示，可以提供真正的海量存储，在现实中几乎不可能遇到容量问题。在现有的64位kernel(内核)下，它可以容纳达到16 Exabytes(264)大小的单个文件，可以使用264个存储设备，可以创建264个文件系统。

由于ZFS所有的数据操作都是基于Transaction（事务），一组相应的操作会被ZFS解 析为一个事务操作，事务的操作就代表着一组操作要么一起失败，要么一起成功。而且如前所说，ZFS对 所有的操作是基于COW（Copy on Write）， 从而保证设备上的数据始终都是有效的，再也不会因为系统崩溃或者意外掉电导致数据文件的inconsistent。

还有一种潜在威胁数据的可能是来自于硬件设备的问题，比如磁盘，RAID卡的硬件问题或者驱动bug。现有文件系统通常遇到这个问题，往往只是简单的把错误数据直接交给上层应用，通常我们把这个问题称作Silent Data Corruption。而在ZFS中，对所有数据不管是用户数据还是文件系统自身的metadata数据都进行256位的Checksum(校验)，当ZFS在提交数据时会进行校验，彻底杜绝这种Silent Data Corruption情况。

和传统File System + Volume Manager + Storage架构不同，ZFS则是直接基于存储设备提供所有的功能，因此有自己独有的创新特性，性能自然非比寻常。

Dynamic Striping vs. Static Striping

由于ZFS是基于COW和一个全局动态的ZFS Pool，任何一次写操作，都是对一块新数据块（Block）的一次写操作。ZFS从ZFS Pool中动态挑选出一个最优的设备，并且以一个transaction（事务）线性写入，充分有效地利用了现有设备的带宽，我们把这个特性称为Dynamic Striping。而相对应的Static Striping则是传统文件系统所使用的方式，Static Striping需要管理员预先对这组Stripe进行正确地计算人为设置，而且如果加入新的设备则需要再次人为的计算和设置，更为严重的是如果人为计算错误，则会直接影响系统的性能。而在使用Dynamic Striping这种特性之后，我们根本不需要人为介入，ZFS会自动调整，智能的为你提供最佳的设备，最快的操作方式。

ZFS支持多种大小的数据块定义，从512字节到1M字节。和传统文件系统往往都是固定大小数据块不同，ZFS则是可以动态的根据不同大小的文件进行计算，动态的选择最佳的数据块。

因为不同大小数据块，直接影响到实际使用硬盘容量和读取速度。如果使用较小的数据块，存储文件所导致的碎片则较少，读写小文件更快一些，但是会导致需要创建更多的metadata，读写大文件则会更费时。如果使用较大的数据块，使用的metadata较少，更利于读写大文件，但是会导致更多的碎片。ZFS根据实际调查现有文件使用的情况，分析出一个选择数据块大小的算法，动态的根据实际文件大小确定最佳的数据块。所以ZFS是非常智能的，在不需要系统管理员介入，就可以得到一个自我调优的结果。当然ZFS也支持用户对单个文件或者整个文件系统所使用的数据块大小的自定义设置。

多数的操作系统都有这种将数据预先读取的功能，而ZFS则是建立在文件系统上直接提供的一种更加智能的数据预读取功能。它不仅可以智能地识别出多种读取模式，进行提前读取数据，而且可以对每个读取数据流进行这种预读取智能识别，这个对许多流媒体提供者来说是件非常好的事情。

在扩展性上，和现有文件系统多是基于一个受限的静态模型不同，ZFS是采用ZFS Pool这个动态概念，它的metadata也是动态，并且读写操作都是可并行的，并且具有优先级概念，所以即使在大数据量，多设备的情况下仍可以保证性能的线性增长。

ZFS Mirror 和 RAID-Z

传统的硬盘Mirror及RAID 4，RAID 5阵列方式都会遇到前面提到过的问题：Silent Data Corruption。如果发生了某块硬盘物理问题导致数据错误，现有的Mirror，包括RAID 4，RAID 5阵列会默默地把这个错误数据提交给上层应用。如果这个错误发生在Metadata中，则会直接导致系统的Panic。 而且还有一种更为严重的情况是：在RAID 4和RAID 5阵列中，如果系统正在计算Parity数值，并再次写入新数据和新Parity值的时候发生断电，那么整个阵列的所有存储的数据都毫无意义了。

在ZFS中则提出了相对应的ZFS Mirror和RAID-Z方式，它在负责读取数据的时候会自动和256位校验码进行校验，会主动发现这种Silent Data Corruption，然后通过相应的Mirror硬 盘或者通过RAID-Z阵列中其他硬盘得到正确的数据返回给上层应用，并且同时自动修复原硬盘的Data Corruption 。

在Solaris 10中，包含一个ZFS诊断引擎和Solaris的 Fault Manager（这也是Solaris 10的 另一个新特性）交互，可以实时地诊断分析并且报告ZFS Pool和存储设备的错误，用户可以通过Fault Manager及时得到一个非常友善的消息。这个诊断引擎虽然不会采取主动的行为去修复或者解决问题，但是会在消息中提示系统管理员可采取的动作。

类似下面一个ZFS报错消息，其中REC-ACTION就是建议采取的动作：

 
SUNW-MSG-ID: ZFS-8000-D3, TYPE: Fault, VER: 1, SEVERITY: Major
EVENT-TIME: Fri Mar 10 11:09:06 MST 2006
PLATFORM: SUNW,Ultra-60, CSN: -, HOSTNAME: neo
SOURCE: zfs-diagnosis, REV: 1.0
EVENT-ID: b55ee13b-cd74-4dff-8aff-ad575c372ef8
DESC: A ZFS device failed. Refer to http://sun.com/msg/ZFS-8000-D3 for more information.
AUTO-RESPONSE: No automated response will occur.
IMPACT: Fault tolerance of the pool maybe compromised.
REC-ACTION: Run ’zpool status -x’ and replace the bad device. 

在安全上，ZFS支持类似NT风格NFSv4版的ACL（读取控制列表）。而且前面所提到的256位验证码，用户可选择多种验证方式，包括SHA-256验证算法，从而在物理存储单元级别上保证数据的安全性。

ZFS作为“最后一个文件系统”，涵盖了基本的文件系统和Volume管理的功能，同时一并提供许多企业级别的超强功能：Quota(配额)，Reservation(预留), Compression(压缩)， Snapshot(快照)，Clone（克隆）。并且速度非常快。有了这个文件系统，大家再也不需要任何Volume Manager了。

ZFS是一个完全兼容POSIX规范的文件系统，所以处于上层的应用程序是完全不受影响。ZFS也提供一个Emulated Volume模块，可以把任何一个ZFS文件系统作为普通的块设备使用。同时ZFS也可以使用基于Volume Manager构建的Volume作为存储设备单 元。这样在不需要修改应用程序，不修改已有文件系统下，给了大家最大的自由度去获得ZFS提供的各种特性。

ZFS是Sun Microsystems公司作为OpenSolaris的一个开源项目运作并且完全免费使用，点击这里(http://www.opensolaris.org/os/community/zfs/source/) 可以直接浏览到ZFS的代码。这就代表着我们不仅同时可以享受商业公司的高质量，也可以获得开源模式的优点。

虽然目前只有Solaris支持该文件系统，但是这种开源的模式必定会促进更多基于ZFS的应用。现在已经有国外开发者正在将ZFS移植到Linux和Mac OS上来。如果想要体验一下ZFS，由于目前它和Solaris 10绑定在一起，所以需要下载最新版的Solaris 10 06/06/11版本。

1. 需要存储大量的共享资料时;
2. 多台主机频繁访问共享资料时;

最常见就是利用NFS协议。但这种方式存在几个致命的缺点：

1. NFS是种协议，并不是文件系统，因此仍然受到底层文件系统性能的约束
2. NFS server在一对多(>20个)客户端连接的时候，经常会timeout,性能低下
3. 基于RPC的设计，需要增加额外的安全方面的考虑

针对NFS这种多对一的架构，我们需要改变架构来提高共享文件的性能。提高性能的思路有两种：

1. 多对多的架构，如采用分布式的文件系统(Hadoop,MFS,Mogilefs)
2. 多对一的架构，但是避开NFS协议，采用FC,ISCSI,AoE专用协议实现块操作，配合集群文件系统(GFS,OCFS2)实现多机读写

• Moosefs
• MogileFS 需要Mysql
• GlusterFS
• Google File System
• Apache Cassandra Facebook正在使用

• Redhat GFS
• Oracle OCFS2
• Lustre 属于Sun的项目，前途不明朗

• http://www.bsdmap.com/2008/09/13/dfs/

Mogilefs 的网站

mogileFS是一个分布式文件存储的解决方案，他由Six Apart开发下面列出了他的一些特性

• 应用层——不需要特殊的核心组件
• 无单点失败——MogileFS安装的三个组件（存储节点、跟踪器、跟踪用的数据库），均可运行在多个机器上，因此没有单点失败。（你也可以将跟踪器和存储节点运行在同一台机器上，这样你就没有必要用4台机器）推荐至少两台机器。
• 自动的文件复制——基于不同的文件“分类”，文件可以被自动的复制到多个有足够存储空间的存储节点上，这样可以满足这个“类别”的最少复制要求。比如你有一个图片网站，你可以设置原始的JPEG图片需要复制至少三份，但实际只有1or2份拷贝，如果丢失了数据，那么Mogile可以重新建立遗失的拷贝数。用这种办法，MogileFS(不做RAID)可以节约磁盘，否则你将存储同样的拷贝多份，完全没有必要。
• “比RAID好多了”——在一个非存储区域网络的RAID（non-SAN RAID）的建立中，磁盘是冗余的，但主机不是，如果你整个机器坏了，那么文件也将不能访问。 MogileFS在不同的机器之间进行文件复制，因此文件始终是可用的。
• 传输中立，无特殊协议——MogileFS客户端可以通过NFS或HTTP来和MogileFS的存储节点来通信，但首先需要告知跟踪器一下。
• 简单的命名空间——文件通过一个给定的key来确定，是一个全局的命名空间。你可以自己生成多个命名空间，只要你愿意，不过这样可能在同一MogileFS中会造成key冲突。
• 不用共享任何东西——MogileFS不需要依靠昂贵的SAN来共享磁盘，每个机器只用维护好自己的磁盘。
• 不需要RAID——在MogileFS中的磁盘可以是做了RAID的也可以是没有，如果是为了安全性着想的话RAID没有必要买了，因为MogileFS已经提供了。
• 不会碰到文件系统本身的不可知情况——在MogileFS中的存储节点的磁盘可以被格式化成多种格式（ext3,reiserFS等等）。MogilesFS会做自己内部目录的哈希，所以它不会碰到文件系统本身的一些限制，比如一个目录中的最大文件数。你可以放心的使用。

• http://www.capoune.net/mogilefs/

提供了一个php扩展用来在php中使用mogileFS。这儿也有一个地址，svn的源码库 http://svn.usrportage.de/php-mogilefs/trunk/

• http://durrett.net/mogilefs_setup.html

这儿有一个兄弟的中文安装学习笔记 mogileFS学习

你可以用mogdbsetup程序来初始化数据库。数据库保存了Mogilefs的所有元数据，你可以单独拿数据库服务器来做，也可以跟其他程序跑在一起，数据库部分非常重要，类似邮件系统的认证中心那么重要，如果这儿挂了，那么整个Mogilefs将处于不可用状态。因此最好是HA结构。

mogstored程序的启动将使本机成为一个存储节点。启动时默认去读/etc/mogilefs/mogstored.conf ，具体配置可以参考配置部分。mogstored启动后，便可以通过mogadm增加这台机器到cluster中。一台机器可以只运行一个mogstored作为存储节点即可，也可以同时运行其他程序。

mogilefsd即trackers程序，类似mogilefs的wiki上介绍的，trackers做了很多工作，Replication ，Deletion，Query，Reaper，Monitor等等。mogadm,mogtool的所有操作都要跟trackers打交道，Client的一些操作也需要定义好trackers，因此最好同时运行多个trackers来做负载均衡。trackers也可以只运行在一台机器上，也可以跟其他程序运行在一起，只要你配置好他的配置文件即可，默认在/etc/mogilefs/mogilefsd.conf。

主要就是mogadm，mogtool这两个工具了，用来在命令行下控制整个mogilefs系统以及查看状态等等。

Client实际上是一个Perl的pm，可以写程序调用该pm来使用mogilefs系统，对整个系统进行读写操作。

MogileFS采用了离散存储，将一个文件离散方式存储在多个节点上，不同节点上的文件存储量不一定一样，便于存储节点的扩展，同时也有效避免了单点失败的问题。

而FastDFS可以认为是镜像存储，同组存储节点上存储的文件是相同的，以后一个存储节点空间不够的时候只能采用同步的存储空间扩容替代升级，不能像MogileFS那样只通过添加新节点扩展整体的存储容量。

相对觉得 FastDFS 应该和 GlusterFS 比较，分组镜像存储，但是 GlusterFS 更好，采用类似nfs那样的文件系统方式，有RAID那种条带功能，可以很好的提升文件的存取速度。

MogileFS不支持对一个文件的随机读写，因此注定了只适合做一部分应用，就是静态存储（那种一次保存，多次读取型的资源）。比如以html方式静态化处理的动态文件，图片文件，只提供下载的文件等。

扩展文件系统（ext 或 extfs）第四版产生的原因是开发人员在 ext3 中并入了新的高级功能。但在实现的过程出现了几个问题：

• 一些新功能违背向后兼容性。

  • Ext3 代码变得更加复杂并难以维护。
  • 这些更改使原本十分可靠的 ext3 变得不可靠。

  由于这些原因，从 2006 年 6 月份开始，开发人员决定把 ext4 从 ext3 中分离出来进行独立开发。Ext4 的开发工作从那时起开始进行，但大部分 Linux 用户和管理员都不怎么注意这件事情。随着 2.6.19 内核在 2006 年 11 月的发布，ext4 第一次出现在主流内核里，但是它当时还处于试验阶段（现在还是），因此很多人都忽视了它。

由于还处于开发阶段，从 2.6.24.4 内核开始，ext4 的功能列表就一直在变动。 Ext4 的当前和预期功能包括从 ext3 发展而来的功能，见表 1。

表 1. Ext4 的当前功能和未来功能使它超越了 ext3

Ext4 最为显著的改进是文件和文件系统的大小。因此，最可能需要 ext4 的用户是那些磁盘空间大小为几个 TB 的用户。然而表 1 中的功能列表还展示了其他一些吸引人的改进。例如，如果您的目录带有大量子目录，或者要求时间戳的精确度小于一秒，您可能希望尝试使用 ext4。

因为 ext4 目前处于试验阶段，要使用它就必须重新编译内核，否则，使用 ext4 时将会出现麻烦。事实上，ext4 处于试验阶段意味着只有希望为 ext4 的开发做贡献，或者非常渴望它的某些功能，这些情况下才有必要使用它。如果想在稳定的 ext4 发布之前获得可靠的大磁盘支持，可以考虑使用 XFS 或 JFS。

当然，ext4 不可能永远处于试验阶段。它不久将成为一个稳定的文件系统。届时，ext4 将像 ext3 一样成为所有用户的最佳选择，但需要注意几个问题。首先，ext4 还存在一些独有的 bug，因此当首次发行 ext4 稳定版时要多加注意。其次，使用 ext4 可能导致一些老版本的工具无法访问磁盘。这将涉及到紧急恢复工具，因此在确定您使用的工具支持 ext4 之前不要进行更新。好的一面是，应该可以从 ext3 顺利迁移到 ext4，如果需要保存现有数据，这将实现轻松的转移。

• http://www.ibm.com/developerworks/cn/linux/l-ext4/index.html
• http://linuxtoy.org/archives/ext4-benchmarks.html
• http://blog.csdn.net/nhczp/archive/2007/09/04/1771897.aspx
• http://blog.csdn.net/nhczp/archive/2007/09/06/1774447.aspx

• Cluster Technology and File Systems
• 分布式、集群文件系统小结

MooseFS 很不错，已经实用了半月了，易用，稳定，对小文件很高效。

MogileFS 据说对于 Web 2.0 应用存储图片啥的很好。

GlusterFS 感觉广告宣传做的比产品本身好。

OpenAFS/Coda 是很有特色的东西。

Lustre 复杂，高效，适合大型集群。

PVFS2 搭配定制应用会很好，据说曙光的并行文件系统就是基于 PVFS。

适合做通用文件系统的有 MooseFS，GlusterFS，Lustre。

1. 依赖 PostgreSQL

• 服务端是 Java 实现的 - 性能不高

1. 被 Hadoop 作为分布式文件系统后端之一
2. 不支持文件元信息
3. kfs_fuse 太慢，不可用
4. 编译依赖多，文档落后，脚本简陋
5. 开发不活跃

1. 支持文件元信息
2. mfsmount 很好用
3. 编译依赖少，文档全，默认配置很好
4. mfshdd.cfg 加 * 的条目会被转移到其它 chunk server，以便此 chunk server 安全退出
5. 不要求 chunk server 使用的文件系统格式以及容量一致
6. 开发很活跃
7. 可以以非 root 用户身份运行
8. 可以在线扩容
9. 支持回收站
10. 支持快照
11. master server 存在单点故障
12. master server 很耗内存

1. 不适合做通用文件系统，适合存储静态只读小文件，比如图片

• GlusterFS集群文件系统研究
• GlusterFS快速入门及概述
• GlusterFS技术详解
• Setting Up GlusterFS Client

1. 无单点故障问题
2. 支持回收站
3. 模块化堆叠式架构
4. 对文件系统格式有要求，ext3/ext4/zfs 被正式支持，xfs/jfs 可能可以，reiserfs 经测试可以 (系统需求)
5. 需要以 root 用户身份运行（用了 trusted xattr，mount 时加 user_xattr 选项是没用的，官方说法是glusterfsd 需要创建不同属主的文件，所以必需 root 权限)
6. 不能在线扩容(不 umount 时增加存储节点)，计划在 3.1 里实现
7. 分布存储以文件为单位，条带化分布存储不成熟

gluster volume create MySQL_Backup stripe 2 replica 2 transport tcp \
EBS-SAD-00{1,2,3,4}:/disk/sata{1,2}/mysql_backup \
force

#!/bin/sh
VOL="MySQL_Backup"

gluster volume set $VOL performance.cache-size 4GB
gluster volume set $VOL performance.flush-behind on
gluster volume set $VOL performance.write-behind on
gluster volume set $VOL performance.read-ahead on
gluster volume set $VOL performance.io-thread-count 32                                                             

• Gluster performance testing

iozone -w -c -e -i 0 -+n -C -r 64k -s 1g -t 8 -F /mnt/f{0..31}.ioz

从一定程度上讲，GlusterFS的性能依赖于硬件基础设施，主要涉及服务器、CPU、内存、磁盘、网络等部件，硬件性能直接决定着系统理论上的最大性能。当性能不能满足应用需求时，我们应当首先分析是否硬件配置是否足够。如果硬件配置存在明显问题，可以直接通过升级硬件配置来直接提升性能，比如更多更高性能的CPU，更多的内存，更多或更快的磁盘，更多的网络接口或更快的网络。

通常情况下，系统缺省的参数设置是为了适应更多的应用负载，但性能往往不是最优的，比如I/O调度算法、Cache参数、进程调度亲和度、磁盘文件系统参数、mount参数、网络通信参数等。可以针对具体的应用特征，基于理论分析和实验测试，对这些参数进行个性化配置，以获得更高的性能提升。

Gluster的底层核心是GlusterFS分布式文件系统，为了满足不同的应用负载需求，它提供了许多可调节的系统参数，其中与性能调优相关的主要参数包括：

• 设置全局Cache-Size，缺省值32MB → 256MB
• 每文件Write-Cache-Size，缺省值1MB
• 条带大小，缺省值128KB

开启 指定 volume 的配额： (models 为 volume 名称)

gluster volume quota models enable

限制 models 中 / (既总目录) 最大使用 80GB 空间

gluster volume quota models limit-usage / 80GB

设置 cache 4GB

gluster volume set models performance.cache-size 4GB

开启 异步 ， 后台操作

gluster volume set models performance.flush-behind on

设置 io 线程 32

gluster volume set models performance.io-thread-count 32

设置 回写 (写数据时间，先写入缓存内，再写入硬盘)

gluster volume set models performance.write-behind on
gluster volume set models performance.read-ahead on

• 内核3.10 vs 4.14 ( base gluster 3.12)
• 网卡bonding mode=2 xtr=0（0,1,2,3）
• 集群服务器时间同步
• gluster volume stripe 4 replica 2 / stripe 4 replica 3

1. GFS 的 Oracle 翻版，据说性能比 GFS2 好 (Debian: aptitude install ocfs2-tools, 图形配置工具包 ocfs2console)
2. 不支持 ACL、flock，只是为了 Oracle database 设计

1. 成熟稳定
2. 开发活跃，支持 Unix/Linux/MacOS X/Windows
3. 性能不够好

1. 从服务器复制文件到本地，文件读写是本地操作因此很高效
2. 文件关闭后发送到服务器
3. 支持离线操作，连线后再同步到服务器上
4. 缓存基于文件，不是基于数据块，打开文件时需要等待从服务器缓存到本地完毕
5. 并发写有版本冲突问题
6. 并发读有极大的延迟，需要等某个 client 关闭文件，比如不适合 tail -f some.log
7. 研究项目，不够成熟，使用不广

http://blog.csdn.net/yfw418/archive/2007/07/06/1680930.aspx

1. 高性能
2. 没有锁机制，不符合 POSIX 语意，需要应用的配合，不适合做通用文件系统
3. 静态配置，不能动态扩展

1. 适合大型集群
2. 很高性能
3. 支持动态扩展
4. 需要对内核打补丁，深度依赖 Linux 内核和 ext3 文件系统

1. 本地写缓存，够一定大小 (64 MB) 时传给服务器
2. 不适合通用文件系统

1. 只能通过 API 使用，不支持 fuse

1. 简单
2. 没有负载均衡，容错

1. 没有普及

1. pNFS 在 Linux 上的一个实现

1. 开发初期，不稳定 kernel > 2.6.34,建议用 3.x系列内核
2. 依赖 btrfs、xfs
3. Ceph：一个 Linux PB 级分布式文件系统
4. Ceph: A Scalable, High-Performance Distributed File System

1. BeeGFS is a high-performance parallel file system with easy management
2. Distributed Filesystems: BeeGFS vs Gluster

EXT4 兼容EXT3 文件系统 ，可以使用e2fsprogs 从EXT3 无缝迁移至EXT4。

EXT3 文件系统最大支持16TB 文件系统，单个文件最大2TB。
EXT4 使用48 位地址空间，最大支持1EB 文件系统，单个文件最大16TB 。
EXT3 最大子目录数为32768
EXT4 没有目录个数限制
由于在支持64位地址空间之前还有一些限制需要解决。因此暂时使用48位地址空间，
在将来，EXT4将会支持64位地址空间�

传统的unix衍生文件系统如EXT3 使用间接的block 映射架构记录已使用的block 及其对应的文件数据。
这种方式对大文件的操作非常低效，尤其在删除大文件的时候。因为映射表记录着每一个single block 的条目，
而大文件由许许多多的single block 组成，这就意味着它拥有一个巨大的block映射记录集合，因此处理起来非常的慢。
EXT4 使用一种称之为“extents” 的方法来处理数据。一个“extents”由一段连续的物理块组成，简单来说就是
数据存储在一段连续的blcok上,举个例子： 在存储一个100M 的文件在存储时，文件系统会为其分配一个大小为100MB,
连续的物理块“extents” ，而在ext3文件系统中存储100MB的数据，需要创建约25600个 block（每个block大小为 4KB） 的映射，
效率可想而知。
在EXT4文件系统中,超大的文件会被分割为若干的extents,由于extent是一段连续的物理块，
因此extents不仅可以有效的增强文件系统的性能而且还可以减少文件碎片。

当EXT3 文件系统需要向磁盘写入新的数据时，会由block allocator 方法 来分配新写入的数据需要占用多少空闲的磁盘空间。
但是 EXT3 的每次调用 block allocator 只能分配一个block(4KB),这意味着在前面的例子中，写入100MB 的数据，
需要执行25600次 block allocator 调用，这还仅仅是在100MB 的情况下。EXT3的 block allocator不仅是效率低下
它还无法优化block的 分配策略，因为它不会预先计算数据需要分配多少个block ，每次只分配1个block，直到满足为止。

EXT4 使用“multiblock allocator” 也叫（mballoc）的方法来为数据分配block,每次调用block allocator 可以分配
多个block,这样就避免了多次调用带来的开销，mballoc 与 extents 、delayed allocation 等EXT4 特性配合使用效果
更加明显，而且这些特性并不会影响磁盘格式。

Delayed allocation 是一个在流行文件系统中的常用特性， XFS,ZFS,btrfs 或者 Reiser 4 都用到它。

它尽可能的将需要进行分配的block 进行延时操作，而在传统文件系统中（例：EXT3 RESIER3）正好相反，传统文件系统
会尽可能快的将block分配出去。举个例子：在处理一个写操作时，传统文件系统会立刻将数据将要存放的block 分配出来，即使
数据是在CACHE中保留一段时间，并不需要立刻写入磁盘。这种方法有些缺点，在进程对一个文件进行连续不断的写操作时
连续的write()s立刻为文件分配block，但是由于它并不知道文件是否会增长，因此会不断的进行allocate调用导致开销过大。 而Delayed allocation则不同，当数据存在于cache中时，它并不会执行allocate操作，直到数据真正的药写入到磁盘时，它 才会进行 mballoc 调用，这样就减少了mballoc的调用时间间隔，使得mballoc 有时间进行分配策略的优化。 Delayed allocation 同 extents、mballoc 共同使用是非常好的选择，因为在很多应用中，数据都是一次性写入，配合extents,一次mballoc 调用就可以为数据分配完block.

Fsck 是一个非常慢的操作，尤其是第一步：检查文件系统的所有索引节点。 在EXT4中，在每张group's索引表的结尾将会存储未使用的索引节点信息列表（处于安全，带校验和），因此在Fsck 时，只需要对 已使用的索引节点进行检测，同EXT3比较通常可以将检查的效率提升10倍，具体取决于使用索引节点数，使用的索引节点数越多，
检测效率就会越低。 需要注意的是：第一使用必须先使用Fsck对未使用的索引节点创建列表。 u

journal 是磁盘非常有用的一部分，它可以将block 恢复到硬件损坏时的状态，但是从被顺坏的journal进行恢复会导致更严重的损失。
EXT4 通过对journal进行校验来确保journal的完整性，journal checksum还有个额外的好处，它可以将EXT3 文件系统的
journal two-phase 提交系统，转换为single-phase ,在某些情况下，这可以提升20%的操作效率。因此journal checksum 可以同时提高可靠性和性能。

注意：默认情况下EXT4的asynchronous logging 未被启用，在以后的版本将会启用这个特性，它能够进一步提高文件系统的可靠性。

journaling 通过记录在线磁盘的操作日志，来确保文件系统的完整性。然而， 它会带来一些开销，
有些特殊应用不需要通过文件系统的journal特性，在EXT4 中可以关闭journal特性，这样可以带来小幅度的性能提升。

在线磁盘碎片整理，这项功能正在开发中，将会在未来版本中使用。

 EXT3 的 inode 大小为 128 字节，EXT4 默认为256字节，多出来的部分用于存储时间戳，inode版本信息等。
 

 EXT4 支持预留索引节点的功能，例如当创建一个目录时，为其预留一部分索引节点用于将来使用，当在目录中创建新文件\\
 时就会使用这些预留的节点，文件的创建和检索会因此变的更有效率。
 

 EXT4使用纳秒（十亿分之一秒）级别的时间戳来取代EXT3 秒级别的时间戳。
 

EXT4 的这项特性允许上层应用为数据预先分配磁盘空间，它通过libc 的posix_fallocate 接口进行调用。

在RHEL 5.3 及其以后版本的内核都支持EXT4 文件系统，但是默认情况下RHEL 只支持EXT3文件系统。
要使用EXT4 文件系统，必须手动迁移。

1.安装 e4fsprogs 或者 tune2fs的1.43-1.4.10 版本。

    $ yum install -y e4fsprogs
    

2. 更新Grub。 Grub2-1.97 和 grub-0.97 中已经加入EXT4 支持
若Grub 符合上述要求，忽略这步。

1. 修改/etc/fstab . LABEL=/boot1 /boot ext3 defaults 1 2 改为 LABEL=/boot1 /boot ext4 defaults 1 2 4.开启ext4特性. 在boot分区上开启ext4特性，下面的例子中boot分区为 /dev/sda1.
   $umount /boot $tun4fs -O extents,uninitbg,dirindex /dev/sda1
   
   5.使用 tun4fsck 在线修复boot 分区. $ tun4fs -fDC0 /dev/sda1
   至此 boot分区已经转换为 ext4 。

   root 分区迁移

1.安装 e4fsprogs.或者 tune2fs的1.43-1.4.10 版本。

    $ yum install -y e4fsprogs
    

2.在initrd.img中添加ext4模块，否则启动时根分区无法挂载，出现kernel panic.

     
      $ mkinitrd -v --with ext4 -f /boot/initrd-`uname -r`.img  `uname -r`
      

3.修改grub 文件,在启动时以ext4 格式挂载根文件系统。

         kernel /vmlinuz-2.6.18-194.el5 ro root=/dev/VolGroup00/LogVol00  
         修改为：
         kernel /vmlinuz-2.6.18-194.el5 ro root=/dev/VolGroup00/LogVol00 rootfstype=ext4

4.修改/etc/fstab.

    /dev/VolGroup00/LogVol00             /                       ext3   defaults        1 1
    修改为
    /dev/VolGroup00/LogVol00                /                       ext4    defaults        1 1

5.在根分区开启ext4 特性。

 $ tun4fs -O extents,uninit_bg,dir_index /dev/VolGroup00/LogVol00
 

6.重启后修复文件系统。

 根分区不能使用fsck 在线修复。否则会造成无法修复的损坏。
 重启系统后 ，会出现一系列的文件系统错误，提示要求输入ROOT 的PASSWD 进入系统。 输入密码后进入系统后，使用fsck 修复文件系统。
 
 $ fsck -fDC0 /dev/VolGroup00/LogVol00 
 

7.修复文件系统后再次重启 ，根分区迁移至EXT4 成功。