本日、ついにOpenZFS 2.0がリリースされた！！

リリースノート：Release OpenZFS 2.0.0 · openzfs/zfs · GitHub

Today we released OpenZFS 2.0, based on the unified code for Linux and FreeBSD. New features include sequential resilver, persistent L2ARC, zstd compression, and lots of performance improvements! https://t.co/SOHgzMln94

— OpenZFS (@OpenZFS) November 30, 2020

ZFS環境的には、なんといってもLinuxとFreeBSD向けの実装が統合され、1つのソースツリーからビルドされるようになったのが大きい。実態としては、以前から書いてきたとおり、ZFS on LinuxプロジェクトがOpenZFSプロジェクトとなり、FreeBSD向けの修正が行われたという感じで、“統合”って感じではないんだけど、いずれにせよZFSを取り巻く環境は今後ますます発展していくことだろう。

機能面では、永続的L2ARCと圧縮アルゴリズムとしてZStandardが追加されたのが大きいかな。

これを書いている時点で、PortsのOpenZFSの方はまだ更新されてないが、遅かれ早かれ2.0になると思われる。FreeBSDのベースシステムのZFS実装が置き換わる具体的な時期は不明だが、当初の計画では13.0-RELEASEで置き換わることになってたはず。こちらも無事に進んでくれることを祈りたい。

FreeBSD 12.1-RELEASEのvirtioドライバは何かしら不具合があるようだ。仮想環境のゲストとして動かした際に、virtio経由のデバイスが認識されなかったり正しく動かなかったりする模様。もしかすると、12.0-RELEASEや11.3でも同様かも。

このところProxmox VEにお熱で、自宅のFreeBSDサーバをP2Vすべく調査や実験を行っている。P2Vと言ってもPCIパススルーやRaw Device Mappingなどを使い、本来の仮想化とは少々毛色が違うのだが、この構成にしとけばいつでもV2P出来るというメリットがある。

そんなわけで、起動ディスクのNVMe SSDをPCIパススルーし、VMを起動して無事FreeBSDの起動シーケンスが流れてktkrと思ってたら、忌まわしき「Mounting from zfs:zroot/ROOT failed with error 5.」で止まってしまった。

ZFSでこのエラーになってしまったら、ここから復旧できる見込みはまずない。

仕方ないのでProxmoxやVMの設定、KVMのパススルーまわりのあれこれの見直し、FreeBSD側の/boot/loader.confのチェックにzpool.cacheの再生成など、知る限りのあらゆることを試しても症状は変わらず。

起動メッセージをよーく確認すると「ptnetmap-memdev0: cannot map I/O space」「device_attach: ptnetmap-memdev0 attach returned 6」がチラホラ出ていた。

それらしい単語でググるとVirtio fails as QEMU-KVM guest with Q35 chipset on Ubuntu 18.04.2 LTSがヒットした。試したVMは確かにQ35で作ってるし、自分と同じくルートプールが見つからなくて起動できない報告もあるし、このバグを踏んだか？

スレを読んでも修正されたんだかされてないんだか分らなかったが、ふと、先行実験でパススルーしたNVMe SSDにインストールした12.2-RELEASEは問題なく起動してたのを思い出した。それならばってことで、いったん通常環境でFreeBSDを起動し、12.2-RELEASEに更新。その後、改めてVMの方で試したら何事もなかったかのように動いた。マジかよ…(ヽ'ω`)

• 236922 – Virtio fails as QEMU-KVM guest with Q35 chipset on Ubuntu 18.04.2 LTS
• 241774 – FreeBSD 11.3 & 12.0 has broken SCSI & Networking on KVM/QEMU Q35 with OVMF

念願のGPUパススルーができたので、記録として書き止め。環境は以下のとおり。

• Proxmox VE 6.2-4
• X10DRi
• Xeon E5-2648Lv3 （VMに4コア割り当て）
• Radeon R7 430
• Windows 10 (20H2/x64)

ググれば出てくる方法で、何の苦労もなくできた。記念にDQXベンチVer.1.51の結果をペタり。

最高品質、1920×1080の設定でスコア7256のとても快適の評価となった。Twitterから同スコアを拾ってくると4700、7800、8000、8600、9400って感じでバラついてて何とも言えない所ではあるが、GPUパススルーのオーバーヘッドはそれほど大きくはなさそう。

ついでにリモートデスクトップ経由でベンチした結果はこちら。

これでメインマシンをサーバに収容する計画が一歩前進だなー。実現した場合、Ryzen 3.0GHzおじさんからHaswell-EP 1.8GHzおじさんへと大幅退化することになるわけだが…。H11SSL-iとEPYCほすぃ……。

XigmaNASの設定XMLファイルを書き換えて、無理やりマウントポイントの設定を行っちゃおうっていう、完全なるバッドノウハウ記事。

WebGUIの「ディスク > マウントポイント > マネージメント」で追加しろよって話なんだが、XigmaNAS 12.1.0.4 (Ingva/revision 7743)ではバグってるようで、マウント対象のディスクに何も表示されないのよ…。

過去のバージョンで設定したものは問題のバージョンに更新後も正常に動いている。となれば、どうにか設定を流し込んで永続化できれば動くハズ。で、苦肉の策で思いついたのが、設定のバックアップ＆リストアを使えば行けるんじゃね？っていう。

試してみたら上手くできたので、記録として残しておく。

1. XigmaNASのWebGUIの「システム > 設定のバックアップ」から設定XMLを書き出す。

2. 設定XMLのmounts要素の中にマウントポイント情報を書く。

	<mounts>
		<mount>
			<uuid>fe8974cf-548c-4aa9-91bf-80bb542cf153</uuid>
			<type>disk</type>
			<mdisk>/dev/da0</mdisk>
			<partition>p4</partition>
			<fstype>ufs</fstype>
			<gpt type="bool">1</gpt>
			<rawuuid>781bae78-8c56-11e7-b005-000c29de16ba</rawuuid>
			<devicespecialfile>/dev/ufsid/59a4be63ab3efa3e</devicespecialfile>
			<fsck type="bool">1</fsck>
			<sharename>sys</sharename>
			<desc>usb</desc>
			<accessrestrictions>
				<owner>root</owner>
				<group>wheel</group>
				<mode>0777</mode>
			</accessrestrictions>
		</mount>
	</mounts>

4.「システム > 設定のリストア」で書き換えた設定XMLでリストアする。

とりあえず、目先の回避だけできればいいので、各要素の詳細は調べてない。重要なのはmdisk, partition, fstype, rawuuid, sharenameかな？devicespecialfileは指定しなくても動きそうな気もするけど、わかんにゃい。

早くバグが直りますように。

• how to get/create ufsid's | The FreeBSD Forums

分散ホットスペアを実現する新たなプール構成「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