看中了 btrfs 的 COW 特性，有部署过的说一下这个文件系统实际中有哪些坑。我知道的好像软 raid6 有问题，但这个不用提，我也不用软 raid 。

在

性能对比： http://www.ilsistemista.net/index.php/virtualization/47-zfs-btrfs-xfs-ext4-and-lvm-with-kvm-a-storage-performance-comparison.html?limitstart=0

全部 zfs mirror 或者 raidz1

3 年前就放弃再踩 btrfs 这个坑，安心继续用 zfs (freebsd)

btrfs 似乎并不是一个可以完全免维护的文件系统。

软 RAID 没问题，有问题的是 BTRFS 自带的文件系统层面的 RAID 。

踩过一个坑，就是把 EXT4 转 BTRFS ，结果删除 EXT4subvolum 后系统挂了……
后来才看到有报道说，某几个内核版本的 btrfs-convert 有问题。

忘记是多久以前了 曾经折腾 ArchLinux 的时候 在 VirtualBox 里面安装 Arch 选的 btrfs 最后一步安装 grub 就是装不上 回去换别的 fs 就能安装了 也不知道是不是 btrfs 的问题 反正从此不选这个 fs 还是 ext4 好

其实不太懂，就是觉得扩容太方便了。。

LVM 不是最高，我有点惊讶

我在我笔记本上是 btrfs 根分区，后来一次误操作删除了 /home
发现以前经常用的 extundelete 不支持，只有用 btrfs rescue
发现 quota 只能用 btrfs quota
发现速度确实是没有 ext4 快
有一次恢复快照后多次启动会内核崩溃（具体的原因不清楚，快照用的很少）
可能没有什么帮助。。

快照是神器,
压缩是福利.
不要遇到断电和当机,修复麻烦.我说的是真实结构毁损连带快照都挂的.
就算能修复的问题也需要手动确认.麻烦.
btrfs 内预设延迟写入是 30 秒.
怕问题,改成 1 秒.变慢但不怕故障.而且这才是真实性能.30 秒测出的读写速度根本骗自己.
预设 30 秒是大部分异常之后出问题的原因.因为 30 秒内有太多关键资料没写入.
suse 预设有用 btrfs 了.
不过预设值和使用方法超低能的.
我是手动分割 /挂载 /格式化.

开 COW 写入延迟 30 秒内当机原文件还完整吧？

不如 lvm 开启 thin 功能，然后使用 ext 分区。

只用 FB+ZFS 的飘过。。。

笔记本上用在 nvme 的 ssd 上面。出现几次只读。然后重启就好。但是还是不敢用了

写入延迟 30 秒是说最久 30 秒要写入至少一次.
其实不一定都到 30 秒这样久.
原子性的档案读写都是要求档案系统"确实"写入完成后返回 TRUE 这样的模式.
所以原子性的读写通常损失都很小.但需要等待,而且一般人可能没注意到自己是否用了原子写入.
如果执行的程式用的代码不是原子性的,比较容易发生问题,因为真实写入时间就由 BTRFS 控制了.
COW 的优点应该是
A 有快照功能
B 就算不使用快照也有大量历史版本可修复,但修复失败你就全死了,珍惜生命,要有 2 备,最好 3 备.
C 除非明确使用 NOCOW 参数,这样就跟 EXT3/4 差不多了,如果跟 EXT3/4 差不多干嘛要换 BTRFS,当机后修复要手动很累.
D 好吧 NOCOW 之后的优点是透明压缩,尤其程式码这种零碎小文字档读写很厉害的.BT 这种碎流档案写入也很优.但为什么主流资料库高负载读写性能很低很好笑?法克.

另外,几乎所有的档案系统都有延迟写入的参数,但多少人知道?
zfs 很好很强大,但其实他也是延迟写入大户.只是他用的主要是 RAM,SSD 快取.
所以限制 ZFS 的可用 RAM,拿掉 SSD 快取区,他的表现还能高大上吗?
大概只剩 lz4 这个我超想要但 BTRFS 没有的透明压缩选项了.

没用过 BTFS ，曾经被 ZFS on linux 折磨了半年多...

记得 BTRFS 的官方文档用很显眼的方式标明："使用 BTRFS 一定要尽可能的使用新的内核", 例如 4.6....服务器上敢随便升级么

zfs 的内存还是值得的，一般我都给 4g ，跑数据库的我都给 8g 再加 SSD 的 cache 和 log 设备

搭车问下， ubuntu 1604 据说支持 zfs ，有人用过吗？

在几台机器上用 btrfs ，家里的 nas btrfs raid10 跑了一年多了

不要在硬件 raid 上搭 btrfs ，软 raid 很好用
snapper 是神器
为了避免手贱删除 subvolume ，可以在里面建立一个.开头的隐藏 subvolume ，因为 subvolume 删除不是递归的……

目前我用自己的旧主机跟家用光纤线路营运,所以很难要求设备高大上,只好想办法压榨旧主机.
其实设备性能很强或资金充裕的时候很多人不会在乎这些细节,因为赶时间去赚钱.
我总共才 16G 还要开 KVM/AS/eclipse/vs2015 等多项开发工具,舍不得给档案系统太多 RAM,
所以我用 ZFS 的时候是用 64MB 看性能的.
SSD 我也才一块 256,都用于真实档案系统上了,不是给 ZFS 当快取 /日志碟.

btrfs 时不时要 balance 一下，遇到过好几次 metadata 空间不足的情况，多 balance 几次才救过来。

是的，要玩快照，只敢用 ZFS

[所以限制 ZFS 的可用 RAM,拿掉 SSD 快取区,他的表现还能高大上吗? ]
小内存(2G-4G)机器上限制 ARC (ZFS 可用 RAM)，没钱用 SSD ，一直玩的很好。

参考我以前吐槽 btrfs 的吧：
引用:
likuku 2015-04-15 23:40:02 +08:00
btrfs 的坑，去年又被狠狠坑了一次，还是公司的开发机，搞得 站点和 svn 库所在的分区没法写入，也基本没法读取(几十 KB/sec 的读取速度)，折腾了两天才导出数据火速切换成默认的 Ext4 。
以为这么多年过去了终于能用了吧。。。也是指望用它的 snapshot 。
https://www.v2ex.com/t/183689

btrfs 的效能真不是一个“烂”字可以形容～！ - V2EX :
https://www.v2ex.com/t/25686

除了这个还有什么能实现存储池很简单的扩容缩容的？

Btrfs 添加删除硬盘， RAID 格式转来换去还真是挺方便的。
但虚拟机和数据库之类的应用需要禁用掉 COW, 否则性能极差。
我还碰到一个最无法忍受的问题，在略早的一对 2T 硬盘 RAID1 上执行 scrub ， io 优先级尽管调到最低，系统停止响应，必须等到 scrub 完成，才恢复响应。另在 4x3T 的 RAID10 上执行 scrub, 虽然系统没有完全无响应，但系统开销也是极高的，响应时间大大降低。
我这还是家用系统，如果是生产系统，这肯定是无法接受的。
上 ZFS 吧，真的挺好的。