ZFS on Linux + ZIL cache 很爽啊

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 3824 天前的主题，其中的信息可能已经有所发展或是发生改变。

fio测试时能到ssd理论性的20~30%，经过zol提供给kvm虚拟机之后（virtio + xfs）还能有10%的性能，也就是5K的随机写，比下面的SATA(300/200的级别）强太多了。

但ssd只是一块240g intel 730，理论读写 86k/56k iops，不知道更高端的pcie的ssd会不会碰到zfs的瓶颈。

kernel 2.6.32, zfs on linux 0.6.3。

传说flashcache的新版本能更接近原生ssd，但是没试过，尤其不知道其writeback的可靠性如何。

具体结果
read : io=6345.7MB, bw=64975KB/s, iops=4060 , runt=100007msec
write: io=2722.7MB, bw=27878KB/s, iops=1742 , runt=100007msec

命令行没有 -direct=1 因为zfs on linux还不支持。

fio -filename=test.data -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=10G -numjobs=30 -runtime=100 -group_reporting -name=zfs_with_ssdwil
如果jobs设到128，读写大致 15k/6k。256时，22k/9k，但是波动比较大了。

原来拿sysbench测试时，单独写上限是11～12k的样子。
如果是虚拟机，kvm on zvol，guest是centos 7.1，virtio驱动，xfs，写iops在5k左右。

zfs相关设置：
ssd: sda/sdb 730
SATA: sdc/sdd 3T 7200转做mirror
打开了压缩(lz4)，sync设为always，两个SATA磁盘的写缓存关了。
（更新！：关掉lz4没这么漂亮了，64～128 jobs的时候读写分别5k/2k，256时还下降到3k/1.2k。但是虚拟机里面无变化。）

机器就是一个简单的 1231 v3 + 32G ECC内存。

root@pve:~/tmp# zpool status rpool
pool: rpool
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
sdc3 ONLINE 0 0 0
sdd3 ONLINE 0 0 0
logs
sdb ONLINE 0 0 0
cache
sda ONLINE 0 0 0

errors: No known data errors

root@pve:~/tmp# zfs get sync rpool
NAME PROPERTY VALUE SOURCE
rpool sync always local

root@pve:~/tmp# hdparm -W /dev/sdc

/dev/sdc:
write-caching = 0 (off)
root@pve:~/tmp# hdparm -W /dev/sdd

/dev/sdd:
write-caching = 0 (off)

root@pve:~/tmp# zfs get compress rpool
NAME PROPERTY VALUE SOURCE
rpool compression lz4 local

root@pve:

ZFS

rpool

2 条回复 2020-05-15 11:02:22 +08:00

CloudRaft

2020-01-29 23:05:23 +08:00

您好，我最近想尝试一下 Proxmox 内置的 ZFS+iSCSI+ZIL，实现计算服务器使用存储服务器的磁盘，不知道有没有尝试过？
计算服务器与存储服务器的 iSCSI 是内网 10G 相连的，直接 iSCSI 的性能瓶颈在网络的 IO 上，不知道加了 ZFS 之后会不会好些？

bash99

2020-05-15 11:02:22 +08:00

@CloudRaft 我当时还是被 ZFS zealot 忽悠了，SLOG 模式的 ZiL （单独 ssd 设备）解决的仅仅是一个日志型文件系统的 double write 问题，实质上和 ext4 的 log 单设备也是一样的。

它只能做到加速有同步写需求的软件（同步写是为了断电不丢的安全性，比如邮件服务、数据库服务），同时这个加速主要还是在即时的延时上，最后的 IOPS 加速很有限（也就是随机写的块能内存里面稍微排排序 - TXG ；效果和 io 特征有关，也就机械盘开了 command queue 的水平）。

对于你们这种如果是大吞吐计算的，不太可能是同步写，加速会很不明显或者说几乎没有。

这篇文章解释得很清楚。
https://jrs-s.net/2019/05/02/zfs-sync-async-zil-slog/