柔中带刚，刚中带柔，淫荡中富含柔和，刚猛中荡漾风骚，无坚不摧，无孔不入！
全部博文（1669）
分类： LINUX
2013-03-26 10:08:07
2013-03-22 11:26:08| 分类： linux文件系统 | 标签： |字号大中小
Linux原生的ext4文件系统目前已经在一些最新的Linux发布版本中包含了，我也使用了一段时间，和ext3相比，有所改善但是不是那种非常显著的干劲，更详细的情况可以参考这篇文章()。
不过我一直向往上的，觉得那才是真正的企业级文件系统，COW,CDP等功能让人着迷，虽然目前linux上已经有基于的实现，但是性能上就大打折扣了，直到文件系统的出现，让我看到了未来：
承若将赋予这个文件系统许多类似ZFS的企业级特征，甚至在性能和亮点上要超过。事实上，很多Linux专家认为应该是Linux未来的 一个关键点。
不过目前目前还没有完全发布，不过相信很快大家就能用到了，在正式使用之前，我们不妨对它做一些了解，甚至可以对其进行一些性能上的测试。
，有时又被称作”Butter FS”(黄油文件系统？），最先由在工作的发起这个项目，以协议发布。目前这个项目在Linux社区获得大量的追随者并引起大多数人的共鸣，目前有以下特性：
从以上的特征，你能看出来是一个非常有“野心”的项目，当然看了这些特征，估计你会爱死它了（不会像一样不堪重负而死掉吧？） 可能你立刻会问到一个问题，“和相比如何？”，恩，知道你会问这个问题，因为有人已经有来对此作为比较，我们这里摘录其关键点吧，看下面这张对照表格：
| 特征 | ZFS | BTRFS |
|---|---|---|
| 写时复制 | 是 | 是 |
| 快照 | 是 | 是 |
| 快照的快照 | 不清楚 | 是 |
| 磁盘使用率接近98-100%时，性能受损 | 是 | 差不多是这样 |
| 块级别压缩 | 是 | 当前是作为一个挂载选项 |
| 磁盘加密 | 正在开发 | 已经计划了，但是目前还未进入内核，encryptfs是一个选择 |
| 在线改变文件系统大小 | 否 | 是 |
| 在线碎片整理 | 否 | 是 |
| 写校验和 | 是 | 是 |
| 内建RAID | 是(0,1,10, 5 ) | 是(0, 1, 10) |
| ACL | 是 | 是 |
| 直接IO | 是 | 写可以，读不行–已经计划了 |
| 配额 | 是 | 是 |
是非常有雄心的一个项目，带来了非常多的新特性，一些非常重要和关键的特性已经在上面的列表中说了，这些特性值得我们深入了解。
这个特性听上去不怎么实用，实际上，在创建/扩展文件系统时，它还是很有用的。动态分配意味着当创建文件系统时只有少量的i节点被创建，当i节点不够时，文件系统会非常平滑的创建更多的i节点。想想以前创建一个500G的文件系统时，有多少时间是花在创建i节点上呢？
允许你创建文件系统或者文件系统某一个部分的快照，你可以利用这个快照来创建备份，或者在紧急情况下的数据拷贝。
你也可以使用它来将文件系统的某一个部分dump出来作为一个归档（归档后，你可以删除快照和原始数据）。
通常，快照是不会被修改的，因为做快照一般都是用来执行一些比较关键的任务，比如备份、修复、归档等。
但是在某些情况下，你可以需要对快照做一些写的操作，允许你这么干
举个例子：假定你对某一个目录做了快照，而后你又在这个目录做了一些工作，只要你能确保这个目录已经更新到快照里，你就可以保持你的拷贝是最新的，这实际上是一个快照的快照，这就是一个非常灵活的快照功能(没有明白？等你用了，你就明白了）。
这个术语已经听得很多了，它指的是允许你的某一些数据在写的时候被拷贝（就是做了两次拷贝）。
在里，这个技术可以有各种用途。比如可以将它和快照甚至快照的快照技术联合起来使用，这样使得数据很容易更新。
也可以使用它来记录日至，比如对于日志文件系统，可以对日志或者数据来一个写时复制，这就可以保证数据的高可用性。
能够把文件系统的某一部分分离出来挂载，就像是一个独立的文件系统一样。
当你想限制用户访问一个目录中的某一个部分的时候，这个功能就会变得非常有用。
比如，如果在一个主目录里，其中一个子目录希望能被用户访问，而其他部分不允许。
那么这个子目录就可以当作子卷（subvolume）挂载，对用户而言，她就像一个实际的文件系统一样。
当前Linux系统，如果你想创建一个RAID-0或者RAID-1或者其他RAID级别，然后在这些设备用上LVM，你可能需要使用硬件RAID卡或者软RAID（md）来做到把多个设备合成一个虚拟的设备。
而则把对多设备(RAID)的支持内嵌到文件系统里了。
当前，可以做RAID-0，RAID-1，RAID-10（以后应该会增加系统RAID级别）。
一旦被创建，它允许你直接增加设备（磁盘）到这个文件系统里（动态i节点分配是关键），当然也允许你拿走设备。
（哦，天啦，哦，天啦，天啦，这不就是一个磁盘阵列了么？）
文件系统检查(fsck)对系统管理员而言就是一个毒药，因为做文件系统检查，你就需要将文件系统处于offline的状态（在线fsck，你试试，别到时哭都没有地方哭去），然后做fsck操作来修复，这个过程是需要花费大量的时间的，修复完成后，你总算可以重新挂载了（假定你修复出来的文件系统没有问题）。
Btrfs允许你对一个已经挂载而且在使用的文件系统进行在线的文件系统检查。在检查的过程中，你仍然可以使用这个文件系统。
另外，虽然文件系统开发人员尽了最大的努力，但是碎片还是会发生，当然也就会影响性能（想起那个著名的有关windows磁盘碎片整理的笑话来了）。
磁盘碎片整理也需要文件系统处于offline的状态，和fsck差不多，而也允许你在在线的时候使用。
文件系统加密变得越来越流行，特别对一些企业和敏感人士的笔记本而言，一旦笔记本被偷或者遇到不良维修人员（想象陈君冠希老师吧），也许你会死的很惨。因此文件系统加密变得很重要了。
加入了非常强的加密功能，而且还会提供一些额外的技术（记住：目前这部分还在开发过程中）
除了加密，也提供了压缩来节省空间和提升性能的功能，当前，它使用内核自带的zlib压缩算法。
一旦有新的功能，我们总是想问，我们嘛时候能使用呀？可是新功能总是要经过无数次的测试，调试，开发这样的一个迭代过程，因此不会来的太快的。
目前，内核2.6.29版本已经进入了，不过加上了“试验(experimental)”的标签，这当然是Linux一贯的做法，可以获得更广泛的测试以及问题反馈。
你可以升级到这个核心，并订阅的开发邮件列表，为的早日杀青作出你的贡献吧。
说了这么多，都是干说，现在我们来点实际的，下面给出一个完整的文件系统创建和测试的步骤，让大家过足瘾吧。
故事从下面的指令开始：%mkfs.btrfs /dev/sda1 它发生的太快了，连你想掐秒表计算时间的机会都没有。OK，来个脚本测试一把吧：
[root@test64 ~]# ./test.sh
Sat Apr 18 15:47:50 EDT 2009
WARNING! - Btrfs Btrfs v0.18 IS EXPERIMENTAL
WARNING! - see before using
fs created label (null) on /dev/sda1
nodesize 4096 leafsize 4096 sectorsize 4096 size 465.76GB
Btrfs Btrfs v0.18
Sat Apr 18 15:47:51 EDT 2009
不要不相信自己的眼睛，没错，465G的文件系统创建只要1秒钟，这就是i节点动态分配的直接结果。你可以用创建ext3文件系统来作为一个对比(当然，ext4已经支持i节点动态分配了）
创建完后,挂载当然是一件很简单的事情了。
%mount -t btrfs /dev/sda1 /mnt/data_btrfs
在多个设备上创建文件系统也很简单，缺省情况下，在在多个设备上创建 文件系统是，元数据(metadata)会在每一个设备上做一个镜像（类似RAID1）。而数据而采取条带模式(类似RAID0)。当然 也允许你改变元数据存储的方式，它支持下面的方式：
下面是在多个设备上创建的例子：
% mkfs.btrfs /dev/sda1 /dev/sdb1
现在你可以使用/dev/sda1或者/dev/sdb1挂载。创建多设备的文件系统并不比创建单个设备的文件系统要慢。
性能测试有很多，这里我们选择iozone工具，关于的相关说明和用户可以参考官方文档。测试环境是AMD Opteron64 CPU 2.0GHz，CentOS 5.3,Btrfs v0.18，kernel 2.6.30-rc1
我们会针对单个磁盘和两个磁盘分别进行测试，对于挂载选项，我们可以选择了缺省（标准）挂载方式和以下的挂载参数：
下面的测试结果表有4列：write,rewrite,read,reread。
作为对比，我们选择了ext3(default),ext4(default),ext3(performance),ext4(performance)最为测试比较对象。
详细情况请看下表：
| File System |
mkfs.btrfs options |
Mount options |
Write MB/s |
Rewrite MB/s |
Read MB/s |
Reread MB/s |
|---|---|---|---|---|---|---|
| Ext3 | 28.307 | 28.001 | 55.791 | 55.765 | ||
| Ext4 | 30.228 | 29.626 | 108.701 | 108.884 | ||
| Ext3 “optimal” | 28.047 | 26.432 | 105.565 | 105.156 | ||
| Ext4 “optimal” | 30.127 | 29.365 | 109.889 | 109.600 | ||
| Btrfs | Standard | Standard | 31.586 | 31.917 | 104.104 | 104.106 |
| Btrfs | Standard |
nodatacow, nodatasum |
31.933 | 31.839 | 107.157 | 106.565 |
| Btrfs | -m single | standard | 31.513 | 31.504 | 105.578 | 105.828 |
| Btrfs | -m single |
nodatacow, nodatasum |
31.874 | 31.896 | 105.109 | 106.565 |
| Btrfs | standard | compress | 71.359 | 71.129 | 126.660 | 132.314 |
| Btrfs |
two disks, raid0 |
standard | 49.891 | 50.318 | 129.907 | 132.024 |
| Btrfs |
two disks, raid0 |
nodatacow, nodatasum |
45.054 | 45.867 | 130.655 | 131.879 |
| Btrfs |
two disks, single |
standard | 50.144 | 50.264 | 126.984 | 131.130 |
| Btrfs |
two disks, single |
nodatacow, nodatasum |
43.834 | 47.603 | 131.612 | 131.470 |
| Btrfs |
two disks, raid1 |
standard | 48.984 | 50.388 | 122.818 | 109.867 |
| Btrfs |
two disks, raid1 |
nodatacow, nodatasum |
48.196 | 48.462 | 131.832 | 131.807 |
| Btrfs |
two disks, raid10 |
standard | 49.859 | 50.101 | 130.655 | 132.179 |
| Btrfs |
two disks, raid10 |
nodatacow, nodatasum |
50.072 | 50.366 | 129.424 | 122.828 |
| Btrfs | -m single | -o compress | 70.241 | 69.299 | 138.849 | 127.958 |
| Btrfs | -m single |
-o compress nodatacow, nodatasum |
31.976 | 31.922 | 107.000 | 106.728 |
| Btrfs |
two disks, raid0 |
-o compress | 70.234 | 69.048 | 130.852 | 129928 |
| Btrfs |
two disks, raid0 |
-o compress nodatacow, nodatasum |
48.762 | 48.831 | 130.812 | 130.202 |
| Btrfs |
two disks, raid1 |
-o compress | 70.467 | 68.286 | 130.990 | 130.051 |
| Btrfs |
two disks, raid10 |
-o compress | 70.900 | 69.926 | 130.812 | 130.202 |
从上面的测试结果，我们可以获得以下一些结论：
以上测试结论或者在你的环境中有些不同，毕竟其影响因素太多，但是不管如何，对于一个还在开发过程中的文件系统而言，已经有了非常可观的性能。而且，针对单个磁盘，当压缩选项打开后，iozone的测试性能是非常显著的。
尽管Linux的开发和进展都非常好，但是还有一些人很早以前就要求Linux能够提供更好的文件系统，他们希望它具有企业级特性，而能和竞争。应该回答和满足了这些人的需求。在内核2.6.29时合并到了内核主干里，不过目前仍然是试验性质的。并不是上述所有的特性都已经实现了，但是目前的版本(v0.18)已经有了非常多的特性了。
尽管在CentOS 5.3系统(kernel 2.6.30-rc1)里，还是试验性质，不过的基本性能已经和ext4差不多了。
综合上面的测试案例，的性能更多的受磁盘性能的影响，有时受CPU性能的影响（在使用压缩的测试例子里）。
你当然还可以更加深入的研究上述的测试结果，以获得更多的信息。
如果你看了这篇文章，对Btrfs甚至Linux产生了浓厚的兴趣，那我会非常高兴的。
注：以上内容大部分内容翻译自，另外一部分内容加入了自己的看法和理解。
btrfs是linux下一代文件系统，由oracle、radhat、intel、suse等多个公司和社区研发，采用GPL协议发布（Linux Only），目前正逐步稳定下来。Arch的内核很新，也对btrfs提供了较好的支持，我尝试了一次全新的整个系统基于btrfs的安装，和大家分享一下心得。
首先，为什么我们要用btrfs？btrfs有很多吸引人的特性，比如：
1、类似lvm的多设备文件系统，目前支持raid0、raid1、raid10,预计在3.5内核中加入raid5/6的支持。
2、类似于ZFS的pool概念：一个分卷（volume）可以横跨多个物理分区，分卷内有subvolume共享volume的空间。比如为了重装能保留/home，你的/分了20G，/home分了60G，某天/不够用了，怎么办？btrfs可以把/和/home作为subvolume，共享剩余空间，同时在/遇到不可逆损坏时保持/home的完整性。不过有一个限制：btrfs上不能放置swap文件，会损坏文件系统。请使用独立的swap分区。
3、快照。btrfs能对任何subvolume进行快照，同时其copy-on-write的特性可以让多个快照引用同一个文件，当文件在一个快照中被修改时再复制一份储存在这个快照中，所以说，一个快照初始时几乎不占硬盘空间，随着系统使用快照和当前系统的差异越来越大，快照才占用越来越多的空间。
4、透明压缩。支持文件系统级的压缩，目前支持zlib和lzo两种算法，后续会加入snappy和lz4等。现在系统往往硬盘读取速度是瓶颈，牺牲一些CPU时间压缩数据而减少硬盘读写往往能提高整体效率。 测评：
5、设计时就考虑到了SSD的优化
我觉得以上是比较吸引桌面用户的地方，还有很多别的特性可见： 可以说，目前来看，除了ZFS的deduplication功能，btrfs是一个能和ZFS正面抗衡的linux文件系统。
为了尝试btrfs，我在我的15G小硬盘上重装了系统。系统安装和别的大致无异，但要注意一下几个方面：
1、选择软件包时，选上btrfs-progs
2、我要讲讲subvolume的意义：btrfs，顾名思义，Btree（二叉树）是文件系统组织方式。subvolume就是森林的根，标识一个subvolume有两个数据：名称和ID。建立文件系统后，会自动生成总树根，没有名称，ID为0。之后你可以在下面建立文件、文件夹和子树，文件夹和子树中又能包含别的文件、文件夹和子树。子树和文件夹的区别在于，子树能够用mount命令直挂载在到目录根部，也可以对其快照而文件夹不行。为了更好的扩展性与快照回滚能力，建议把/安装在一个新的subvolume而不是总树根上。很不幸，arch默认的安装脚本不能满足我们的要求，我们来手动安装arch。下面演示创建一个/、一个/home和一个pkg子树，并为了稳妥将/boot分在另一个独立的ext4分区上。为什么建这个pkg子树呢？因为可以对subvolume指定不同的挂载选项，像pkg里面全是压缩包，自然就不用透明压缩，所以不需要compress（很可惜，到3.3内核还没有支持不同subvolume使用不同的压缩选项，以后会改进，见：)。
具体步骤可见：，我想有意愿折腾btrfs的不会被手动安装arch难到。用mkfs.btrfs创建一个类型为btrfs的分区，挂载到/mnt。cd到/mnt，执行以下命令：
btrfs subvolume create rootfs btrfs subvolume create homefs btrfs subvolume create pkg
之后用命令
btrfs subvolume list /mnt
可以看到这样的结果：
ID 256 top level 5 path rootfs ID 260 top level 5 path homefs ID 262 top level 5 path pkg
（我们的ID可能会不一样，以自己的为准）
三个subvolume建立完成！但是这样还不够，我们要按照结构挂载。btrfs的挂载选项也很有讲究，具体见：
执行：
mount -o remount,compress=lzo,space_cache,autodefrag /dev/sdaX /mnt mkdir -p /mnt/rootfs/home /mnt/rootfs/var/cache/pacman/pkg /mnt/rootfs/dev /mnt/rootfs/proc /mnt/rootfs/sys mkdir -p /mnt/rootfs/var/cache/pacman/pkg mount -o subvol=homefs,compress=lzo,space_cache,autodefrag /dev/sdaX /mnt/rootfs/home mount -o subvol=pkg,compress=lzo,space_cache,autodefrag /dev/sdaX /mnt/rootfs/var/cache/pacman/pkg mount /dev/sdaY（ext4的boot分区） /mnt/rootfs/boot
subvol=
然后到/mnt/rootfs/中，执行
mount -o bind /dev dev/ mount -t proc /proc proc/ mount -t sysfs /sys sys/
最后来一步pacman -r . -Sy base grub2-bios --ignore grub 安装系统。我试过，grub1不能从subvolume中启动，syslinux我不熟，听说也有问题，所以推荐grub2。安装grub2不多说了，。
之后就是/etc 中的设置了，按个人喜好，注意几个地方：
1、mkinitcpio的hook里加上btrfs，然后mkinitcpio -p linux重新生成镜像，不然多设备btrfs可能无法启动。会提示fsck.btrfs找不到，不用管，这个目前还没实现。
2、fstab要写好，我的是这样的：
…… /dev/sda10 / btrfs subvolid=256,defaults,compress=lzo,space_cache,autodefrag 0 1 /dev/sda10 /home btrfs subvolid=260,defaults,compress=lzo,space_cache,autodefrag 0 1 /dev/sda10 /var/cache/pacman/pkg/ btrfs subvolid=262,defaults,compress=lzo,space_cache,autodefrag 0 1 /dev/sda8 /boot ext4 defaults 0 1 /dev/sda9 swap swap defaults 0 0 ……
3、/etc/default/grub里GRUB_CMDLINE_LINUX_DEFAULT="rootflags=subvolid=256"后生成grub.cfg。这是告诉内核启动时把subvolid=256当成/。以上所有用id的地方都可以用subvol=名称
设置好root密码--passwd root。然后你觉得差不多就可以重启了
重启以后，按照自己的喜好配置系统吧！操作和别的文件系统完全一样。大家用df看看硬盘容量，一定会惊奇于大小的：我整个系统包括X、左面环境和日常软件一共只占了1.8G大小！大家肯定还有一个疑问：df显示的total != used+available，前者比后者大了1/8左右，这是为什么呢？还是来看挂载选项：
就是说，默认情况每分配8个data chunk会分配1个metadata chunk，所以那1/8是metadata的大小。难道说btrfs的硬盘利用率只有8/9？不用担心，btrfs会把能放进metadata chunk的小文件放在里面，所以那1/9的空间也是可以存储文件的！而命令
btrfs filesystem balance
可以重新平衡文件分布，如果是raid，那么在多个设备上平衡负载；如果对单设备的metadata进行，就可以平衡小文件的分布。以后可能会自动后台进行metadata的balance。而且鉴于lzo平均2.08的压缩率，磁盘利用率会提高很多，尤其是对于大量的文本配置文件、源代码等。
再说一说snapshot这个吸引人的特性，snapshot就是依据现有的subvolume新建一个subvolume，有点像OO语言中的引用，对一个subvolume创建一个快照后，两者是平等的；一个文件有引用计数，可以在多个snapshot中被引用，或者由cp --reflink=always创建一个引用（目前cp的reflink不能做到跨subvolume引用，补丁还未合并），当引用数降为零时文件才被删除；和硬链接不同的是，当文件在一个快照中被修改时会新复制一份储存在这个快照中，而不会影响到别的引用，这就是copy-on-write。这样的快照能充分节省空间。我们来演示一下：
首先，我们要挂载总结点
mount -o subvolid=0 /dev/sdaX /mnt
cd到/mnt，我们创建一个对于rootfs的快照：
btrfs subvolume snapshot rootfs 20120516
建议：
touch 20120516/This-is-snapshot-20120516
注意：btrfs的快照不具有递归性，即如果rootfs中还有二级subvolume，那么快照中不会包含二级subvolume的文件，而是包含一个对二级subvolume的引用，类似于这样：
0----rootfs--------------------------------------------subvol2-----文件a
| | ^
| -----------文件夹b--文件c |
| ---文件d ^ ^ |
| ^ | | |
| | | | |
--20120516---------------------------------------------
在rootfs中修改文件d、c会复制一份新的，对20120516不可见；而修改a的话在rootfs和20120516中都能看到。
所以为什么我们之前分了三个subvolume：
1、一般灾难都是/所致，所以不需要把/home也整个备份，而且/home中修改频繁，很容易创造大量新文件，占用空间；
2、能够对/home单独snapshot
3、pkg是pacman的包所在地，一般不需要备份。这样对rootfs快照后pkg不会被打进去，使用pacman -Scc后也不会因为20120516中仍有对其中软件包的引用而导致不能释放硬盘空间。
灾难恢复也变得很简单了，回滚到上一个/的状态，只要在开机时编辑grub菜单linux项里把rootflags=subvol=rootfs改成rootflags=subvol=20120516就回滚了。开机后如果你发现/下有刚才touch的文件This-is-snapshot-20120516，那么你就成功进入了快照中！
快照也是可读写的，所以对于/home的快照恢复不需要重新挂载一边，找个地方把/dev/sdaX挂上就能在里面把需要的文件cp出来。当然你想回滚整个/home的状态那么就改fstab好了。
定期创建和清理不需要的快照是个好习惯！清理快照能解除引用，释放你在当前系统中删除的文件的空间。对于重要文件，还是建议不要完全依赖快照，在别的文件系统或网络上留一个备份为好。
最后说一下问题和修复的办法，我没有遇到过问题，就是摘录几个方法：
1、mount选项里的recovery会尝试找到上一次的节点，比如写入一个文件一半后断电，ext4下这个文件会损坏，而btrfs你可能会得到这个文件写入前的版本。所有没有执行flush的操作都会导致得到旧版本的文件。
2、btrfsck。btrfs有fsck，但是api和fsck.ext4等不同，所以还没有集成进去，mkinitcpio里也没有。建议在initramdisk里包含这个(mkinitcpio.conf的BINARY="btrfsck")，如果文件系统错误得挂载不了了，在ramfs里执行btrfsck /dev/sdaX
3、AUR里有一个mkinitcpio-btrfs，是方便回滚的脚本。我不太喜欢它的命名风格（当前/叫__active，我叫rootfs的，备份在__snapshot subvolume里，而我放在根节点下），所以我没用。经常回滚的可以参考一下。
还有几个提醒：
1、备份备份备份！光有回滚不能保证你的数据安全。
2、/boot是独立的，所以没有内核回滚能力，请自行备份内核。
3、（和2矛盾）如果用新版本内核提供的挂载选项挂载过btrfs文件系统，再用老版本内核可能会挂载出错！请仔细看挂载选项后表明的内核版本。
最后有一个疑问：为什么oracle要研发btrfs呢？当时sun的solaris和linux在服务器领域有竞争（我想他们不会认为bsd有和他们竞争的能力），sun的ZFS是一大法宝，而且采用CDDL发布，使Linux无法使用；oracle一方面闭源了ZFS，另一方面却开发GPL的btrfs，GPL意味着它不能将btrfs私有化。Oracle想什么呢？
参考资料：