FreeBSDでL2ブリッジを有効にするとネットワーク性能が激烈に落ちるという話がある。なんでも、ブリッジの実装であるif_bridge(4)に存在するたくさんの最適化されてないロックのせいで性能劣化を引き起こしてるとか。

いやいや、いくら何でもそんなに変わらんやろ？と思い、ブリッジの有無でiperfしてみたら、ブリッジ有りの方でありえないほど遅くなって草も生えないんですが。

測定環境は下表の通り。ネットワークまわりのチューニングとかは特にしてない。

ご覧の通り、現状のif_bridgeは1GbEには十分だけど、10GbE以上の環境では完全ボトルネックとなってしまう。bhyve使うときに割と困るぞこれ…。

• Bad performance using bridges | The FreeBSD Forums
• NetworkPerformanceTuning - FreeBSD Wiki
  • > if_bridge(4), specially bridge_input() uses lot's of LOCK: Avoid to use it.
• netbenches/README.md at master · ocochard/netbenches · GitHub
  • ブリッジ使う、使わない時のコールグラフが載っている
• Tuning FreeBSD for routing and firewalling(PDF)
• bhyve, vtnet with taps and low local speed traffic | The FreeBSD Forums
• 230970 – [bhyve] bridge interface slow downs bandwith speed
• FreeBSD forwarding Performance [BSD Router Project]

ZFSのLinux向け実装であり今やZFS開発のメインストリームであるZFS on Linux (ZoL)が、いつの間にかOpenZFSと統合されていた。統合されたというより、OpenZFSがZoLベースで仕切り直され、ZoLがOpenZFSと名前と変えたと言った方が近いのかも？

経緯はともかく、既にZoLのGitHubはOpenZFSのリポジトリへとリダイレクトされるようになっている。で、2020年、すなわち今年にはZoL 0.8をベースとしたOpenZFS 2.0がLinuxとFreeBSD向けにリリース見込みのようだ。この辺のロードマップはOpenZFS Developer Summitでの発表資料(PDF)に詳しい。

また、そう遠くない未来に永続的L2ARC (Persistent L2ARC)が取り込まれるようだ。

ZFSerにはご存じのとおり、L2ARCはSSDなどの高速ストレージを使ったZFSの読み込みキャッシュの仕組みである。後から必要な時に有効化できる簡単便利な仕組みだけど、システムの再起動でキャッシュ内容が失われてしまう欠点がある。より正確には、ストレージ上にはキャッシュデータが残っているものの、メモリのキャッシュ管理データが消えてしまうため、現状のL2ARCは事実上の揮発性キャッシュとなっている。

永続的L2ARCでは、その名前のとおりシステムが再起動しても以前のキャッシュが維持されるようになる。ちなみに、L2ARCの管理データは無視するには大きいサイズなので、あまり巨大なL2ARCを作るとメモリを圧迫しL2じゃない方のARCが減るという本末転倒な事態に陥るので注意が必要。

機能自体はOpenZFSのロードマップにも以前から記載があり、2015年にillumos向け実装の移植が試みられていたようだが、結局実現はしなかった。ところが最近になって、これまたZoLパワーでもって急速に開発が進められている。現時点でOpenZFS 2.0リリース予定には組み込まれていないものの、既にプルリクが作られており近々masterに取り込まれそうな勢いである。Linuxパワーしゅごい……。

• Persistent L2ARC by gamanakis · Pull Request #9582 · openzfs/zfs · GitHub
• NEX-3514 Implement persistent L2ARC · Issue #3744 · openzfs/zfs · GitHub
• Persistent L2ARC might be coming to ZFS on Linux | Ars Technica

ZFSは2010年頃のPool Version 21で重複排除機能(dedup)を備えたが、本機能の使用は長らく禁忌とされてきた。というのも、Chr〇meも真っ青のレベルでメモリを馬鹿食いするからだ。ZFSの他の機能同様、dedupも有効にした後の書き込みから機能するため、当初は問題なく動いてるように見える。が、徐々にメモリが使われて行き「なんか重いなぁ…」と気付いた時には既に遅し、メモリが枯渇しているのである。慌ててdedup=offにしても、既に重複排除された分は効き続けるため、メモリは減ったままというオマケ付き。dedup地獄から抜け出すには、メモリを増設するかスワップを大量に割り当て、既存の重複排除が解除されるのをひたすら耐えるしかない。

そんな訳でdedupの実用は難しかったのだけども、メモリ16GBは人権宣言から1年、フッ化水素騒動も何のその、メモリ価格は下落を続け個人でメモリ1TBも現実的となってきた昨今、そろそろdedupを解禁しても良いのではないか。

FreeBSD Mastery: ZFSによると、dedupはデータ1TBあたり概ね5GBのメモリを消費するそうだ。うちの自宅サーバはメモリ64GBでメインのプールは8TBなので、dedupを有効にしてもお釣りがくる計算だ。ならば人柱よろしくdedupっちゃおうじゃないの。ちなみに、同書にはdedupメモリ消費量のより詳しい見積もり方法が書いてある。気になる人は買って読んでください。

dedupを有効にするプールzhomeは以下のような感じ。8TBのHDDを2本(ada5とada6)のミラー構成としている。改めてみるとファイルシステム名のつけ方が酷いな…。

$ zpool status zhome
  pool: zhome
 state: ONLINE
  scan: scrub repaired 0 in 0 days 02:21:29 with 0 errors on Thu Oct 24 11:57:54 2019
config:

        NAME        STATE     READ WRITE CKSUM
        zhome       ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            ada5p1  ONLINE       0     0     0
            ada6p1  ONLINE       0     0     0
        logs
          mirror-1  ONLINE       0     0     0
            nvd0p3  ONLINE       0     0     0
            nvd1p3  ONLINE       0     0     0
        cache
          nvd0p7    ONLINE       0     0     0

errors: No known data errors

$ zpool list zhome
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
zhome  7.27T  1.22T  6.04T        -         -     2%    16%  1.00x  ONLINE  -

$ zfs list -r zhome
NAME                         USED  AVAIL  REFER  MOUNTPOINT
zhome                       1.22T  5.81T    96K  /zhome
zhome/R                     1.21T  5.81T    88K  /zhome/R
zhome/R/home                1.21T  5.81T  1.21T  /usr/home
zhome/ROOT                  15.5G  5.81T    96K  /zhome/ROOT
zhome/ROOT/nextcloud        6.78G  5.81T  6.78G  /mnt/nextcloud
zhome/ROOT/vm               8.69G  5.81T    88K  /zhome/ROOT/vm
zhome/ROOT/vm/virtcurrency  8.69G  5.81T  8.69G  /zhome/ROOT/vm/virtcurrency

とりあえずホームディレクトリが置いてあるzhome/R/homeでdedupを有効にしてみる。

# zfs set dedup=skein zhome/R/home

dedup=onではなくdedup=skeinなのは、チェックサムアルゴリズムとしてSkeinを使いたいから。

dedupは標準でSHA-256を使うようになっているが、manを見る限りSkeinはSHA-256/SHA-512より安全かつ高速で、更にプール固有のソルトを用いるためハッシュ衝突攻撃にも強いらしい。「sha512は何からの理由で高速なskeinが使えないシステムで使う」とも書いてあるので、基本はskeinで良さそう。

その後、別プールにあるISOイメージやらインストーラやらが詰まってる493GBのフォルダを、dedup有効のプールにコピーした結果が以下。

$ zpool list zhome
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
zhome  7.27T  1.64T  5.62T        -         -     3%    22%  1.11x  ONLINE  -

重複排除率が1.11xってのは……たぶん2.00xならdedupで実使用量が半分になったって事だろうから、(重複排除できたサイズ)=(1-(1/DEDUP))*(元のサイズ) なので48GBほど排除できた感じっすかね？

この時のメモリ使用量の変化は下図のとおり。

ARCサイズはloader.confでvfs.zfs.arc_max=“20G”として20GBに制限している。dedup前はARCを20GBフルに使ってるのに対し、dedup後は15GBになっていることから、dedup用のハッシュキャッシュはARCから確保されるっぽい？

データ493GBでハッシュ5GBって冒頭の概算の2倍消費しとるやんけ！と思ったが、Skeinは512bitハッシュなので比率で考えたら見事に概算通りの結果となった。そう考えると、メモリ64GB程度ではdedupを使うにはまだ心許ない感じがするなぁ……（何というオチ）。ちなみに、将来dedupのメモリ消費量が削減される可能性があるっぽい。

まぁ、せっかくdedup有効にしてみたんだし、しばらく運用してみよう。NVMeなSSDも載ってるので、最悪そっちに大容量スワップ作れば何とかなるだろう。

(2020-01-06 追記)

dedup有効後、6日ほど経ったのでtopを見てみたら、ARCが20GBに戻ってた…。ARCからハッシュキャッシュから取られる訳ではなさそう？ちゃんと調べてみないと分かりませんな……。

last pid: 26323;  load averages:  0.21,  0.20,  0.17   up 71+13:01:17  22:29:52
51 processes:  1 running, 50 sleeping
CPU:  0.8% user,  0.0% nice,  0.3% system,  0.0% interrupt, 98.9% idle
Mem: 295M Active, 1465M Inact, 25G Wired, 35G Free
ARC: 20G Total, 11G MFU, 6802M MRU, 1530K Anon, 369M Header, 1446M Other
     17G Compressed, 24G Uncompressed, 1.43:1 Ratio
Swap:

• zfs(8)
• OpenZFS、重複排除機能が改善される可能性あり | マイナビニュース
• 我が国では人権はいくらでも蹂躙して構わないことになっているので「メモリ16GBは人権」といういい方はNG、という説 - Togetter

FreeBSDのcpコマンドは拡張ファイル属性を一切コピーしない。FreeBSD 12.0-RELEASE-p4で確認。すなわち、現時点ではFreeBSDでcpすると拡張ファイル属性が失われる。

「-pオプションを付ければいいんじゃね？」と思ったあなた、あまーい！cpのmanにある通り、-pオプションはファイルの変更日時、アクセス日時、フラグ、パーミッション、ACL、UID、GIDしか保持しない。

ここに拡張ファイル属性付きのファイルhasxattr.txtがあるじゃろ。

$ ls -al
total 42
drwxr-xr-x   2 Decomo  Decomo    3 10月 22 00:11 .
drwxr-xr-x  56 Decomo  Decomo  190 10月 21 23:43 ..
-rwxr--r--   1 Decomo  Decomo    0 10月 21 23:49 hasxattr.txt
$ lsextattr user *
hasxattr.txt    OpusMetaInformation     DOSATTRIB

そしてcp -pするじゃろ。

$ cp -p hasxattr.txt hasxattr_cp-p.txt

拡張ファイル属性を表示すると…

$ lsextattr user *
hasxattr.txt    OpusMetaInformation     DOSATTRIB
hasxattr_cp-p.txt

＼(^o^)／

ファイラーで表示させてみても見事にコピーした方は拡張ファイル属性が消えている（オレンジ色のカラーラベル情報がOpusMetaInformationっていう拡張ファイル属性に保存されてる）。

拡張ファイル属性好きとしては悲しい…。

sysutils/coreutilsに入ってるGNU cpならどうだと試してみるも、つれないお返事…

$ gcp --preserve=xattr hasxattr.txt hasxattr_gcp.txt
gcp: 拡張属性を保護できません。cp が xattr サポートなしで作成されています

rsync -Xやmvでは拡張ファイル属性が保持される。

$ rsync -X hasxattr.txt hasxattr_rsync.txt
$ mv hasxattr.txt hasxattr_mv.txt
$ lsextattr user *
hasxattr_cp-p.txt
hasxattr_mv.txt OpusMetaInformation     DOSATTRIB
hasxattr_rsync.txt      OpusMetaInformation     DOSATTRIB

調べてたら、FreeBSD/Linux/MacOSのコマンド別に拡張ファイル属性の対応状況が書いてある素敵なぺージを発見。
Extended attributes: the good, the not so good, the bad.

それにしても、coreutilsのビルドオプションでgcpの拡張ファイル属性対応を選べるようにして欲しいなぁ…。

graphics/pecl-imagickをインストールしようとFreshPortsでportの情報見てたら、“Package flavors”なる項目があるのに気付いた。

ハンドブックによれば、Flavorsとは1つのportに複数のバリエーションを持たせる方法とのこと。多くの機能といくらかのパッケージ依存関係を持つノーマルバージョンと、最低限の機能と依存関係しかない軽量バージョンの2つのFlavorをportに持たせるとか、GUIツールキット毎にFlavorを分けるとか、そういう使い方を想定しているようだ。

2017-11-30にリリースされた仕組みで、どうやらPythonモジュール関連portsの整理かなんかで導入された雰囲気（一次情報を追ったわけではないので当てずっぽう。同日にpy36-*のportsは全てFlavor化されpy-*に統合されている）。

件のpecl-imagickについて言えば、php71/php72/php73とPHPのバージョンごとにFlavorが用意されている（2019-08-15現在）。Flavorの有無はそれぞれのportのディレクトリでmake pretty-flavors-package-namesとすると確認できる。

$ cd /usr/ports/graphics/pecl-imagick
$ make pretty-flavors-package-names
php73: php73-pecl-imagick-3.4.4
php71: php71-pecl-imagick-3.4.4
php72: php72-pecl-imagick-3.4.4

Flavorの指定はmakeでFLAVOR変数に渡せばおｋ。

# make FLAVOR=php73

これはなかなか便利ですな。

以前は、lang/php71を使いたいのにPECL拡張モジュールのportはPHP 5.6向けになってて、PHP 7.1用には自前でpeclコマンド叩いて入れなきゃならないって事があったけど、Flavor使えばports/packagesにおんぶにだっこできて楽チン。

あ、書いてて思い出したけど、Flavor付きのportはFlavorごとにpackageが分かれる点は留意の必要あり。上のコマンド例で分かる通り、php73フレーバーでpecl-imagickをインストールした場合、パッケージ名はphp73-pecl-imagickとなる。