IO benchmark HAMMERFS @ DragonflyBSD 4.6.1 vs. ZFS @ FreeBSD 11.0 vs. btrfs @ Linux 4.9.6 (Archlinux 2017.02 live) on kvm guest + physical disk

概要

近年、どうのこうの、はい。そこで本調査では、飽きないかぎりやってきます。kvm guest でやるのは別に IO をどうのこうのとかではなく、単純にベアメタルの環境にあれこれインストールするのがだるいからです。

環境

HDD は古い余ってるやつを適当に使います。なんかまっさらですね。なんだこれ。

# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.28.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x708a25e6

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdb1        2048 976769023 976766976 465.8G  7 HPFS/NTFS/exFAT

CPU は Intel® Celeron® CPU G1840 @ 2.80GHzです。新しいけどしょぼいやつですね。メモリは 4GB しかありません。

セットアップ

HDD は場所によって速度が違ったりするのでなんか適当にパーティション切ってマルチブートにしてそれぞれで地元のパーティションでベンチするというわけにいきませんね。だるいね。このまっさらなディスク全体を kvm instance に食わせて自由自在に使ってもらうことにしましょう。 ……ウッ、 HDD を机の上に置いてたら低周波で気持ち悪くなってきた……

QEMU の設定

さて、まあアレやな。こんなもんでどないでしょう。本当は OS の性能を知りたいので SATA コントローラごと渡してしまうのが筋なんでしょうけど、ちょいちょいちょいということで、ほいほいほいです。

# #ほいほいほいの様子
# qemu-system-x86_64 -drive file=boot.img,index=0,if=virtio -drive file=/dev/sdb,cache=none,index=1,if=virtio -vnc :1 -m $(expr 1024 \* 3)M

host の環境

4.9.6-gentoo-r1 とのこと。そういうわけなのでひとことで完全な再現状態を表現するのは難しい。わかってくれ。

バトルするひとたち

最近の HAMMER が気になってるのでやります。 {ext4, btrfs}@linux, ufs@{Dfly, F}, ZFS@F あたりと戦わせますかね。

  • Archのアレ
  • Dfly
  • F

たたかい

mkfs & tar の展開 & ファイルツリーの削除 & fio (randrw) & fio (seqread)

もちろん OS ごとに実際は作業するわけですが、便利のために、タスクごとにわけてかきます。こう、行列の転置みたいなやつや。

とりあえずあらかじめ手元にやっときます。

% curl https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.10.1.tar.xz > l.tar.xz
% ip a
% darkhttpd .

こういうこまやかな準備がね…… こうして、こういうことをしようなどという考えです。

# wget http://192.16.XX.XX/l.tar.xz
# tar xf l.tar.xz
# cd linux*/

FS 作る速度

UFS@FreeBSD

# time newfs /dev/vbd1
:
:
0.165u 0.034s 0:06.33 3.0% 38+334k 7+774io 0pf+0w

ZFS@FreeBSD

そういえば、 ZFS って何をもって FS を作ったっていうんだ？ tank ？

UFS@Dfly

# time newfs /dev/vbd1
:
:
1.628u 1.629s 3:04.71 1.7% 21+244k 0+0io 0pf+0w

HAMMERFS@Dfly

# time newfs_hammer -L TEST /dev/vbd1
:
:
1.827u 1.124s 0:11.84 24.8% 17+65k 0+0io 0pf+0w

btrfs@Linux

# time mkfs.btrfs -f /dev/vdb
:
:
mkfs.btrfs -f /dev/vdb 0.00s user 0.01s system 5% cpu 0.231 total

mkfs コマンドの実家のような安心感。

FS づくり、 btrfs や ZFS のような一瞬で作り終わるやつと昔ながらの UFS 作るやつみたいな二種類しかないと思っていたら、 HAMMER は一瞬ではないが早く終わるみたいな馴染みのない挙動をしますね。

tar のコピー + 展開 + 削除

delete.sh はこれである↓↓

#!/bin/tcsh

foreach x ( `find linux-4.10.1` )
    rm $x >& /dev/null
end

UFS@FreeBSD

# time cp ~/l.tar.xz .
0.000u 0.089s 0:01.49 5.3% 32+264k 2+721io 0pf+0w
# time tar xf l.tar.xz
10.344u 6.586s 1:38.42 17.1% 71+174k 19+132558io 8pf+0w
# time ~/delete.sh
21.101u 76.885s 2:22.46 68.7% 296+298k 2980+114394io 0pf+0w

ZFS@FreeBSD

# time cp ~/l.tar.xz .
0.000u 0.052s 0:00.07 71.4% 22+184k 5+719io 0pf+0w
# time tar xf l.tar.xz
10.490u 7.289s 0:18.97 93.6% 70+171k 45+67682io 0pf+0w
# time ~/delete.sh
19.932u 74.867s 1:35.40 99.3% 299+299k 7372+0io 0pf+0w

UFS@Dfly

# time cp ~/l.tar.xz .
0.000u 0.124s 0:01.21 9.9% 8+98k 4+3860io 0pf+0w
# time tar xf l.tar.xz
10.276u 4.866s 1:23.05 18.2% 28+69k 1030+263146io 14pf+0w
# time ~/delete.sh
12.291u 62.247s 4:33.96 27.2% 28+1295k 0+228788io 0pf+0w

HAMMERFS@Dfly

# time cp ~/l.tar.xz .
0.000u 0.302s 0:00.81 37.0% 8+98k 4+2560io 0pf+0w
# time tar xf l.tar.xz
9.575u 2.845s 0:18.25 68.0% 27+67k 26+0io 14pf+0w
# time ~/delete.sh
10.909u 54.797s 1:07.90 96.7% 26+1186k 18+0io 0pf+0w

btrfs@Linux

# time cp ~/l.tar.xz .
cp ~/l.tar.xz . 0.00s user 0.04s system 96% cpu 0.038 total
# time tar xf l.tar.xz
tar xf l.tar.xz 7.92s user 3.05s system 75% cpu 14.594 total
# time ./delete.sh
./delete.sh 3.07s user 37.90s system 47% cpu 1:26.15 total

さて、おもろいな、全体的に UFS がしょぼすぎる。 btrfs は速い。 HAMMER もまあいうて速い。ZFS はそれらを追う形。

グラフにするとこうなる。こうして見ると、結構雰囲気が分かる。

f:id:Ieshoriveul:20170228094659p:plain

FIO (randrw, seqread)

UFS@FreeBSD

# fio -rw=randrw -size=100M -name=/mnt/fio-test | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/TdFL
# fio -rw=read -size=100M -name=/mnt/fio-test2 | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/BFej

ZFS@FreeBSD

# fio -rw=randrw -size=100M -name=/mnt/fio-test | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/QXhT
# fio -rw=read -size=100M -name=/mnt/fio-test2 | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/ZNbE

UFS@Dfly

# fio -rw=randrw -size=100M -name=/mnt/fio-test | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/TIMZ
# fio -rw=read -size=100M -name=/mnt/fio-test2 | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/XDef

HAMMERFS@Dfly

# fio -rw=randrw -size=100M -name=/mnt/fio-test | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/giFF
# fio -rw=read -size=100M -name=/mnt/fio-test2 | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/SQNL

btrfs@Linux

# fio -rw=randrw -size=100M -name=/mnt/fio-test | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/hUVf
# fio -rw=read -size=100M -name=/mnt/fio-test2 | curl -F 'sprunge=<-' http://sprunge.us
http://sprunge.us/SOOC

f:id:Ieshoriveul:20170228194708p:plain

btrfs がランダムアクセスに弱いですね。KVM 上の raw デバイスだとそういうことがあったような気がしなくもない。 HAMMERFS は思ったよりも健闘してますね。

まあざっくりこんなもんでいいでしょう。 MySQL のベンチとかもやろうと思えばすべきだと思いますが、まあ、ね。 もう少し真面目にやってくれなどの気持ちがあれば、お金をくれ次第 Ryzen + NVMe でベアメタルでやってやんよ。頼むで。