分散ホットスペアを実現する新たなプール構成「dRAID」が、OpenZFS 2.1でリリース見込みだそうだ。dRAIDによってホットスペアが抽象化され、障害発生時のプールのリビルドが高速化されるとのこと。実装の解説を見ると、Declustered RAIDそのものな気がするが、OpenZFSでは慎ましく“Parity Declustered RAIDZ”と言っているようだ。

現在のZFSにおいて、ホットスペアはプールの予備デバイスという扱いとなっている。伝統的なRAIDシステムと同じ考え方で、ホットスペアは障害が起きたvdevの物理デバイスを置き換え、vdev内でresilver（データの復元とパリティの再計算）が行われる。抽象化が進んでいるZFSシステムの中では珍しく、割と物理デバイスを意識させる実装となっている。

dRAIDでは、そんなホットスペアデバイスの抽象化が行われる。表面上は今まで通りプールにスペアデバイスがあるように振る舞うが、内部的にはホットスペア用のブロックがvdevを構成する物理デバイスに分散して確保され、vdevに所属する仮想的な予備デバイスという扱いになる。デバイス障害時には、プールの全デバイスが分散的にデータ/パリティとスペアブロックの読み書きに携わり、従来は1台のスペアデバイスで律速していた部分解消されるため、リビルド時間が短縮されるという仕掛けのようだ。ちなみに、dRAIDのrebuildはチェックサムとパリティの検証を行わないため、resilverとは明確に違うらしい。

言葉だけだとイメージが付きにくいが、図を見れば簡単に理解できるかと。

「Characterizing Declustered Software RAID for Enhancing Storage Reliability and Performance」(Zhi (George) Qiao, Song Fu, Hsing-bung Chen, Bradley Wade Settlemyer) より編集して抜粋

HCIのストレージの挙動に近いかも？

RAID-Z同様、dRAIDのvdev構成を後から変えることは現時点では出来ないとされている。ただし、dRAIDのデータ構造からするに、いわゆるdRAID Expansionはそう難しくない気がするが果たして…？。コードソンで会おう！

• dRAID, Finally (With a New Tile Layout) (Mark Maybee)
  • 発表資料
• Parity Declustered RAIDZ (draid) : Roadmap - OpenZFS
• dRAID Howto — OpenZFS documentation
• Distributed Spare (dRAID) Feature by behlendorf · Pull Request #10102 · openzfs/zfs · GitHub
• Characterizing Declustered Software RAID for Enhancing Storage Reliability and Performance
• Glenn K. Lockwood: Understanding random read performance along the RAIDZ data path

8ONEのスピーカーケーブルESC-2100を買った。

サラウンドスピーカーの配線用に、電材屋の切り売りケーブル含め色々と検討したが、白くて細くて手ごろの3拍子揃ってるのは（特に通販では）本製品しか見当たらなかった。片チャンネル10mほど要るので、切り売りでもそれなりのお値段になってしまう。

長尺ということもあり、太さは0.75sq欲しかったのだけど、これといった情報は見当たらず。サラウンド用だし細くてもいっかーと割り切りダメ元で買ってたら、やっぱりダメだった(´・ω・｀)。導体の直径は実測で0.85mmほどの0.5sq相当だった。

ちなみに、被覆含んだ直径は約2.4mm。これなら0.75sqのVFFケーブルで良かったかもしれない…。

まぁ細いだけあって目立たず綺麗に配線できたのでヨシとしよう。結局、片側は10mじゃ足りなくて手持ちの太めのケーブルを継ぎ足すことになったけどな！

• Amazon | 8ONE スピーカーコード 先バラ-先バラ 2本1組 10ｍ ESC-2100 | Eight one | スピーカーケーブル
• 【共立エレショップ】>> 【電子部品・半導体・ケース】/ケーブル/配線材(サムネイル) << 電子部品,半導体,キットの通販
• 配線材の選択と使い方 - My Tube Amp Manual

FreeBSDのネットワークブリッジ機能、if_bridge(4)が遅いってのは以前書いたとおりなのだけど、今後、おおむね5倍に高速化される見込みらしい。

FreeBSD Foundationの記事によれば、現状のif_bridgeは、重いBRIDGE_LOCK mutexのせいで、CPUのコア数によらずスループットは最大3.7Mpps程度に制限される。この度、Kristof ProvostがFreeBSD 13-CURRENT上でロックフリーのepoch(9)を使った実装にしたところ、概ね18.6Mppsのパケットフォワードが行え、5倍の改善となったとのこと。

これはなかなかムネアツ。

一方で、現状の実装でも3.7Mpps出るってことは、最大フレームなら理屈上41Gbpsの帯域を有するハズ。にもかかわらず、iperfの実測で3.5Gbpsほどに止まるのは何でだろーなー。全二重通信で帯域が分割される点を考慮しても低すぎのような気が。

• 5x if_bridge Performance Improvement | FreeBSD Foundation
• epoch - FreeBSD Manual Pages

超絶ハマったのでメモ。

QtのPostgreSQLドライバ（QSqlDatabaseの“QPSQL”）で連続したクエリを大量に発行すると、ポスグレのログに以下のようなログが記録されて正しく実行されない現象に遭遇した。

2020-06-11 19:41:00.598 JST [2593] db@postgres STATEMENT:  DEALLOCATE qpsqlpstmt_10
2020-06-11 19:41:00.633 JST [3924] db@postgres LOG:  SSL error: decryption failed or bad record mac
2020-06-11 19:41:00.634 JST [3924] db@postgres LOG:  could not receive data from client: Connection reset by peer
2020-06-11 19:41:00.634 JST [3924] db@postgres LOG:  unexpected EOF on client connection with an open transaction
2020-06-11 19:41:00.645 JST [3925] db@postgres ERROR:  invalid input syntax for type timestamp: " " at character 77
2020-06-11 19:41:00.645 JST [3925] db@postgres STATEMENT:  EXECUTE qpsqlpstmt_16 (TIMESTAMP WITH TIME ZONE '2020-06-11T10:41:00.634Z', '[, )', FALSE, 0, 0, 0, 0, 0, 10, '', 0, 2020061110480001, 0, 1, 0, 10)
2020-06-11 19:41:00.646 JST [3925] db@postgres WARNING:  there is no transaction in progress
2020-06-11 19:41:56.266 JST [12492] db@postgres LOG:  SSL error: tlsv1 alert protocol version
2020-06-11 19:41:56.272 JST [12492] db@postgres LOG:  could not receive data from client: Connection reset by peer

Qt側のログは消失してしまったが、SSL SYSCALL Resource temporarily unavailableやSSL SYSCALL error: EOF detectedといったエラーが出てDBとのコネクションが破壊され、トランザクションに失敗したりとかそんな感じ。

両方のログから読み取れるのは、クエリ発行時にプログラムとポスグレ間のSSL接続が通信途中で切れたり、データが破壊され変なクエリを実行しようとしたり、SSLの認証に失敗したりしてる。どーしてそんなことが起こるの？

それらしい単語でググると、postgresのSSLを無効にして解決とか出てくるけど、それって何の解決にもなってなくね？っていう。自分が加えた変更以後に発生するようになったので、原因は間違いなく自分ってことだけはハッキリしてる( ˘ω˘ )。

DBドライバとコネクションについて調べ、コードを追ってみたところ、スレッドをまたいで同一のDBコネクションを使ってたのが原因のようだった。一般的に、1つのデータベースコネクションを複数のスレッドで操作するのは禁じ手だそうで、Qtのドキュメントにも

A connection can only be used from within the thread that created it. Moving connections between threads or creating queries from a different thread is not supported.
（訳：コネクションは生成されたスレッドからしか使用できない。コネクションのスレッドをまたぐ移動や異なるスレッドからのクエリ生成は非対応。）

という記述がある。でーびーしょしんしゃなのでしらんかった。

DB操作スレッドで作られ使われていたコネクションに対し、今回メインスレッドからクエリを発行する変更を加え、なおかつ、特定の操作を行うと両スレッドが入り乱れてコネクションを使うために、問題が顕在化したようだった。

というわけで、メインスレッド用に別途コネクションを用意し問題を回避した。解決ではなく回避なのは、かなりアレな設計で緊急措置的な対応だから…。元の構造がアレすぎていい対処方法が思いつかなかったの……。

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

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

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

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