V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
sherlock1122
V2EX  ›  Linux

测试了一下 btrfs 和 zfs

  •  
  •   sherlock1122 · 2021-05-09 20:49:29 +08:00 · 7289 次点击
    这是一个创建于 1283 天前的主题,其中的信息可能已经有所发展或是发生改变。
    测试环境,最新的 Fedora 34,结论:
    Btrfs:
    btrfs 的 compression 形同虚设,一点都没有压缩率。
    btrfs 的 dedup 没找到怎么打开,有些资料说要单独装一个 binary, 然后周期性运行???太 low 了。

    ZFS:
    compression,dedup 都是实打实的。
    zfs 选择 lz4 在性能以及压缩率上,对比 zstd,gzip9,是综合最优的。
    25 条回复    2021-07-17 06:45:47 +08:00
    billlee
        1
    billlee  
       2021-05-09 21:25:42 +08:00
    现在 ZFS on Linux 和 page cache 配合得怎么样?
    Jirajine
        2
    Jirajine  
       2021-05-09 21:48:22 +08:00
    btrfs 的 inband dedup 还在试验性阶段 https://btrfs.wiki.kernel.org/index.php/User_notes_on_dedupe

    压缩不可能形同虚设,可能你的文件被识别为已压缩过的了,就会跳过压缩,可以用 compress-force= 强制对所有文件压缩,但一般来说并不值得。

    lz4 会优于 zstd 么,各种 benchmark 都显示 zstd 在性能和压缩率上综合最优,尤其是解压速度。
    love
        3
    love  
       2021-05-09 22:01:20 +08:00
    话说有人在 PC 上用过 f2fs 吗?我在我的 U 盘上用了,但没在 PC 上用过,似乎没人用,有什么问题吗
    codehz
        4
    codehz  
       2021-05-09 22:05:36 +08:00 via Android
    @love 建议不要使用 f2fs,这个不是为桌面使用优化的,还有数据丢失的风险(然后很难恢复因为多数数据恢复软件都不支持)
    sherlock1122
        5
    sherlock1122  
    OP
       2021-05-09 22:29:30 +08:00
    @Jirajine 同一个文件,一个虚拟机镜像,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
    <忘记拷贝了,现在已经被冲刷了>
    ```
    sherlock1122
        6
    sherlock1122  
    OP
       2021-05-09 22:30:28 +08:00
    @billlee 没关注过这个细节。
    我五年前还在 ZFS 内核组,天天看 ZFS 代码,年纪大了,现在忘干净了。
    skyrem
        7
    skyrem  
       2021-05-09 23:09:10 +08:00
    @love #3 我在 gentoo 的 ssd 上用了,确实会有数据丢失的风险,因为开机磁盘检查会失败而报 panic 。
    也可能是我哪里没配置对,我现在是跳过了磁盘检查,用到现在没出啥问题就是了
    12101111
        8
    12101111  
       2021-05-09 23:16:03 +08:00
    @skyrem
    @love
    f2fs 升级内核会强制全盘校验, 如果失败就挂载不上了, 但是手机从来不升级内核大版本号, 因此不需要强制校验
    aloxaf
        9
    aloxaf  
       2021-05-09 23:35:12 +08:00
    @sherlock1122 #5 你这又没贴怎么测 btrfs 的……
    sherlock1122
        10
    sherlock1122  
    OP
       2021-05-09 23:52:28 +08:00
    @aloxaf cp & btrfs status

    btrfs 前天测得,数据没保存,懒得再弄了。
    aloxaf
        11
    aloxaf  
       2021-05-10 00:04:29 +08:00   ❤️ 2
    @sherlock1122 #10 不需要数据,告诉我们你怎么测的就行。你说你以前是 ZFS 内核组的,那好歹是个技术大佬,做测试也得负点责任吧,一点都没压缩显然是不正常的,怎么能就直接作为结论……

    点进来之前还以为会贴出各种测试数据对比两个文件系统的优劣,说实话有点失望……
    liuxu
        12
    liuxu  
       2021-05-10 00:19:06 +08:00
    @Jirajine

    zstd 官方的 benchmark,https://facebook.github.io/zstd/#benchmarks

    尤其是解压速度,lz4 甩 zstd 一倍
    liuxu
        13
    liuxu  
       2021-05-10 00:24:26 +08:00
    曾经是 zfs 内核组的,这么浮躁有点意外
    Rasphino
        14
    Rasphino  
       2021-05-10 02:07:11 +08:00 via iPhone
    Btrfs 的透明压缩不可能“一点都没有压缩率”吧,我之前用 archlinux 感觉压缩率还可以的。
    另外 btrfs 可以自己选择压缩算法,包括但不限于 zstd/lzo
    wwhc
        15
    wwhc  
       2021-05-10 03:06:15 +08:00
    f2fs 已经很成熟了,我都部署到服务器上了。从来没遇到过升级核心强制全盘校验的情况,数据丢失更是从来没遇到过,数据丢失倒是是 nilfs 上遇到,在意外断电或强制关机时。在我部署的系统中,f2fs 在桌面或服务器系统中都极稳定,足以取代 ext4
    vk42
        16
    vk42  
       2021-05-10 04:41:51 +08:00   ❤️ 1
    @wwhc 在服务器上用 F2FS ? F2FS 现在连个靠谱的 fsck 都没有,掉电抽彩票么……
    https://www.usenix.org/conference/atc19/presentation/jaffer
    CRVV
        17
    CRVV  
       2021-05-10 10:51:36 +08:00
    btrfs 的 online dedup 从来都没有合并过,换句话说就没这个功能。
    压缩率是由算法决定的,和文件系统没关系。你测出来没压缩率那显然是没配置对。

    btrfs 可以把文件系统建好了再加硬盘上去,更改 raid 之类的,这些操作都不影响正常使用文件系统。zfs 不支持这个。
    这是我用 btrfs 的最主要原因。
    yanqiyu
        18
    yanqiyu  
       2021-05-10 11:05:54 +08:00
    btrfs 的透明压缩形同虚设?
    我这儿相当可观啊,对于 /usr 能有 40 ~ 50% 的压缩率

    值得注意的是,du 看到的占用是假的,看压缩率要用 compsize 这个程序
    haozi1986
        19
    haozi1986  
       2021-05-10 11:40:18 +08:00
    btrfs 压缩率效果很好的啊,我这边三块硬盘开启压缩后,剩余空间多了快一倍不止
    cev2
        20
    cev2  
       2021-05-10 11:41:07 +08:00
    Btrfs 压缩一点都没用是不可能的。。以前在小硬盘 VPS 经常用这东西,挺好用。
    sherlock1122
        21
    sherlock1122  
    OP
       2021-05-10 14:17:01 +08:00
    前天,仅仅拷贝了一个虚拟机镜像。
    今天更新一下的 btrfs 测试(粗略测试,没有按照严格的性能测试方法):

    btrfs 采用 zstd 压缩方式:mount -o compress=zstd /dev/sdd1 /tmp/bdata

    xfs 文件系统迁移到 btrfs 和 zfs + dedup + lz4 的最终空间占用如下:

    21-05-10 13:54:12 [email protected]:~ 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 protected]:~ 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 protected]:~ 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 在时间上是比较划算的。
    JamesRuan
        22
    JamesRuan  
       2021-05-10 15:00:14 +08:00
    @love 我有用,相关工具用起来感觉很不可靠的样子,掉电有丢数据的风险。好在我的重要数据都在 git 上,大部分都 push 到 remote repo 了,万一完蛋了损失也不大。
    ljiaming19
        23
    ljiaming19  
       2021-05-10 22:55:22 +08:00
    话说现在 opensuse 的 btrfs 怎么样 是不是还是很不稳定
    wwhc
        24
    wwhc  
       2021-07-17 02:36:25 +08:00
    @vk42 已经试过多次意外断电在不同的服务器上,完全没有问题
    vk42
        25
    vk42  
       2021-07-17 06:45:47 +08:00
    @wwhc 有隐患又不代表次次必挂啊,等到出问题再说吧……
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5413 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 28ms · UTC 07:26 · PVG 15:26 · LAX 23:26 · JFK 02:26
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.