新闻资讯
测试了一下 btrfs 和 zfs
- 0次
- 2021-06-12 00:44:52
- idczone
测试环境，最新的 Fedora 34，结论：
Btrfs:
btrfs 的 compression 形同虚设，一点都没有压缩率。
btrfs 的 dedup 没找到大带宽服务器怎么打开，有些资料说要单独装一个 binary， 然后周期性运行？？？太 low 了。
ZFS：
compression，dedup 都是实打实的。
zfs 选择 lz4 在性能以及压缩率上，对比 zstd，gzip9，是综合最优的。
现在 ZFS on Linux 和 page cache 配合得怎么样？
btrfs 的 inband dedup 还在试验性阶段 https://btrfs.wiki.kernel.org/index.php/User_notes_on_dedupe
压缩不可能形同虚设，可能你的文件被识别为已压缩过的了，就会跳过压缩，可以用 compress-force= 强制对所有文件压缩，但一般来说并不值得。
lz4 会优于 zstd 么，各种 benchmark 都显示 zstd 在性能和压缩率上综合最优，尤其是解压速度。
话说有人在 PC 上用过 f2fs 吗？我在我的 U 盘上用了，但没在 PC 上用过，似乎没人用，有什么问题吗
建议不要使用 f2fs，这个不是为桌面使用优化的，还有数据丢失的风险（然后很难恢复因为多数数据恢复软件都不支持）
同一个文件，一个虚拟机镜像，raw 格式的，btrfs 根本压不动，btrfs 压缩正常。
我的测试程序：
```
zpool create tank /dev/sdc
zfs create tank/lz4
zfs create tank/gzip9
zfs create tank/zstd
zfs set compression=lz4 tank/lz4
zfs set compression=gzip-9 tank/gzip9
zfs set compression=zstd tank/zstd
zfs set dedup=on tank
time cp ~/fedora33-1.img /tank/lz4
zfs list;zpool list
time cp ~/fedora33-1.img /tank/gzip9
zfs list;zpool list
time cp ~/fedora33-1.img /tank/zstd
zfs list;zpool list
```
结果：
```
real 0m3.000s
user 0m0.030s
sys 0m2.325s
NAME USED AVAIL REFER MOUNTPOINT
tank 3.93G 285G 26K /tank
tank/gzip9 24K 285G 24K /tank/gzip9
tank/lz4 3.92G 285G 3.92G /tank/lz4
tank/zstd 24K 285G 24K /tank/zstd
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 298G 3.89G 294G - - 0% 1% 1.00x ONLINE -
/>real 1m0.327s
user 0m0.052s
sys 0m2.019s
NAME USED AVAIL REFER MOUNTPOINT
tank 7.13G 283G 26K /tank
tank/gzip9 2.70G 283G 2.70G /tank/gzip9
tank/lz4 4.39G 283G 4.39G /tank/lz4
tank/zstd 24K 283G 24K /tank/zstd
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 298G 6.10G 292G - - 0% 2% 1.17x ONLINE -
/>real 0m20.419s
user 0m0.038s
sys 0m2.241s
<忘记拷贝了，现在已经被冲刷了>
```
没关注过这个细节。
我五年前还在 ZFS 内核组，天天看 ZFS 代码，年纪大了，现在忘干净了。
我在 gentoo 的 ssd 上用了，确实会有数据丢失的风险，因为开机磁盘检查会失败而报 panic 。
也可能是我哪里没配置对，我现在是跳过了磁盘检查，用到现在没出啥问题就是了
f2fs 升级内核会强制全盘校验, 如果失败就挂载不上了, 但是手机从来不升级内核大版本号, 因此不需要强制校验
你这又没贴怎么测 btrfs 的……
cp & btrfs status
btrfs 前天测得，数据没保存，懒得再弄了。
不需要数据，告诉我们你怎么测的就行。你说你以前是 ZFS 内核组的，那好歹是个技术大佬，做测试也得负点责任吧，一点都没压缩显然是不正常的，怎么能就直接作为结论……
点进来之前还以为会贴出各种测试数据对比两个文件系统的优劣，说实话有点失望……
zstd 官方的 benchmark，https://facebook.github.io/zstd/甩 zstd 一倍
曾经是 zfs 内核组的，这么浮躁有点意外
Btrfs 的透明压缩不可能“一点都没有压缩率”吧，我之前用 archlinux 感觉压缩率还可以的。
另外 btrfs 可以自己选择压缩算法，包括但不限于 zstd/lzo
f2fs 已经很成熟了，我都部署到服务器上了。从来没遇到过升级核心强制全盘校验的情况，数据丢失更是从来没遇到过，数据丢失倒是是 nilfs 上遇到，在意外断电或强制关机时。在我部署的系统中，f2fs 在桌面或服务器系统中都极稳定，足以取代 ext4
在服务器上用 F2FS ？ F2FS 现在连个靠谱的 fsck 都没有，掉电抽彩票么……
https://www.usenix.org/conference/atc19/presentation/jaffer
btrfs 的 online dedup 从来都没有合并过，换句话说就没这个功能。
压缩率是由算法决定的，和文件系统没关系。你测出来没压缩率那显然是没配置对。
btrfs 可以把文件系统建好了再加硬盘上去，更改 raid 之类的，这些操作都不影响正常使用文件系统。zfs 不支持这个。
这是我用 btrfs 的最主要原因。
btrfs 的透明压缩形同虚设？
我这儿相当可观啊，对于 /usr 能有 40 ～ 50% 的压缩率
值得注意的是，du 看到的占用是假的，看压缩率要用 compsize 这个程序
btrfs 压缩率效果很好的啊，我这边三块硬盘开启压缩后，剩余空间多了快一倍不止
Btrfs 压缩一点都没用是不可能的。。以前在小硬盘 VPS 经常用这东西，挺好用。
前天，仅仅拷贝了一个虚拟机镜像。
今天更新一下的 btrfs 测试（粗略测试，没有按照严格的性能测试方法）：
btrfs 采用 zstd 压缩方式：mount -o compress=zstd /dev/sdd1 /tmp/bdata
xfs 文件系统迁移到 btrfs 和 zfs + dedup + lz4 的最终空间占用如下：
21-05-10 13:54:12 [email&df -h
zdata/lz4 302G 111G 191G 37% /root
/dev/sdd1 301G 100G 202G 34% /tmp/bdata
/dev/mapper/myroot-root 300G 187G 114G 63% /tmp/root
从空间看，xfs 占用 187G，zfs 占用 111G，btrfs 100G 。
我之前测试单个文件，看来是样本的问题。
cp 结果看：
21-05-10 14:08:40 [email&time cp /tmp/root/fedora33-2.img.bak /tank/lz4/a/
cp /tmp/root/fedora33-2.img.bak a/ 0.04s user 4.11s system 46% cpu 8.861 total
21-05-10 14:09:09 [email&time cp /tmp/root/fedora33-2.img.bak /tmp/bdata/a/
cp /tmp/root/fedora33-2.img.bak /tmp/bdata/a/ 0.06s user 4.67s system 51% cpu 9.224 total
btrfs & zfs 时间差不多。
综合：
1. 压缩率：btrfs 的使用 zstd 后，比 zfs + dedup + lz4 压缩率要高一些。
2. 性能：从实际的编译大型 C++ 任务来看，每组测试 5 次，zfs + dedup + lz4 需要 30s 左右，btrfs 只需要 20s，btrfs 更占优。
我的开发机器平时编译任务较多，所以还是选择 btrfs 在时间上是比较划算的。
我有用，相关工具用起来感觉很不可靠的样子，掉电有丢数据的风险。好在我的重要数据都在 git 上，大部分都 push 到 remote repo 了，万一完蛋了损失也不大。
话说现在 opensuse 的 btrfs 怎么样 是不是还是很不稳定
Btrfs:
btrfs 的 compression 形同虚设，一点都没有压缩率。
btrfs 的 dedup 没找到大带宽服务器怎么打开，有些资料说要单独装一个 binary， 然后周期性运行？？？太 low 了。
ZFS：
compression，dedup 都是实打实的。
zfs 选择 lz4 在性能以及压缩率上，对比 zstd，gzip9，是综合最优的。
现在 ZFS on Linux 和 page cache 配合得怎么样？
btrfs 的 inband dedup 还在试验性阶段 https://btrfs.wiki.kernel.org/index.php/User_notes_on_dedupe
压缩不可能形同虚设，可能你的文件被识别为已压缩过的了，就会跳过压缩，可以用 compress-force= 强制对所有文件压缩，但一般来说并不值得。
lz4 会优于 zstd 么，各种 benchmark 都显示 zstd 在性能和压缩率上综合最优，尤其是解压速度。
话说有人在 PC 上用过 f2fs 吗？我在我的 U 盘上用了，但没在 PC 上用过，似乎没人用，有什么问题吗
建议不要使用 f2fs，这个不是为桌面使用优化的，还有数据丢失的风险（然后很难恢复因为多数数据恢复软件都不支持）
同一个文件，一个虚拟机镜像，raw 格式的，btrfs 根本压不动，btrfs 压缩正常。
我的测试程序：
```
zpool create tank /dev/sdc
zfs create tank/lz4
zfs create tank/gzip9
zfs create tank/zstd
zfs set compression=lz4 tank/lz4
zfs set compression=gzip-9 tank/gzip9
zfs set compression=zstd tank/zstd
zfs set dedup=on tank
time cp ~/fedora33-1.img /tank/lz4
zfs list;zpool list
time cp ~/fedora33-1.img /tank/gzip9
zfs list;zpool list
time cp ~/fedora33-1.img /tank/zstd
zfs list;zpool list
```
结果：
```
real 0m3.000s
user 0m0.030s
sys 0m2.325s
NAME USED AVAIL REFER MOUNTPOINT
tank 3.93G 285G 26K /tank
tank/gzip9 24K 285G 24K /tank/gzip9
tank/lz4 3.92G 285G 3.92G /tank/lz4
tank/zstd 24K 285G 24K /tank/zstd
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 298G 3.89G 294G - - 0% 1% 1.00x ONLINE -
/>real 1m0.327s
user 0m0.052s
sys 0m2.019s
NAME USED AVAIL REFER MOUNTPOINT
tank 7.13G 283G 26K /tank
tank/gzip9 2.70G 283G 2.70G /tank/gzip9
tank/lz4 4.39G 283G 4.39G /tank/lz4
tank/zstd 24K 283G 24K /tank/zstd
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 298G 6.10G 292G - - 0% 2% 1.17x ONLINE -
/>real 0m20.419s
user 0m0.038s
sys 0m2.241s
<忘记拷贝了，现在已经被冲刷了>
```
没关注过这个细节。
我五年前还在 ZFS 内核组，天天看 ZFS 代码，年纪大了，现在忘干净了。
我在 gentoo 的 ssd 上用了，确实会有数据丢失的风险，因为开机磁盘检查会失败而报 panic 。
也可能是我哪里没配置对，我现在是跳过了磁盘检查，用到现在没出啥问题就是了
f2fs 升级内核会强制全盘校验, 如果失败就挂载不上了, 但是手机从来不升级内核大版本号, 因此不需要强制校验
你这又没贴怎么测 btrfs 的……
cp & btrfs status
btrfs 前天测得，数据没保存，懒得再弄了。
不需要数据，告诉我们你怎么测的就行。你说你以前是 ZFS 内核组的，那好歹是个技术大佬，做测试也得负点责任吧，一点都没压缩显然是不正常的，怎么能就直接作为结论……
点进来之前还以为会贴出各种测试数据对比两个文件系统的优劣，说实话有点失望……
zstd 官方的 benchmark，https://facebook.github.io/zstd/甩 zstd 一倍
曾经是 zfs 内核组的，这么浮躁有点意外
Btrfs 的透明压缩不可能“一点都没有压缩率”吧，我之前用 archlinux 感觉压缩率还可以的。
另外 btrfs 可以自己选择压缩算法，包括但不限于 zstd/lzo
f2fs 已经很成熟了，我都部署到服务器上了。从来没遇到过升级核心强制全盘校验的情况，数据丢失更是从来没遇到过，数据丢失倒是是 nilfs 上遇到，在意外断电或强制关机时。在我部署的系统中，f2fs 在桌面或服务器系统中都极稳定，足以取代 ext4
在服务器上用 F2FS ？ F2FS 现在连个靠谱的 fsck 都没有，掉电抽彩票么……
https://www.usenix.org/conference/atc19/presentation/jaffer
btrfs 的 online dedup 从来都没有合并过，换句话说就没这个功能。
压缩率是由算法决定的，和文件系统没关系。你测出来没压缩率那显然是没配置对。
btrfs 可以把文件系统建好了再加硬盘上去，更改 raid 之类的，这些操作都不影响正常使用文件系统。zfs 不支持这个。
这是我用 btrfs 的最主要原因。
btrfs 的透明压缩形同虚设？
我这儿相当可观啊，对于 /usr 能有 40 ～ 50% 的压缩率
值得注意的是，du 看到的占用是假的，看压缩率要用 compsize 这个程序
btrfs 压缩率效果很好的啊，我这边三块硬盘开启压缩后，剩余空间多了快一倍不止
Btrfs 压缩一点都没用是不可能的。。以前在小硬盘 VPS 经常用这东西，挺好用。
前天，仅仅拷贝了一个虚拟机镜像。
今天更新一下的 btrfs 测试（粗略测试，没有按照严格的性能测试方法）：
btrfs 采用 zstd 压缩方式：mount -o compress=zstd /dev/sdd1 /tmp/bdata
xfs 文件系统迁移到 btrfs 和 zfs + dedup + lz4 的最终空间占用如下：
21-05-10 13:54:12 [email&df -h
zdata/lz4 302G 111G 191G 37% /root
/dev/sdd1 301G 100G 202G 34% /tmp/bdata
/dev/mapper/myroot-root 300G 187G 114G 63% /tmp/root
从空间看，xfs 占用 187G，zfs 占用 111G，btrfs 100G 。
我之前测试单个文件，看来是样本的问题。
cp 结果看：
21-05-10 14:08:40 [email&time cp /tmp/root/fedora33-2.img.bak /tank/lz4/a/
cp /tmp/root/fedora33-2.img.bak a/ 0.04s user 4.11s system 46% cpu 8.861 total
21-05-10 14:09:09 [email&time cp /tmp/root/fedora33-2.img.bak /tmp/bdata/a/
cp /tmp/root/fedora33-2.img.bak /tmp/bdata/a/ 0.06s user 4.67s system 51% cpu 9.224 total
btrfs & zfs 时间差不多。
综合：
1. 压缩率：btrfs 的使用 zstd 后，比 zfs + dedup + lz4 压缩率要高一些。
2. 性能：从实际的编译大型 C++ 任务来看，每组测试 5 次，zfs + dedup + lz4 需要 30s 左右，btrfs 只需要 20s，btrfs 更占优。
我的开发机器平时编译任务较多，所以还是选择 btrfs 在时间上是比较划算的。
我有用，相关工具用起来感觉很不可靠的样子，掉电有丢数据的风险。好在我的重要数据都在 git 上，大部分都 push 到 remote repo 了，万一完蛋了损失也不大。
话说现在 opensuse 的 btrfs 怎么样 是不是还是很不稳定