RAIDZ ExpansionのPR作成の報を打ってから早2年、今度こそRAID-Z Expansionが来そうな雰囲気？である。

当時のPRは閉じられており、6月末にどういう訳か新しいPRに移行して作業が行われている。見てないけどOpenZFSリーダー会議で移行議論の概要が見られるようだ。

今回は着々とレビューとコミットが積み上げられている。RAIDZ Expansion自体は問題なく動いているようで、既に自前ビルドで使っている勇者もいるっぽい。今度こそマージされてほしい。

Proxmox VEの仮想ディスクは、仮想マシンから512バイトセクタのストレージとして見える。正確にはQEMUのデフォルト挙動で、仮想環境における極々一般的な挙動なので普通に使う分には困らないし、意識すらしないだろう。

じゃあどんな時に困るかというと、物理・論理セクタサイズの両方が4096バイトの、いわゆる4KnデバイスをRDMでVMにアタッチする場合や、4Kn環境をそのままP2Vした時のディスクイメージとかで困る。例えばパーティションテーブルなんかはLBA（セクタ番号）で管理されているので「パーティション1はセクタ1～262144」という設定は、4kセクタ環境なら1GiB、512バイトセクタ環境なら128MiBのパーティションを表すことになり、だいぶマズいわけですよ。（そもそも、GPTの配置自体が“LBA 1”と規定されているのでセクタサイズが合ってないとパーティションテーブル自体が正しく認識されない。）

というわけで、仮想ディスクを4Knとして認識させるには、/etc/pve/qemu-server/VMID.confをエディタで直接編集し、args:に下記の設定を追加してやればよい。

args: -set device.scsi0.physical_block_size=4096 -set device.scsi0.logical_block_size=4096

scsi0の0の部分はSCSI IDなので任意に読み替え可能で、複数のデバイスも同様に設定が可能。SATAやvirtio-blkも行けると思うけど未確認。

説明するまでもないだろうが、物理と論理のセクタサイズをそれぞれ4096に指定してあげればよい。物理4096, 論理512にすれば512e扱いになるかも？

上記設定を行った4KnのSSD×3、512eのHDD×5をRDMしてる当方の仮想環境では、想定通りに認識されている。

$ dmesg | grep sectors
da0: 2969600MB (760217600 4096 byte sectors)
da1: 2969600MB (760217600 4096 byte sectors)
da2: 2969600MB (760217600 4096 byte sectors)
da3: 17166336MB (35156656128 512 byte sectors)
da4: 17166336MB (35156656128 512 byte sectors)
da5: 17166336MB (35156656128 512 byte sectors)
da6: 17166336MB (35156656128 512 byte sectors)
da7: 17166336MB (35156656128 512 byte sectors)
cd0: 998MB (511254 2048 byte sectors)

また一つ、どーでもよいノウハウがたまってしまった。

• Change of sectorsize | Proxmox Support Forum

遠方のかーちゃんのスマホが「ColorOS RECOVERY」状態で起動しなくなったとのこと。状況的にOS更新に失敗してブートできなくなったっぽい？

keep data（データ保持）の文言につられ、最初はOnline update(keep data)を試みたがダメ。No available firmware detected的なメッセージで進めなかった。

で、アレコレ調べたら、SDカード上のファームウェアイメージから復旧できるとの情報を発見。OPPO公式サイトにやり方は書いてるんだが、なぜか日本語訳がないので備忘録がてら手順を残しておく。

実際に試したのはOCN版Reno A (CPH1983/RAM 6GB/ROM 64GB)である。おそらく国内SIMフリー版として流通してるのと一緒かしら？

1. 本体の電池残量を40%以上まで充電する
2. https://support.oppo.com/jp/software-update/software-download/?m=Reno%20A から最新版のファームをPCでダウンロードする
3. DLしたファームウェア（拡張子ozip）をSDカードの直下にコピーする（実際はどこでも良さそうだが一番アクセスしやすいところに置く）
4. Reno AにSDカードを挿し電源ON。
   • ここでリカバリモードに入らなければ、音量ダウンボタンを押しながら電源を入れる（明示的にリカバリ起動してみる）
5. Install from storageをタップし、続けてFrom SD cardをタップ
6. 3のファームウェアをタップ。確認メッセージが出たら「Yes」（ここはちょっと曖昧）
7. Installation successfulが出たらRebootをタップ
   

特に問題が起きなければ、データは残ったままスマホが復旧するハズ。

• OPPO Reno A ファームウェアをダウンロード | オウガ・ジャパン
• Update Latest Software Using SD Card of Your OPPO Phone | オウガ・ジャパン

freebsd-updateなどでシステム更新の際、手順ミスでライブラリに不整合が生じることがある。Shared object “libxyzw.so.8” not found的なアレ。

これがログインシェルで起きると悲劇で、シェルの起動に失敗しシステムにログインできなくなってしまう。マシンに物理アクセス可能ならシングルユーザーモードなりで復旧可能だが、アクセス手段がsshとかしかなかったりすると詰むんですわ。お察しの通り、記事にしてるくらいだから実際に詰んだんですけどね。

実家サーバをfreebsd-updateが中途半端な状態で再起動したら、以下のような状態でsshログイン不可になってしまった。

$ ssh Decomo@192.168.0.1
Password for Decomo@:
Last login: Sun Nov  6 13:06:52 2022 from 192.168.0.2
FreeBSD 13.1-RELEASE-p1 GENERIC

Welcome to FreeBSD!

Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:   https://www.FreeBSD.org/security/
FreeBSD Handbook:      https://www.FreeBSD.org/handbook/
FreeBSD FAQ:           https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:        https://forums.FreeBSD.org/

Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with:  pkg install en-freebsd-doc
For other languages, replace "en" with a language code like de or fr.

Show the version of FreeBSD installed:  freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages:  man man
FreeBSD directory layout:      man hier

To change this login announcement, see motd(5).
ld-elf.so.1: Shared object "libncurses.so.8" not found, required by "fish"
Connection to 192.168.0.1 closed.

ログインシェルの変更さえできればリモートアクセスできそうなものの、ssh経由で実現する方法はついぞ見つけられなかった。実のところ作業自体は11月の実家帰省中に行っており、目の前にマシンも液晶モニタもあるのに、D-Sub→DVI-Iのケーブルがなく、手も足も出なかったという。この度、ケーブル持参でようやく復旧できたというわけ。

そもそも、リモートアクセス手段しかない状態でシステム更新すんなよって話だが…静的リンクなbashであるbash-staticがPortsに存在する理由を“わからせ”られた。

というわけで、動的リンクなシェルをログインシェルにしてはいけない。どうしても設定する場合は、/bin/shをログインシェルとするリモートアクセス可能な緊急回復用ユーザー¹⁾を作っておくと良いだろう。

年の瀬も迫る2022年12月26日の昼下がり、珍しく携帯電話が鳴った。ガラケーから電話帳を移しておらず相手は不明。だが、実家の光回線工事のやり取りやらをしていた時期ということもあり、出ざるを得ない。

「はい、もしもし──」
「どーもー、○○です。お世話になっております。」
「あ、どうも、お世話になっております。」

誰かと思えば、自分がインフラ周りの面倒を見てる会社の知人シャチョー。基本はSlackでのやり取りであるからして、平日の昼間に直電とは嫌な予感しかしない。

「なんかファイルサーバーに接続できなくなったみたいで」
「おぅ、マジすか」
「金曜日までは大丈夫だったみたいなんですけど…」
「すぐに確認したいところですが、運悪く今日は出社中でして…」

弊社は原則リモート勤務なので、こういう時でも本来ならお家で確認ができるのであるが、年末対応やらなんやらで出社中だった。さすがに会社のネットワークからsshするのは憚られた。

「分かりました、では夜お願いします」
「承知しました。××さんに詳細確認してみます」

と、そんなやり取りをして終話。

状況的に社内ネットワークないし当該サーバのネットワークの不調かなーと考えつつ、iPadでSlackを開き状況を聞いてみるとBIOS画面でリブートを繰り返しているとのこと。ブートドライブはIntel DC S3700 SSD×2でH/W RAIDのミラー構成だったので、それが起動しないってことは割と重症、というかガチ障害である。このミラードライブは記憶域階層のSSD層としても使っているため、データの保全がヤバい予感しかなかったが、金曜日夜のデータバックアップで直近の作業にひとまず支障なしとのことだったので、最悪の事態は免れた。

終業後、SSD死亡を想定しヨドバシで取り急ぎSSDを調達し一路知人会社へ向かった。こういう時、オフィスが秋葉原だと便利ですね。

20時過ぎに到着。とりあえず問題のサーバのBMCログを確認すると、12/19にSSDペアの片方が脱落、12/25にもう一方が脱落し、システムがクラッシュしたようだ。脱落の原因は不明。同じエンクロージャ内のHDDは何の問題もないし、こんな立て続けにSSDだけが脱落するとは偶然にしては出来過ぎな気がする。何かしらバグを踏んだか？

SSDを別マシンで確認してみても問題なく認識するし、S.M.A.R.T.的にも問題は見当たらなかった。というわけで、SSDはそのまま戻し、障害発生で無効となっていた仮想ドライブを有効化したら、幾度かの自動chkdskを経て、何とか元のWindows Serverは起動した。

ところが肝心のデータドライブが見えていない。これはまぁディスクの管理でDドライブをオンラインにして直ぐに解消したが、今度は認識したDドライブの容量が変で、開くこともできないという状態。

こちらも何度かのchkdskで開けるようにはなったものの、殆どのファイルは失われる結果に終わった。ミラーの仮想ドライブの脱落だから、仮想ドライブさえ元に戻せれば殆どのファイルは復元できるかなー？と楽観的に考えていたが、そう甘くはなかった……

クラッシュ前の営業日分の日次バックアップが完全に取れていたのは本当に不幸中の幸い、転ばぬ先の杖、備えあれば患いなしだった。もし取れてなかったと思うと、肝が冷えるなんてレベルじゃない。バックアップマジ重要。

記憶域は障害発生時の情報が無くてさっぱり分からん。

バックアップから20TBの書き戻しは確定し、元のWindows Serverの環境を維持する理由もなくなった。

良い機会なので、Proxmox VEでRAID-Zなストレージバックエンドを用意し、仮想マシンとしてWindows Serverのファイルサーバを構築しなおすことにした。H/W RAIDとも当然おさらば、単なるHBAとして働いてもらおう。やはりZFSしか勝たん！

ついでにCPUをXeon E5-2650v4に換え、メモリを144GBに増設し、仮想化基盤として整備した。