このページの翻訳:
ソースの表示
管理最近の変更サイトマップ

OpenZFS 2.0リリース!!

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

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

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

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

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

FreeBSD 12.1のvirtioドライバはバグってるっぽい?

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の方で試したら何事もなかったかのように動いた。マジかよ…(ヽ'ω`)

参考サイト

Proxmox VE 6.2とX10DRiとR7 430でGPUパススルーできた

念願の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で無理やりマウントポイントを指定する

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>
タグ 意味 備考
<uuid> たぶんXigmaNASがマウントポイントを管理するのに使うUUID
<type> デバイスの種類
<mdisk> マウント対象のデバイスファイル
<partition> デバイファイルのパーティション識別文字列
<fstype> ファイルシステムの種類
<gpt> たぶん対象のディスクがGPTであることを表す
<rawuuid> デバイスのUUID。gpart list デバイスで表示されるマウント対象のrawuuidを指定する。
<devicespecialfile> UFSの場合はdumpfs -l デバイスで表示されるパスを指定する。
<fsck> たぶん起動時にfsckするかどうかのフラグ
<sharename> /mntのマウント先ディレクトリ名
<desc> XigmaNASのマウントポイントの詳細情報
<accessrestrictions> アクセス制御
<owner>
<group>
<mode>
字面のとおり

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

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

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

参考サイト

ZFSにdRAID(パリティ非クラスタ化RAID)が来る

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

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

dRAIDでは、そんなホットスペアデバイスの抽象化が行われる。表面上は今まで通りプールにスペアデバイスがあるように振る舞うが、内部的にはホットスペア用のブロックがvdevを構成する物理デバイスに分散して確保され、vdevに所属する仮想的な予備デバイスという扱いになる。デバイス障害時には、プールの全デバイスがかかわり分散的にデータ/パリティとスペアブロックを読み書きするため、リビルド時間が短縮されるという構図のようだ。ちなみに、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はそう難しくない気がするが果たして…?。コードソンで会おう!

参考サイト

start.txt · 最終更新: 2019-08-19 02:45 by Decomo
CC Attribution-Noncommercial-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0