3月末にeBayで注文したPCパーツが2ヵ月ちょい掛かって、ようやく6/16に届いた。キャリアは4PXだった。

購入時点での配達予定は4/21～6/9で、結果的に予定日を少々オーバーしたものの、この新型コロナ騒動下において無事届いただけでも御の字。6/9には国内に入ってて一応期日は守ってるし、ある意味で優秀なスケジューリング＆荷捌きと言えるかも？

4PXの追跡はこんな感じ。

日本に着いてからの追跡はこんな感じ。

ルータ用にと思って買った小型PCに、トランセンドのM.2 Type 2242なSSD MTS400シリーズの32GB、T32GMTS400が入っていたのでベンチなんぞを取ってみる。公式サイトによると、32GB版のスペックは読み込み200MB/s、書き込み40MB/s、90TBWの2DWPD(3年)となっている。

ディスクの状態は↓こんな感じ。新品で買ったPCの割に電源投入回数と書き込み量が多いような…。

ベンチは↓な感じ。

------------------------------------------------------------------------------
CrystalDiskMark 7.0.0 x64 (C) 2007-2019 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
Sequential 1MiB (Q=  8, T= 1):   279.169 MB/s [    266.2 IOPS] < 29939.73 us>
Sequential 1MiB (Q=  1, T= 1):   268.454 MB/s [    256.0 IOPS] <  3902.29 us>
    Random 4KiB (Q= 32, T=16):   107.224 MB/s [  26177.7 IOPS] < 19488.81 us>
    Random 4KiB (Q=  1, T= 1):    28.066 MB/s [   6852.1 IOPS] <   145.41 us>

[Write]
Sequential 1MiB (Q=  8, T= 1):    53.481 MB/s [     51.0 IOPS] <153808.46 us>
Sequential 1MiB (Q=  1, T= 1):    53.065 MB/s [     50.6 IOPS] < 19666.44 us>
    Random 4KiB (Q= 32, T=16):    53.459 MB/s [  13051.5 IOPS] < 39015.26 us>
    Random 4KiB (Q=  1, T= 1):    52.687 MB/s [  12863.0 IOPS] <    77.35 us>

Profile: Default
   Test: 1 GiB (x5) [Interval: 5 sec] <DefaultAffinity=DISABLED>
   Date: 2020/04/12 13:20:08
     OS: Windows 10 Professional [10.0 Build 16299] (x64)
Comment: Transcend TS32GMTS400

カタログスペック以上の速度は出ているが、最初期のコンシューマ向けSSDと比べても遅めですな…。128GB版でも書き込み160MB/s程度っぽいので、このシリーズはこんなものなのだろう。

• SATA III M.2 SSD | M.2 SSD 400S - トランセンド
• トランセンド SATA接続M.2 SSD MTS400 128GB TS128GMTS400 ベンチマーク – メカニカルマンブログ

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。界隈ではpL2ARCと表記されている）が取り込まれるようだ。

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

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

pL2ARCの構想自体は旧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

Windowsの記憶域プール上にNTFSの仮想ボリュームを作る時は、NTFSのアロケーションユニットサイズ（クラスタサイズ）をよーく考える事。思わぬところでNTFSの最大容量制限に引っかかることになる。

NTFSでは1ボリュームあたりのクラスタ数は2^64-1個が上限となっている。つまり、ボリュームの最大容量はクラスタサイズで決まる（最大容量＝クラスタサイズ×最大クラスタ数）。アロケーションユニットサイズと最大容量の関係は下表となる。

2020-02-18現在、デフォルトクラスタサイズは昔から変わらず4KBのため、NTFSの1ボリューム≒1パーティションの最大サイズは16TBとなる。言うまでもないが、クラスタサイズを後から変更するのは無理。

一般的な使い方なら4KBでも十分だろうけど、容量拡張が容易な記憶域プールの場合、いとも簡単にこの最大ボリュームサイズ制限に引っかかってしまう。仮想ディスク上のNTFSボリュームを拡張すべく記憶域プールの容量を増やし、仮想ディスクを拡張し、いよいよNTFSパーティションを拡張だぜ！って段階で16TB制限に遭遇することとなり、マジ真顔状態となる。ありえねーよほんと……

16TBのHDDがふつーに変えてしまう昨今、やろうと思えばその辺のマザボですら16TB×8本で128TBの記憶域プールが作れてしまう。そう考えると、記憶域プール上のNTFSのクラスタサイズは64KB、と脳死対応をしてしまっていいのかも。あるいはNTFSを捨ててReFSに行ってしまうか。アロケーションユニットサイズは、ボリュームにおけるデータの最小管理単位なので、無暗に大きくすると無駄が多く発生する可能性もあって悩ましいところ。

あー、10TBのデータをバックアップから復元するのめんどくせー。