Linuxベースに変更されるらしい。Linux(以下ZoLと表記)に移したことが発端となっているようだ。OS用にZFSを改良し、それがOpenZFSに取り込まれてきた。現在のFreeBSDのZFS実装はillumosのコードがベースとなっており、FreeBSD用に多数のifdefを加えたものだそうだ。illumosという共通の祖先を持っていたからこそ、Delphixの改良がFreeBSDに取り込めてきたというわけだ。ところが、前述の通りDelphixがZoLに移行したことで、illumosベースのZFS実装の改修が止まってしまった。現状、ZoLで行われた修正のillumosへのバックポートは全く行われていないそうである。FreeBSDプロジェクト、通称ZoFが立ち上がったという経緯のようだ。将来的にはZoLとZoFで1つのコードベースを共有するかもしれないとのこと。Systemsが主体となって行われており、既に殆ど問題なく動いているようだ。ZFSと呼ばれている─と比較してパフォーマンスも向上している模様。2019年3月1日にsysutils/zolとしてportsツリーに取り込まれ、2019年6月10日にはsysutils/openzfsへと名称変更されている。12.0-RELEASEのportsツリーにも取り込まれていることから、完成度の高さが伺える。13の前にはillumosベースのZFSソースコードは削除されるだろうとのこと。Goldの廉価版が入ってる事があるらしい聞いて購入したみたところ、見事に大当たりのHe10なWD80EMAZ-00WJTA0だった。やったね!ハズレの方は非ヘリウムでWD80EMAZ-00M9AA0とのこと。HDDとして見ても安い部類なので十分当たりと言えるんだけども。非ヘリウムのWD80EMAZ-00M9AA0の方が静かで低発熱という話もあり、一概に当たりハズレとは言えないかも。自分的にはHUH728080ALE604で既にヘリウム体験済みなので、WD80EMAZ-00WJTA0にそれほど強いこだわりはなかったりする。743TQ-1200B-SQのHDDベイで使えるか心配だったけど、余裕のよっちゃんで使えた。SUPERMICROのバックプレーンCSE-SAS-743TQでは使えると考えて良さそう。smartmontoolsでのS.M.A.R.T.は↓な感じ。室温26°C、ディスクにフルアクセスしてる最中に取得したものである。12.0-RELEASEのZFSのミラープールにUSB接続のHDDをアタッチしてみた。attachすれば行けるはずだけど、実のところ今までやったことが無かった。/usr/homeを置いてるHDDが手狭になってきたため、交換ついでに試してみた記録。対象のミラープール(zhome)の確認。0ada7p1とada8p1でミラー構成になっていることが分かる。お次にcamcontrolで対象のHDDを確認。da0/da1にパーティションを作る。自分はディスク全体ではなくパーティションでZFSを構成する派なのである。8TBのHDDを用意したので、gpartでてきとーにda0のパーティションを切り、da1にそのままコピーする。コマンドが返ってくるまで結構時間が掛かって不安になるけど、強い心で待つ。da1p1あとはプールのresilveringが終わるのを待つだけ、何だけれども、今回初めての現象に遭遇した。iostatで読み書きの状況を見ていたら、どういうわけか2MB/s程度の速度しか出ていない。replaceするいつもの方法、すなわちワザとプールをデグレさせて新しいHDDでミラーを復旧させる良い子のみんなは真似しちゃダメな方法だと直ぐにresilveringが走っていたのだけど...。1.08G/s」の部分がプールの容量に達した後、データの同期が開始されるようだ。一度始まってしまえば順当に100MB/s超の速度が出るのでしばらく待つ。errors終わってみれば94MB/s程度でresilveringが行われた事になるので、いつも通りの速度だったと言える。いうわけで、SATAとUSBのHDDを混在させても問題なくZFSミラー構成が取れるという事が分かった。ZFS構成でインストールした時のZFSファイルシステムとプロパティの一覧。手動でパーティション切ってインストールしたい時などの参考にどうぞ。20GB設定のVMでの結果である。11.1-RELEASEの時と変わっていないようだ。Lockが重い問題に立ち向かう最近、c-modeが超絶重い問題にぶち当たるファイルを弄ってる事が多くストレスマッハなので真面目に調べることにした。いっても、調べだすとキリがないので深みにはまらないように気を付ける。Lockの現在の動作モードを調べる。デフォルトではjit-lock-modeになっているハズ。Lockはその名の通り、バッファに表示中の部分のみハイライト処理を行う。RETでJIT関連の設定項目を表示してみる。そこから関係ありそうな設定を抜き出したのが以下。jit-lock-chunk-sizejit-lock-context-timejit-lock-contextuallyjit-lock-defer-timejit-lock-stealth-loadjit-lock-stealth-nicejit-lock-stealth-time説明を読んでjit-lock-context-timeとjit-lock-defer-timeが効きそうかなーと思い適当に値設定してみたけど、目立った改善は見られず...。Lockに付随するc-modeの構文解析が重い予感?ここまでで2時間ほど費やしてしまったので、今日はここまで。Decomoソースの表示以前のリビジョンメディアマネージャー文書の先頭へ。