作为比较,我跑我的测试脚本,针对一组在Linux内核中,大多数用户将熟悉标准的文件系统。
除了普遍感兴趣之外,它还提供了一个很好的值范围,可以在比较新出现的文件系统时用作基线。
EXT2
ext2文件系统是在1993年1月引入Linux内核的,在2001年引入ext3之前一直是主要的文件系统。它是一个固定块大小的文件系统,没有日志记录功能。
计时结果
测试 |
时间(秒) |
总 |
3232.9 |
解开内核源码 |
2.7 |
提取GCC源 |
4.0 |
递归随机文件 |
22.7 |
配置GCC |
2.0 |
Kernbench |
824.5 |
GCC化妆-j16引导 |
1288.3 |
删除内核源代码 |
0.3 |
邦尼++文件操作 |
403.3 |
删除GCC树 |
0.9 |
tiobench螺纹I / O |
54.9 |
邦妮++智能I / O |
629.1 |
邦尼++结果
测试 |
结果 |
顺序创建/秒 |
651 |
顺序统计/秒 |
+++++ |
顺序删除/秒 |
204531 |
随机创建/秒 |
639 |
随机STAT /秒 |
+++++ |
随机删除/秒 |
1204 |
块写入KB /秒 |
648084 |
块重写KB /秒 |
123908 |
块读KB /秒 |
294471 |
随机力求/秒 |
1007 |
EXT3
第三延伸的文件系统(EXT3)引入到主线Linux内核2001,以提供一个文件系统,是backwards-并与EXT2向前兼容的但其提供元数据和(任选地)数据的轴颈。
在默认的data=ordered模式下,通过确保文件数据在对应元数据之前被刷新到磁盘,它还提供了更高的文件系统一致性保证。
计时结果
测试 |
时间(秒) |
总 |
2509.9 |
解开内核源码 |
4.0 |
提取GCC源 |
5.4 |
递归随机文件 |
22.5 |
配置GCC |
2.1 |
Kernbench |
828.1 |
GCC化妆-j16引导 |
1290.4 |
删除内核源代码 |
0.7 |
邦尼++文件操作 |
7.9 |
删除GCC树 |
1.8 |
tiobench螺纹I / O |
59.9 |
邦妮++智能I / O |
286.6 |
邦尼++结果
测试 |
结果 |
顺序创建/秒 |
53412 |
顺序统计/秒 |
+++++ |
顺序删除/秒 |
60123 |
随机创建/秒 |
52744 |
随机STAT /秒 |
+++++ |
随机删除/秒 |
59555 |
块写入KB /秒 |
275239 |
块重写KB /秒 |
115008 |
块读KB /秒 |
309794 |
随机力求/秒 |
991.9 |
XFS
SGI的XFS在90年代中期开始使用他们的Unix变体Irix,但在1999年该公司宣布将把它贡献给Linux。它最终于2002年9月17日出现在Linux的2.5.36内核中,然后在2004年2月5日出现在2.4.24内核中。
XFS是一种基于区段的64位文件系统,能够扩展到9 eb,但是在32位的Linux系统上,内核限制将文件系统和单个文件的扩展都限制到16TB。
计时结果
测试 |
时间(秒) |
总 |
2782.4 |
解开内核源码 |
8.1 |
提取GCC源 |
13.6 |
递归随机文件 |
22.7 |
配置GCC |
2.0 |
Kernbench |
832.2 |
GCC化妆-j16引导 |
1307.3 |
删除内核源代码 |
6.6 |
邦尼++文件操作 |
145.6 |
删除GCC树 |
7.4 |
tiobench螺纹I / O |
51.1 |
邦妮++智能I / O |
385.4 |
邦尼++结果
测试 |
结果 |
顺序创建/秒 |
2894 |
顺序统计/秒 |
+++++ |
顺序删除/秒 |
4602 |
随机创建/秒 |
2643 |
随机STAT /秒 |
+++++ |
随机删除/秒 |
2109 |
块写入KB /秒 |
617869 |
块重写KB /秒 |
128171 |
块读KB /秒 |
246910 |
随机力求/秒 |
1404 |
JFS
JFS是由IBM开发的文件系统。它首先出现在2002年3月8日的2.5.6开发内核中,然后向后移植到2002年11月28日发布的2.4.20。
JFS是一种基于扩展区的文件系统,并且可以延伸到4个PB的具有4KB块大小。
计时结果
测试 |
时间(秒) |
总 |
3064.5 |
解开内核源码 |
10.5 |
提取GCC源 |
18.7 |
递归随机文件 |
22.1 |
配置GCC |
1.9 |
Kernbench |
847.6 |
GCC化妆-j16引导 |
1387.9 |
删除内核源代码 |
12.1 |
邦尼++文件操作 |
193.4 |
删除GCC树 |
21.5 |
tiobench螺纹I / O |
54.9 |
邦妮++智能I / O |
443.8 |
邦尼++结果
测试 |
结果 |
顺序创建/秒 |
5562 |
顺序统计/秒 |
+++++ |
顺序删除/秒 |
2761 |
随机创建/秒 |
1556 |
随机STAT /秒 |
+++++ |
随机删除/秒 |
1432 |
块写入KB /秒 |
327055 |
块重写KB /秒 |
128943 |
块读KB /秒 |
279747 |
随机力求/秒 |
1060 |
Reiserfs文件系统
Reiserfs(实际上是Reiserfs版本3)是第一个包含在主线Linux内核中的日志文件系统,于2001年1月29日在2.4.1版本中发布。
它为文件和目录使用了一种新颖的树结构,并通过对小文件进行“尾打包”来提高空间效率,不过这个特性也会影响性能,如果需要可以禁用它。
计时结果
测试 |
时间(秒) |
总 |
2531.8 |
解开内核源码 |
3.1 |
提取GCC源 |
5 |
递归随机文件 |
25.0 |
配置GCC |
1.5 |
Kernbench |
831.4 |
GCC化妆-j16引导 |
1273.9 |
删除内核源代码 |
1.2 |
邦尼++文件操作 |
18.1 |
删除GCC树 |
2.8 |
tiobench螺纹I / O |
66.2 |
邦妮++智能I / O |
303.3 |
邦尼++结果
测试 |
结果 |
顺序创建/秒 |
29107 |
顺序统计/秒 |
+++++ |
顺序删除/秒 |
24549 |
随机创建/秒 |
28179 |
随机STAT /秒 |
+++++ |
随机删除/秒 |
16623 |
块写入KB /秒 |
359405 |
块重写KB /秒 |
116784 |
块读KB /秒 |
215436 |
随机力求/秒 |
989.1 |
ChunkFS
*作者:阿米特GUD,瓦尔·汉森等。人
*网站(s):http://linuxfs.pbwiki.com/chunkfs
背景
ChunkFS是基于阿尔扬面包车想法德温和Val Henson的反击造成寻道时间没有跟上磁盘大小和带宽的“fsck的问题”。它是在讨论2006 Linux文件系统研讨会并再次在2007年研讨会。
在他们的Usenix纸他们所描述的文件系统,他说:
我们提出的解决方案chunkfs将磁盘上的文件系统格式划分为具有强大故障隔离边界的可单独修复的块。每个块都可以单独检查和修复,只需要偶尔、有限地引用自身之外的数据。”
目前有ChunkFS两个早期实现;一个是直的内核文件系统和所述第二被实现为使用FUSE用户空间的文件系统。两者都使用ext2文件系统代码的覆盖之下。
安装
通过git可以获得FUSE和内核版本以及它们相关联的工具集http://git.kernel.org/。
FUSE版本
要检索ChunkFS的FUSE版本,我装我思包,它提供了一个更高层次的接口GIT然后克隆库这样的:
# apt-get安装cogito
#CG-克隆的git://git.kernel.org/pub/scm/linux/kernel/git/gud/chunkfs.git
因为它是一个FUSE文件系统,所以需要引入一些依赖项,这些在安装文件中有记录:
# apt-get安装e2fslibs e2fslibs-dev fuses -utils libfuses -dev libfuse2
还有一种非法依赖:
#易于得到安装pkg配置
要构建它通常的程序如下:
# . / configure——prefix = / usr /地方/ chunkfs-fuse-trunk
#化妆
#make install的
看样子FUSE版本滞后有点落后的内核版本,虽然FUSE的版本更容易调试,因为它是非常容易的GDB下运行它。
内核模块
我曾预计ChunkFS的直内核文件系统的版本是一个简单的内核模块,所以在试图克隆它,我惊讶地发现,这是其自身包含的内核树!就这样开始了一个相当痛苦的经历。
我开始通过导入为2.6.22.1构建我已经用我现有的内核配置文件,并启用它作为一个模块。我也采取了通知的文本上ChunkFS PBwiki页,这表示:
与CONFIG_CHUNKFS_FS集和CONFIG_BLK_DEV_LOOP为“y”编译。注:没有xattrs和XIPS然而,CONFIG_EXT2_FS_XATTR和CONFIG_EXT2_FS_XIP应该是“不”干净编译。
不幸的是,我再与构建过程中此错误招呼:
错误: “shrink_dcache_for_umount”[FS / chunkfs / chunkfs.ko]未定义!
错误: “super_blocks”[FS / chunkfs / chunkfs.ko]未定义!
错误:“sb_lock”[fs / chunkfs / chunkfs。ko)定义!
但是,告诉它直接构建到内核中是可行的,因此(目前)ChunkFS似乎不会作为模块构建。
然而,尝试引导这个内核时,它会恐慌开机。我转身阿米特GUD,开发商之一,他能够以非常切下来的内核的.config,他使用提供了我。我能采取和仔细地仅启用哪些是必不可少的(PCI设备的支持,SCSI的支持,Adaptec的aacraid驱动程序,网络,等等),我是能够系统得到的引导。
然而,这当然还没有建议初学者!
组态
为了能够创建任何一个版本的文件系统的文件系统ChunkFS,你需要的mkfs的ChunkFS版本这又是可以通过饭桶。
#CG-克隆的git://git.kernel.org/pub/scm/linux/kernel/git/gud/chunkfs-tools.git
# cd chunkfs-tools
# . / configure——prefix = / usr /地方/ chunkfs-fuse-trunk
#化妆
#make install的
因为我在RAID-0条带中有7个驱动器,所以我决定将其设置为ChunkFS文件系统中创建的块数,如下所示:
# /usr/local/chunkfs-fuse-trunk/sbin/mkfs - c7 /dev/md0
然而,它迅速明显,这是令人难以置信的缓慢,这似乎是相当大量的I / O的每个块。快速调查的代码表明,在参数校验码的破缺是造成-C选项砸透进-c选项和设置变量,使坏块检查。幸运很容易解决!
注意:这个补丁已提交上游,但还没有被提交出来的kernel.org git存储库,所以如果你想试验的话,你可以自己检验一下。
保险丝
安装文件系统FUSE是相同的运行的任何其他用户进程。在这里,我们通过-o选项指定我们以前使用自定义的mkfs命令创建的块。你会发现,每进行一次块带有-C选项指定的相同设备引用七次。最后,我们指定安装点。
#在/ usr /本地/ chunkfs熔丝干线/ sbin目录/ chunkfs -o块=的/ dev / md0的是:/ dev / md0的是:/ dev / md0的是:/ dev / md0的是:/ dev / md0的是:/ dev / MD0:/开发/ MD0 / MNT
核心
内核文件系统要简单得多。即使我们有七个块,我们也不需要告诉它我们创建了什么。
# mount -t chunkfs /dev/md0
测试
计时结果
在这里,我们将分别查看FUSE和内核版本。
保险丝
测试 |
时间(秒) |
总 |
以上故障无效 |
解开内核源码 |
47.5 |
提取GCC源 |
116.2 |
递归随机文件 |
26.2 |
配置GCC |
失败,../configure:权限被拒绝 |
Kernbench |
失败,每次运行返回0秒 |
GCC化妆-j16引导 |
作为失败配置没有完成。 |
删除内核源代码 |
在此chunkfs熔丝进程崩溃。 |
邦尼++文件操作 |
N / A |
删除GCC树 |
N / A |
tiobench螺纹I / O |
N / A |
邦妮++智能I / O |
N / A |
FUSE变种看起来相当脆弱。当传递要断开链接的文件的名称时,将上述结果跟踪到缓冲区溢出之前的可重现崩溃。这段代码只出现在FUSE变种中,而不是内核版本中,因为它不需要这个粘合层。
邦尼++结果
从上面可以看出,ChunkFS的FUSE版本是不是足够强大的生存测试,所以没有了Bonnie ++,结果可用。
核心
可悲的是,ChunkFS的内核版本锁机了硬而试图提取内核源代码树,这是不可能的追查这哪里是在有限的时间发生。
NILFS
升作者:该NILFS开发团队,NTT实验室
l网站(s):
http://www.nilfs.org/en/背景
NILFS是由NTT实验室在日本开发和设计,以提供连续“闯关”(以及需求)日志基于文件系统的,可以在以后转换成快照(持久检查站),检查点过期并被清洗前由垃圾收集起来。这些快照是作为只读文件系统单独地安装,并且可以在稍后的日期转换回检查点(垃圾收集)。
它似乎有一组经过精心考虑的用户命令来创建(mkcp)、列表(lscp)、更改(chcp)和删除(rmcp)检查点。
安装
NILFS的安装相当简单。我获取了nilfs内核模块的2.0.0-test -3版本和nilfs-utils包,并将它们解压缩到它们自己的目录中。
内核模块构建为树外模块,所以它只是一个问题:
#CD NILFS-2.0.0测试-3
#化妆
#make install的
让安装到/lib/modules/2.6.22.1+ext4/kernel/fs/nilfs2/必要的内核模块。
工具包使用标准autoconf工具,我构建他们:
# cd nilfs-utils-2.0.0-testing-3
#的./configure前缀=的/ usr /本地/ NILFS-utils的-2.0.0 - 测试-3-
#化妆-j4
#make install的
后来我发现,它并没有完全兑现我曾经穿过的-prefix选项,因为它所做的:
在/ usr / bin中/安装-c的.libs / nilfs_cleanerd / sbin目录/ nilfs_cleanerd
在/ usr / bin中/安装-c mkfs.nilfs2 /sbin/mkfs.nilfs2
/usr/bin/install - c。nilfs2 /sbin/mount.nilfs2
在/ usr / bin中/安装-c umount.nilfs2 /sbin/umount.nilfs2
这将是在通过了-t <文件系统类型>选项,以便对安装方式的mkfs等工作。
组态
创建文件系统NILFS是很容易的:
#mkfs.nilfs的/ dev / md0的
安装又是非常简单的:
#安装-t NILFS2的/ dev / md0的到/ mnt
测试
计时结果
测试 |
时间(秒) |
总 |
3870.5 |
解开内核源码 |
5.5 |
提取GCC源 |
8.2 |
递归随机文件 |
22.4 |
配置GCC |
1.9 |
Kernbench |
827.0 |
GCC化妆-j16引导 |
1293.6 |
删除内核源代码 |
0.7 |
邦尼++文件操作 |
517.6 |
删除GCC树 |
2.7 |
tiobench螺纹I / O |
106.5 |
邦妮++智能I / O |
1084.4 |
邦尼++结果
测试 |
结果 |
顺序创建/秒 |
495 |
顺序统计/秒 |
+++++ |
顺序删除/秒 |
118726 |
随机创建/秒 |
495 |
随机STAT /秒 |
+++++ |
随机删除/秒 |
993 |
块写入KB /秒 |
102669 |
块重写KB /秒 |
60190 |
块读KB /秒 |
177609 |
随机力求/秒 |
519.6 |
BTRFS
升作者:克里斯·梅森,甲骨文