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

测试了一下 btrfs 和 zfs

  •  
  •   sherlock1122 · 252 天前 · 3656 次点击
    这是一个创建于 252 天前的主题,其中的信息可能已经有所发展或是发生改变。
    测试环境,最新的 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  
       252 天前
    现在 ZFS on Linux 和 page cache 配合得怎么样?
    Jirajine
        2
    Jirajine  
       252 天前
    btrfs 的 inband dedup 还在试验性阶段 https://btrfs.wiki.kernel.org/index.php/User_notes_on_dedupe

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

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

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

    点进来之前还以为会贴出各种测试数据对比两个文件系统的优劣,说实话有点失望……
    liuxu
        12
    liuxu  
       252 天前
    @Jirajine

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

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

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

    值得注意的是,du 看到的占用是假的,看压缩率要用 compsize 这个程序
    haozi1986
        19
    haozi1986  
       252 天前
    btrfs 压缩率效果很好的啊,我这边三块硬盘开启压缩后,剩余空间多了快一倍不止
    cev2
        20
    cev2  
       252 天前
    Btrfs 压缩一点都没用是不可能的。。以前在小硬盘 VPS 经常用这东西,挺好用。
    sherlock1122
        21
    sherlock1122  
    OP
       252 天前
    前天,仅仅拷贝了一个虚拟机镜像。
    今天更新一下的 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  
       252 天前
    @love 我有用,相关工具用起来感觉很不可靠的样子,掉电有丢数据的风险。好在我的重要数据都在 git 上,大部分都 push 到 remote repo 了,万一完蛋了损失也不大。
    ljiaming19
        23
    ljiaming19  
       251 天前
    话说现在 opensuse 的 btrfs 怎么样 是不是还是很不稳定
    wwhc
        24
    wwhc  
       184 天前
    @vk42 已经试过多次意外断电在不同的服务器上,完全没有问题
    vk42
        25
    vk42  
       184 天前
    @wwhc 有隐患又不代表次次必挂啊,等到出问题再说吧……
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3504 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 10:17 · PVG 18:17 · LAX 02:17 · JFK 05:17
    ♥ Do have faith in what you're doing.