Chinaunix首页 | 论坛 | 博客
  • 博客访问: 791967
  • 博文数量: 179
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 1536
  • 用 户 组: 普通用户
  • 注册时间: 2015-01-27 11:05
个人简介

MySQL工程师 QQ:1815357042

文章分类

全部博文(179)

文章存档

2015年(179)

分类: LINUX

2015-03-11 16:22:22

转载自:
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中,并不会立即分配块,而是等到真正向磁盘写入的时候才进行分配。这就使得块分配器有机会优化,组合这些分配的块(合并写入)。
延迟分配需要同extentsExt4 的多块分配器配合。因为在一些工作场景下,文件写入磁盘时是按照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 做了最优化。
可在线重组碎片


阅读(5402) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~