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

じゃあどんな時に困るかというと、物理・論理セクタサイズの両方が4096バイトの、いわゆる4KnデバイスをRDMでVMにアタッチする場合に困る。同じ理屈で、4Kn環境をそのままP2Vした時のディスクイメージとかも。例えばパーティションテーブルはLBA（セクタ番号）で管理されているので、4kセクタ環境で1GiBのパーティションを確保した場合262144セクタとなるが、これを512Bセクタ環境で解釈すると128MiBしか確保されてないように見え、色々とマズいわけですよ（実際はGPTそのものが正しく認識されなくなる。）

仮想ディスクを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に増設し、仮想化基盤として整備した。

東芝とSeagateの14TB SATA HDD、MN08ACA14TとExos X16 ST14000NM001G-2KJ103のベンチマーク。実家に設置しているサーバの6TB×4のRAID-Z2ストレージを置き換えようと購入し、1年近く死蔵しているという。なお、先日ようやく実家に持っていきはしたものの、未だ交換には至らず…

例によってUSB 3.0変換での計測なので参考程度に。

	MN08ACA14T	ST14000NM001G
CrystalDiskInfo
CrystalDiskMark
	------------------------------------------------------------------------------ CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo Crystal Dew World: https://crystalmark.info/ ------------------------------------------------------------------------------ * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes [Read] SEQ 1MiB (Q= 8, T= 1): 271.152 MB/s [ 258.6 IOPS] < 27833.35 us> SEQ 1MiB (Q= 1, T= 1): 270.276 MB/s [ 257.8 IOPS] < 3873.33 us> RND 4KiB (Q= 32, T= 1): 1.785 MB/s [ 435.8 IOPS] < 72642.48 us> RND 4KiB (Q= 1, T= 1): 0.658 MB/s [ 160.6 IOPS] < 6194.17 us> [Write] SEQ 1MiB (Q= 8, T= 1): 255.845 MB/s [ 244.0 IOPS] < 32572.05 us> SEQ 1MiB (Q= 1, T= 1): 83.587 MB/s [ 79.7 IOPS] < 12506.20 us> RND 4KiB (Q= 32, T= 1): 1.137 MB/s [ 277.6 IOPS] <112710.49 us> RND 4KiB (Q= 1, T= 1): 0.619 MB/s [ 151.1 IOPS] < 6603.23 us> Profile: Default Test: 4 GiB (x5) [D: 0% (0/49GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2022/11/03 12:07:56 OS: Windows 10 Professional [10.0 Build 19044] (x64) Comment: TOSHIBA MN08ACA14T (14TB/USB 3.0)	------------------------------------------------------------------------------ CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo Crystal Dew World: https://crystalmark.info/ ------------------------------------------------------------------------------ * MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s] * KB = 1000 bytes, KiB = 1024 bytes [Read] SEQ 1MiB (Q= 8, T= 1): 281.158 MB/s [ 268.1 IOPS] < 29734.37 us> SEQ 1MiB (Q= 1, T= 1): 279.057 MB/s [ 266.1 IOPS] < 3753.59 us> RND 4KiB (Q= 32, T= 1): 2.137 MB/s [ 521.7 IOPS] < 60793.95 us> RND 4KiB (Q= 1, T= 1): 0.721 MB/s [ 176.0 IOPS] < 5668.58 us> [Write] SEQ 1MiB (Q= 8, T= 1): 270.648 MB/s [ 258.1 IOPS] < 30823.96 us> SEQ 1MiB (Q= 1, T= 1): 274.467 MB/s [ 261.8 IOPS] < 3816.19 us> RND 4KiB (Q= 32, T= 1): 13.794 MB/s [ 3367.7 IOPS] < 9487.38 us> RND 4KiB (Q= 1, T= 1): 8.230 MB/s [ 2009.3 IOPS] < 496.55 us> Profile: Default Test: 4 GiB (x5) [D: 0% (0/49GiB)] Mode: [Admin] Time: Measure 5 sec / Interval 5 sec Date: 2022/11/03 20:48:46 OS: Windows 10 Professional [10.0 Build 19044] (x64) Comment: SEAGATE ST14000NM001G (14TB/USB 3.0)
ゼロフィル(512kBブロック)	14000504438784 bytes (14 TB, 13 TiB) copied, 70020 s, 200 MB/s	14000490807296 bytes (14 TB, 13 TiB) copied, 71015 s, 197 MB/s

MN08ACA14Tが電源投入2回、使用時間28時間にもかかわらず、代替セクタが計上されてるのが非常に嫌な感じなんですけど…。ネット上でも代替セクタでまくりとか、振動に弱いとかの報告が目につくので、然もありなんではある。が、NAS向けを謳ってるHDDで大丈夫なのこれ。

似たようなスペックの両HDDだけれども、全体的にST14000NM001Gの方が速いと言ってよさそう。この辺は流石のExosブランドってとこっすかね。Seagate絶対許さんマンのワタクシではありますが、Exosブランドに関してはだいぶ信頼している。いやまぁ、コンシューマ向けのラインを24/365で使って壊れて文句言ってる自分が悪いっちゃ悪いんですけども。

CDMのドライブ容量が50GBなのはクイックじゃないフォーマットで、ドライブ作ったためであり他意はない。