转载自：
http://www.cnblogs.com/tommyli/p/3201047.html#top
http://blog.csdn.net/kickxxx/article/details/9612445
http://tetralet.luna.com.tw/index.php?op=ViewArticle&articleId=214&blogId=1
[root@steven ~]# uname -r
2.6.32-504.8.1.el6.x86_64
[root@steven ~]# cat /etc/redhat-release
CentOS release 6.6 (Final)
Linux kernel 自 2.6.28开始正式支持新的文件系统 Ext4。 Ext4 是 Ext3 的改进版，修改了 Ext3 中部分重要的数据结构，而不仅仅像 Ext3 对Ext2 那样，只是增加了一个日志功能而已。
Ext4 可以提供更佳的性能和可靠性，还有更为丰富的功能：
1. 在线升级到EXT4
与 Ext3 兼容。执行若干条命令，就能从 Ext3 在线迁移到 Ext4，而无须重新格式化磁盘或重新安装系统。原有 Ext3 数据结构照样保留，Ext4 作用于新数据。
当然，整个文件系统因此也就获得了 Ext4 所支持的更大容量。
2. 更大的文件系统和更大的文件
较之 Ext3 目前所支持的最大 16TB 文件系统和最大 2TB 文件
Ext4 分别支持 1EB（1,048,576TB， 1EB=1024PB， 1PB=1024TB）的文件系统，以及 16TB 的文件。
3. 无限数量的子目录
Ext3 目前只支持 32,000 个子目录，而 Ext4 支持无限数量的子目录。
|
|
Ext2/Ext3
|
Ext4
|
|
最大子目录数目
|
32000
|
65000
|
|
|
|
|
4. Extents区
Ext3 采用间接块映射，当操作大文件时，效率极其低下。比如一个 100MB 大小的文件，在 Ext3 中要建立 25,600 个数据块（每个数据块大小为 4KB）的映射表。
而 Ext4 引入了现代文件系统中流行的 extents 概念，每个 extent为一组连续的数据块，上述文件则表示为“ 该文件数据保存在接下来的 25,600 个数据块中”，提高了不少效率。
5. 一次分配多个块
当写入数据到 Ext3 文件系统中时，Ext3 的数据块分配器每次只能分配一个 4KB 的块，写一个 100MB 文件就要调用 25,600次数据块分配器
而 Ext4 的多块分配器“multiblock allocator”（mballoc） 支持一次调用分配多个数据块。
多块分配器对delayed 分配和extents特别有用。这个feature不会影响到磁盘layout。
6. 延迟分配
Ext3 的数据块分配策略是尽快分配，而 Ext4 和其它现代文件系统的策略是尽可能地延迟分配，直到文件在 cache 中写完才开始分配数据块并写入磁盘，这样就能优化整个文件的数据块分配
与前两种特性搭配起来可以显著提升性能。文件系统已经格式化好，只能让数据hold在文件系统缓存
传统的立即分配方法缺点：举例来说，对于一个写调用，文件系统代码立刻分配数据块的存放位置，甚至是数据还会在cache中存放一段时间才写回磁盘的情况。
当一个进程持续的向文件内写数据，那么接下来的每次写操作都会为数据分配物理块，而不知道文件正在持续的增长。
而延迟分配，在调用写操作时，如果数据仅仅写到cache中，并不会立即分配块，而是等到真正向磁盘写入的时候才进行分配。这就使得块分配器有机会优化，组合这些分配的块（合并写入）。
延迟分配需要同extents和Ext4 的多块分配器配合。因为在一些工作场景下，文件写入磁盘时是按照extents进行分配的，而此时调用的分配器也是mballoc分配器（“multiblock allocator”（mballoc））
7. 快速 fsck
以前执行 fsck 第一步就会很慢，因为它要检查所有的 inode，现在 Ext4 给每个组的 inode 表中都添加了一份未使用 的inode 列表
今后 fsck Ext4 文件系统就可以跳过它们而只去检查那些在用的 inode 了。
必须要注意，是fsck创建的未用inode链表，而不是Ext4创建的。必须首先运行fsck来创建unused indes链表，下一次的fsck才会便快。
8. 日志校验checksumming
日志是最常用的部分，也极易导致磁盘硬件故障，而从损坏的日志中恢复数据会导致更多的数据损坏。
Ext4 的日志校验功能可以很方便地判断日志数据是否损坏，而且它将 Ext3 的两阶段日志机制合并成一个阶段，在增加安全性的同时提高了性能。
9. “无日志”（No Journaling）模式
日志总归有一些开销，Ext4 允许关闭日志，以便某些有特殊需求的用户可以借此提升性能。
10. 在线碎片整理
尽管延迟分配、多块分配和 extents 能有效减少文件系统碎片，但碎片还是不可避免会产生。Ext4 支持在线碎片整理，并将提供 e4defrag 工具进行个别文件或整个文件系统的碎片整理。
11. inode 相关特性
Ext4 支持更大的 inode，较之 Ext3 默认的 inode 大小 128 字节，Ext4 为了在 inode 中容纳更多的扩展属性（如纳秒时间戳
或 inode 版本），默认 inode 大小为 256 字节。Ext4 还支持快速扩展属性（fast extended attributes） 和 inode 保留（inodes reservation）。
12. 持久预分配（Persistent preallocation）
P2P 软件为了保证下载文件有足够的空间存放，常常会预先创建一个与所下载文件大小相同的空文件，以免未来的数小时或数天之内磁盘空间不足导致下载失败。
Ext4 在文件系统层面实现了持久预分配并提供相应的 API（libc 中的 posix_fallocate()），比应用软件自己实现更有效率。
13. 默认启用 barrier
磁盘上配有内部缓存，以便重新调整批量数据的写操作顺序，优化写入性能，因此文件系统必须在日志数据写入磁盘之后才能写 commit 记录，
若commit 记录写入在先，而日志有可能损坏，那么就会影响数据完整性。Ext4 默认启用 barrier，只有当 barrier 之前的数据
全部写入磁盘，才能写 barrier 之后的数据。（可通过 "mount -o barrier=0" 命令禁用该特性。）
.-o options 主要用来描述设备或档案的挂接方式。常用的参数有：
loop：用来把一个文件当成硬盘分区挂接上系统
ro：采用只读方式挂接设备
rw：采用读写方式挂接设备
iocharset：指定访问文件系统所用字符集
同一文件组内多个数据文件，数据写入是线性的，写完一个到下一个
当某个操作触发了文件自动增长时，SQLServer会让那个操作等待，直到文件自动增长结束，
原先那个操作才能继续进行。如果自增长用了很长时间，原先的操作会等不及就超时取消（默认阀值是15秒），不但这个操作会回滚，文件自动增长也会被取消。也就是说，这一次文件没有得到任何增大。最坏的情况是，在一个时间点，有很多操作需要申请新空间，可是谁都没能等到文件自动增长完就超时。
这是体现到终端用户的感觉，就是任何修改操作都不能被提交，全部超时。
直到有一个连接能够等足够久，让SQL把这个自动增长做完。做完以后，其他本来超时的操作又忽然都能恢复正常
SQL2005以后的版本采用了延迟写技术。只要增长的新空间已经分配好，这次自动增长就算大功告成。SQL用后台一个线程把剩余的格式化做完，大大缩短自增长时间，前端不容易超时失败
SQL2005：相当于EXT3 对于一个写调用，文件系统代码立刻分配数据块的存放位置（先分配并立刻格式化），甚至是数据还会在cache中
（内存中）存放一段时间才写回磁盘的情况，格式化分配的空间失败，写调用也会失败
SQL2005以后：相当于EXT4 延迟分配，在调用写操作时，如果数据仅仅写到cache中（内存中），并不会立即分配块（先分配好空间但不会立即格式化，因为要预估磁盘是否有足够空间保存写入数据），而是等到真正向磁盘写入的时候才进行分配。这就使得块分配器有机会优化，组合这些分配的块（合并写入）
SQL2005：分配空间 立刻格式化 数据缓存在内存中
SQL2005以后：分配空间 延迟格式化 数据缓存在内存中
EXT3：立刻分配
EXT4：延迟分配
问题所在：如果SQL Server运行在EXT4文件系统就有问题了，由于是延迟分配，数据库不知道文件系统是否还有足够的磁盘空间装载写入的数据
一旦等到刷盘的时候才一次性分配，那么有可能造成数据丢失，数据库不能保存写入的数据，而前端又已经通知数据已经写入的回复，数据库不可能等到刷盘的时候才通知前端数据是否能够写入成功
Linux的EXT4这种延迟分配是否有问题？
ext2：
在光盘和U盘可以使用这种格式，减少磁盘读写，延长光盘寿命
浪费光盘空间
ext3：
有可靠的恢复能力
挂载的时候可以用
-o journal_data 启用data journaling 功能，写入磁盘的资料先写入日志journal 里，然后再真正写到磁盘，但是因为会写入磁盘两次（一次日志，一次真正数据）
效率会打折扣
沒有 undelete 功能。
开机时视情况进行开机自检，有时候等半个小时，据说EXT4有改善这个问题
可用：tune2fs -c 0 -i 1m /dev/hdXY 来关闭 max-mount-counts，让它不会在挂载多次后便进行fsck，并设定
interval-between-checks为1个月
除了 journal 会占用大量磁盘空间外，有人建议保留至少10%未使用空间，否则会造成ext3效率低下
ext4：
向前兼容
ext3，但有可靠的checksumming in journal 功能。
在个人测试中，速度逼近ext2
和ext3类似，会浪费很多磁盘空间
加快了 fsck 的速度。
可在线调整，在线升级，在线碎片整理
reiserfs：
速度快
和 ext3 一样，也支持 data journaling 功能。不過效率大幅下降。
有些目录是非同步的，不太适合于某些系统
（像 postfix）上。
会占用较多CPU和内存
恢复能力较差，断电会找不回数据
挂载和卸载速度很慢，严重影响开机速度，开机挂载的时候会影响开机速度
偶尔出现
Disk I/O 100% 超过 30 秒的事
主要开发者已经入狱，开发工作几乎停顿。
reiser4：
改进了 reiserfs 的很多缺点，且速度比 reiserfs 更快！
主要开发者已经入狱，开发工作几乎停顿，不可能进入kernel了
xfs：
在操作一些小文件的目录或者大量新增或删除文件或目录时，速度很快，不建议使用在/上
在操作 > 200MB 的文件时有优势。
可在线重组碎片
时间使用长了，效率会下降得很严重
沒有 undelete 功能 。
有报告说明在强制关机甚至强制umount，文件可能因为损坏而难以恢复
所有文件系统中的 CPU Loading最小。
挂载和卸载速度极快
依然在开发维护中
jfs：
CPU Loading较低
综合比较会比ext3快一些
修复能力跟ext3差不多
不太容易有碎片问题
挂载和卸载速度极快
可将
journal 放到另一个分区，不过操作有点麻烦
在删除大文件时速度很慢
IBM开发这个文件系统超过10年，但在Linux真正普及之前就已经停止开发，用的人不多
Debian Installer 默认就有 fsck.jfs 功能
zfs：
号称终极文件系统，但因为授权问题而无法进入kernel中，因而经由fuse来支持zfs，所以速度很慢，在Linux上没有竞争力
btrfs：
基本上为了比美zfs而开发出来的Linux终极文件系统
支持一些先进的磁盘功能，例如磁盘快照，磁盘阵列，动态挂载等
更可靠的 checksumming in journal 功能。
对 SSD 做了最优化。
可在线重组碎片
阅读(5917) | 评论(0) | 转发(0) |
