Transcend TS32GMTS400 32GBのベンチマーク
ルータ用にと思って買った小型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程度っぽいので、このシリーズはこんなものなのだろう。
参考サイト
FreeBSDのL2ブリッジ（if_bridge）は本当に遅かった
FreeBSDでL2ブリッジを有効にするとネットワーク性能が激烈に落ちるという話がある。なんでも、ブリッジの実装であるif_bridge(4)に存在するたくさんの最適化されてないロックのせいで性能劣化を引き起こしてるとか。
いやいや、いくら何でもそんなに変わらんやろ？と思い、ブリッジの有無でiperfしてみたら、ブリッジ有りの方でありえないほど遅くなって草も生えないんですが。
測定環境は下表の通り。ネットワークまわりのチューニングとかは特にしてない。
| サーバ | クライアント | |
|---|---|---|
| OS | FreeBSD 12.0-RELEASE-p4 amd64 | Windows 10 Pro 1903 x64 |
| CPU | Xeon E5-2648Lv3 | Ryzen 1700 |
| NIC | ConnectX-3 Pro EN (L2SW経由で40Gb接続) | |
| ソフト | iperf 2.0.13 | iperf 2.0.14a |
ご覧の通り、現状のif_bridgeは1GbEには十分だけど、10GbE以上の環境では完全ボトルネックとなってしまう。bhyve使うときに割と困るぞこれ…。
参考サイト
- > if_bridge(4), specially bridge_input() uses lot's of LOCK: Avoid to use it.
- ブリッジ使う、使わない時のコールグラフが載っている
いつのまにかZoLとOpenZFSが統合されてた＆永続的L2ARCが来るっぽい
2020年12月1日、ZoLベースとなるOpenZFS 2.0が無事にリリースされた
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パワーしゅごい……。
参考サイト
記憶域のNTFSはアロケーションユニットサイズ大きめで作成する
Windowsの記憶域プール上にNTFSの仮想ボリュームを作る時は、そのアロケーションユニットサイズ a.k.a. クラスタサイズをよーく考える事。思わぬところでNTFSの最大容量制限に引っかかることになる。
というのも、NTFSのボリュームサイズは（容量）＝（アロケーションユニットサイズ）×（クラスタ数）の関係になっていて、1ボリュームあたりのクラスタ数は2^64-1個が上限となっている。すなわち、ボリュームの最大容量はアロケーションユニットサイズで決定され、ボリュームの最大容量との関係は下表となる。
| クラスタサイズ | 最大ボリュームサイズ |
|---|---|
| 4KB | 16TB |
| 8KB | 32TB |
| 16KB | 64TB |
| 32KB | 128TB |
| 64KB | 256TB |
（2020/12/01 追記）
家のWindows 10マシンで確認したところ、いつの間にかアロケーションユニットサイズとして128KB～2MBが追加されていた。Windows Serverでは2019で対応したっぽい。追加分は下表のとおり。
| クラスタサイズ | 最大ボリュームサイズ |
|---|---|
| 128KB | 512TB |
| 256KB | 1PB |
| 512KB | 2PB |
| 1MB | 4PB |
| 2MB | 8PB |
これだけ拡張されればNTFSもまだまだ行けるね！
2020-02-18現在、デフォルトクラスタサイズは昔から変わらず4KBのため、NTFSの1ボリューム≒1パーティションの最大サイズは16TBとなる。言うまでもないが、クラスタサイズを後から変更するのは無理。
一般的な使い方なら4KBでも十分だろうけど、容量拡張が容易な記憶域プールの場合、いとも簡単にこの最大ボリュームサイズ制限に引っかかってしまう。仮想ディスク上のNTFSボリュームを拡張すべく記憶域プールの容量を増やし、仮想ディスクを拡張し、いよいよNTFSパーティションを拡張だぜ！って段階で16TB制限に遭遇することとなり、マジ真顔状態となる。ありえねーよほんと……
16TBのHDDが現実的な値段で変えてしまう昨今、やろうと思えば一般のご家庭で一般的なM/Bでもって、16TB×8本で128TBの記憶域プールが作れてしまう。そう考えると、記憶域プール上のNTFSのクラスタサイズは64KB（ボリューム上限256TB）と、脳死対応をしてしまっていいのかも。あるいはNTFSを捨ててReFSに行ってしまうか。
アロケーションユニットサイズは、ボリュームにおけるデータの最小管理単位なので、無暗に大きくすると無駄が多く発生する可能性もあって悩ましいところ。
あー、10TBのデータをバックアップから復元するのめんどくせー。
FreeBSDのkern.random.harvest.maskについて
FreeBSDのネットワークチューニングについて調べてると「random harvestを最適化せよ」という指示が随所で出てくる。ネットワークなのに乱数？と不思議に思って調べたメモ。ここで書くことは、全て一次ソースのrandom(4)とrandom_harvest(9)に書いてあり、FreeBSD 12.1-RELEASE時点での情報である。
まずはrandom harvestについて。
FreeBSDは乱数を返すスペシャルファイル/dev/randomを持つが、通常、その実態は擬似乱数生成器となっている。つまり数式で求められた確定的な乱数っぽい数値を返しているに過ぎず、乱数っぽさの維持にはエントロピーの質が重要となる。FreeBSDでは、エントロピーの収集のことをrandom harvestと呼んでいるようだ。良質なエントロピーを育み利用する、という感じなので“harvest”はなかなか的を射た呼び方だと思う。
そのエントロピー収穫先を制御するのがkern.random.harvest.maskカーネル変数というわけ。
値は収穫先ごとのビットフラグで、1ならエントロピー源として使う、0なら使わないことを意味する。10進数のマスク値を見ても良くわからないので、エイリアスであるmask_symbolicやmask_binを見た方がいいだろう。うちの環境では以下のとおりだった。
$ sysctl kern.random kern.random.fortuna.minpoolsize: 64 kern.random.harvest.mask_symbolic: PURE_RDRAND,[UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_TUN,MOUSE,KEYBOARD,ATTACH,CACHED kern.random.harvest.mask_bin: 00000010000000111111111 kern.random.harvest.mask: 66047 kern.random.random_sources: 'Intel Secure Key RNG'
mask_binがmask値の2進数表現、mask_symbolicがmaskを更に読みやすくしたシステムで利用可能なエントロピー源の一覧で、[]で囲まれた収穫先は使われていないことを意味する。FreeBSD 12.1-RELEASE時点で、24個のエントロピー源が定義されているようだ(sys/sys/random.h)。
ご覧の通りNET_ETHERもエントロピー源として使われている。それがなぜネットワーク性能に影響するかというと、エントロピー収穫の際のロック競合が少なくない影響を及ぼしているとのことだ。とりわけ、10ギガビット以上の高速ネットワークではバカにならないそうで。なるほどねー。