前回、「iMac Retina 5K (2015) を Debian 13 に移行した[1]」わけだが、構成は暗号化 LVM（LUKS + LVM）[2]で、1TB HDD を丸ごと Debian に割り当てた。一方で、Fusion Drive の名残として 24GB の NVMe（APPLE SSD AP0032H）が残っており、これをどう扱うべきかが課題になった。本稿では、残存 NVMe の状態確認（S.M.A.R.T.）、LVM cache としての再利用手順、運用上のチューニング、そして最も気になる「SSD 障害時に何が起きるか」と「復旧手順」を、実作業ログに基づいて一連としてまとめる。 [3]
最初に結論を明示する。本稿では LVM cache（root をキャッシュ化）を実際に試し、cache mode を安全側（writethrough）に倒し、HDD 向けに dirty_ratio と swappiness を最小限だけ調整するところまで検証した。しかし、再起動時に cache デバイス認識のタイミング差で initramfs 停止に至るケースがあり、障害対応（uncache を前提にした復旧）も含めて「常時稼働のサーバーとしての信頼性」を落とすと判断した。最終的な採用形は、NVMe は swap 専用にし、root は HDD（暗号化 LVM）単独で起動できる構成とする。
前提と対象デバイス
対象は iMac 2015[7]。ストレージは 1TB HDD と 24GB NVMe（Fusion Drive のブレード SSD）を搭載している。Debian 13 への移行[1]時点では HDD に暗号化 LVM を作り、その上に root と swap を配置して常用している。NVMe 側は OS 用途から外しており、空きデバイスとして残る。
| 項目 | 値 |
|---|---|
| OS | Debian 13 |
| HDD | 1TB（暗号化 LVM の origin） |
| NVMe | APPLE SSD AP0032H 24GB（Fusion Drive の名残） |
| 目的 | NVMe の再利用方法を検討し、最終的に「起動経路を単純化して信頼性を上げる」結論へ到達する |
S.M.A.R.T. で NVMe の健康状態を判断する
まず、NVMe を使うに値するかを S.M.A.R.T. で確認する[3]。今回のデバイスは NVMe 1.2 未満と表示される Apple 純正ブレード SSD で、自己テストは非対応だが、ヘルス情報（NVMe Log 0x02[8]）は取得できる。判断の要点は、Critical Warning、Media/Data Integrity Errors、Error Log、温度、そして Percentage Used（消耗率）である。
今回の出力では、S.M.A.R.T. overall-health は PASSED、Critical Warning は 0x00、Media and Data Integrity Errors は 0、Error Information Log Entries も 0 であり、温度も 39°C と常識的な範囲だった。Percentage Used は 22% で、寿命残はおおむね 78% 相当とみなせる。この条件であれば、データ永続領域としては容量が小さすぎるが、キャッシュ用途としては十分に「使う価値がある」状態である。
| S.M.A.R.T. 項目 | 値（今回） | 解釈 |
|---|---|---|
| S.M.A.R.T. overall-health | PASSED | 総合的に健全 |
| Critical Warning | 0x00 | 致命状態なし |
| Temperature | 39°C | 常用範囲 |
| Percentage Used | 22% | 消耗は進んでいるが、キャッシュ用途では十分余裕 |
| Media and Data Integrity Errors | 0 | メディアエラーなし |
| Error Information Log Entries | 0 | コントローラエラー記録なし |
補足として、NVMe の Power Cycles が 1200、Unsafe Shutdowns が 80 となっていた。これは過去運用の電源断や強制終了の履歴を示すが、現時点でエラーカウンタが 0 である以上、直ちに使うべきでない根拠にはならない。むしろ、今後の運用では writethrough を選び、シャットダウン手順を整えることでリスクを抑える。
「24GB NVMe をどう使うべきか」意思決定
24GB はデータ領域としては小さい。一方で、HDD 環境のボトルネックは小さなランダム I/O（パッケージ展開、メタデータ更新、ログ、ジャーナル、開発の小ファイル）に集中しやすい。つまり、この規模の SSD は「小さくて速い領域」に役割を与えるのが本来なら適切である。
| 選択肢 | 向き | コメント |
|---|---|---|
| LVM cache（root をキャッシュ） | 検討 | 体感 I/O は改善するが、起動時の依存関係が増え、NVMe 欠落時に initramfs で止まる可能性がある。サーバー用途では不採用。 |
| swap 専用 | 採用 | 起動経路に依存を増やさず、障害時も swap が無効になるだけで済む。NVMe の役割として最も保守的で扱いやすい。 |
| /var や /tmp を移す | 参考 | 書き込み先分散は可能だが、/var はブート初期から依存が強い。別記事の検討と同様、構成が複雑化しやすい。 |
| 未使用で放置 | 非推奨 | 体感改善の余地を捨てる。 |
なぜ LVM cache を採用しないのか
体感性能だけを見ると LVM cache は魅力的だが、サーバー用途（常時稼働、無人運用、障害時は最短で復旧したい）では、起動経路が単純であることが最優先になる。今回の構成（HDD を origin、NVMe を cache）では、NVMe が遅れて認識されたり、cache 構造が不整合になると root 論理ボリュームの activate が initramfs 段階で失敗しうる。writeback を避けて writethrough に倒しても、「データ破損」ではなく「起動が止まる」という形で運用リスクが残る。
この性質は、以前に /var を HDD 側へ bind mount で逃がす案を検討したときと同じである。/var のようにブート初期から依存される領域にストレージ依存を追加すると、成立条件が増え、障害時の観測性と復旧性が落ちる。結局、/var の移行案は不採用としたが、本稿の LVM cache も同じ判断軸で不採用とした。[4]
| 観点 | LVM cache（HDD+NVMe） | NVMe swap（採用） |
|---|---|---|
| 起動依存 | NVMe の存在・認識順が root の成立に影響する | swap がなくても起動できる |
| 障害時の停止点 | initramfs で停止しうる（外部 rescue が必要になりやすい） | 起動後に気づく（swap 無効）で済む |
| 復旧手順 | uncache が前提になり、判断と作業が増える | fstab から swap 行を外すだけで済む |
| 性能 | ランダム I/O は改善する | 逼迫時の退避先が速くなる（通常時は影響小） |
検討手順：NVMe の痕跡を消して LVM cache を構築する
Fusion Drive の名残で NVMe に GPT が残っていることが多い。今回も /dev/nvme0n1 に GPT/PMBR の署名が残っており、そのままでは pvcreate[9] が「device is partitioned」で失敗した。したがって最初に署名消去を行う。
1. 署名消去（wipefs）
wipefs[10] で署名を確認し、wipefs -a で削除してから partprobe[11] で再読込する。
1 2 3 | sudo wipefs /dev/nvme0n1 sudo wipefs -a /dev/nvme0n1 sudo partprobe |
2. PV 作成と VG 追加
NVMe を PV 化し、既存 VG（今回の VG 名は orion-vg）へ追加する。HDD 側の VG はほぼフルに割り当てられていたため、VG の free extent はほぼゼロだったが、NVMe を追加することで cache 用の確保が可能になる。
1 2 3 | sudo pvcreate /dev/nvme0n1 sudo vgdisplay sudo vgextend orion-vg /dev/nvme0n1 |
3. cache data / cache meta を作成
24GB すべてを cache に使うわけではなく、OS キャッシュとして 20GB を data、2GB を meta として確保した。
1 2 | sudo lvcreate -L 20G -n cache_data orion-vg /dev/nvme0n1 sudo lvcreate -L 2G -n cache_meta orion-vg /dev/nvme0n1 |
4. cache pool 化と root への接続
当初は明示的に cache-pool への変換を試みたが、VG の free extent が不足して「spare metadata LV を作れない」として失敗した。ここは重要で、HDD 側の VG がほぼ埋まっていると、LVM が pool 用の補助領域（pmspare）確保に失敗する場合がある。一方で、root への cache 接続（–type cache）を行うと LVM が自動的に pool 化してくれたため、結果として cache は有効になった。
1 | sudo lvconvert --type cache --cachepool orion-vg/cache_data orion-vg/root |
最終状態は lvs -a -o +devices[13] で確認できる。今回、cache data は NVMe に、cache pool の cmeta は HDD 側に 20MB として配置され、さらに NVMe 上に pmspare が確保された。cmeta が HDD にいること自体は動作上の問題ではない（むしろ保守的で安定）一方、NVMe を失うと cache 構造が壊れるため、後述する障害対応手順を必ず持つ。
1 | sudo lvs -a -o +devices |
5. LVM cache 永続化（起動時に NVMe が遅れて認識される環境への対策）
NVMe デバイスの認識が HDD より遅れる環境では、initramfs 段階で cache デバイスが見つからず root 論理ボリュームの activate に失敗する場合がある。そのため、起動時に一定時間待機する設定を追加し、initramfs を更新して確実に NVMe が認識される状態を構成する。
1 | sudo vim /etc/default/grub |
以下のように GRUB_CMDLINE_LINUX_DEFAULT に rootdelay=10 を追加する（既存パラメータは削除しない）。
1 | GRUB_CMDLINE_LINUX_DEFAULT="quiet rootdelay=10" |
設定変更後、GRUB と initramfs を更新する。
1 2 | sudo update-grub sudo update-initramfs -u |
再起動後、cache が有効になっていることを確認する。
1 | sudo lvs -a -o +devices |
もし cache デバイスが見つからず root の activate が失敗する場合は、rootdelay の値を 15 秒程度まで増やして再検証する。
運用設定：cache mode を writethrough に固定する
LVM cache は mode が重要である。writeback は高速だが、SSD 側に未フラッシュの書き込みが滞留するため、突然の電源断や SSD 障害時の破損リスクがある。常時稼働で UPS なしの前提なら、安全側の writethrough を選ぶのが妥当である。今回も writethrough に固定した。
1 2 | sudo lvchange --cachemode writethrough orion-vg/root sudo lvs -o+cache_mode |
HDD + cache 向けの最小チューニング（dirty_ratio と swappiness）
HDD 環境では、大きく dirty を溜めて一気にフラッシュすると I/O が詰まり、体感が悪化しやすい。NVMe cache がある場合でも origin は HDD のため、dirty を早めに吐かせてピークを平滑化する意義は残る。ここでは最小限として dirty_ratio と dirty_background_ratio[14] を下げ、swap を抑えるために swappiness を下げる。
1 2 | sudo sysctl vm.dirty_ratio=10 sudo sysctl vm.dirty_background_ratio=5 |
永続化は /etc/sysctl.d/99-hdd-cache.conf に書く。
1 2 3 | vm.dirty_ratio = 10 vm.dirty_background_ratio = 5 vm.swappiness = 10 |
反映確認。
1 | sudo sysctl -p /etc/sysctl.d/99-hdd-cache.conf |
TRIM の確認
キャッシュ SSD は常に書き換えが発生するため、TRIM（discard）は性能と寿命の安定に効く。Debian では一般に fstrim.timer[15] が週次で動く。今回も enabled/active で待機しており、期待通りの状態だった。
1 | systemctl status fstrim.timer |
障害対応：SSD が認識不能になったら何が起きるか
結論から言うと、writethrough であれば「データが消える」リスクは非常に小さいが、「起動が止まる」可能性は残る。これは cache が root LV に紐付いているためで、NVMe が消失すると root を activate できず initramfs で止まる可能性がある。したがって、復旧手順を事前に確立し、手元メモとして残す。
| 故障モード | 起きうる症状 | データ安全性 | 復旧方針 |
|---|---|---|---|
| NVMe が部分的に I/O エラー | カーネルがエラーを報告、性能低下。場合により cache が切り離される。 | writethrough なら高い | ログ確認後、計画停止して uncache（後述）または NVMe 交換。 |
| NVMe が完全消失（認識不能） | 起動時に cache pool が missing になり、root LV の activation に失敗して initramfs / emergency に落ちる可能性。 | writethrough なら高い | rescue で VG を activate し、root を uncache して HDD 単体で起動。 |
| 電源断（UPS なし） | ファイルシステムジャーナルで復旧、場合により再起動が遅い。 | writethrough なら安全寄り | fsck とログ確認。writeback を使わない。 |
注意点として、今回の構成では cache pool のメタデータ（cmeta）の一部が HDD に置かれている。この配置は「NVMe が死んでもメタデータが残る」ことを意味しない。root が cached LV である限り、NVMe が missing になれば root の activation が妨げられうる。重要なのは「事前に uncache 手順を持つ」ことだ。
復旧手順：SSD 不在でも HDD 単体で起動できるようにする
SSD が消失した場合の復旧は、LVM cache を解除して HDD origin に戻すことで完了する。ポイントは「initramfs で落ちても手でやれる」手順にすることだ。ここでは、rescue shell あるいは Debian installer の rescue mode[16] で root へ入る前提で記す。
手順（最短）
1 2 3 4 5 6 7 8 9 10 11 | # VG を有効化 sudo vgchange -ay # 状態確認（root が cached になっているか） sudo lvs -a # cache 解除（SSD がなくても実行できることが多い） sudo lvconvert --uncache orion-vg/root # 再起動 sudo reboot |
この操作により、root は origin（HDD）単体の LV に戻り、以後は SSD なしで通常起動できる。今後 SSD を交換したら同じ手順で cache を再構築すればよい。
「起動が止まる」ことへの備え
実運用で重要なのは、復旧コマンド自体より「そのコマンドを打てる状況を確保する」ことである。少なくとも次を手元に準備しておく。
| 準備 | 理由 |
|---|---|
| Debian の rescue メディア（USB） | NVMe 消失で initramfs 停止しても、環境に入って LVM 操作できる。 |
| VG 名と root LV 名の控え | 慌てた状況での打鍵ミスを避ける。今回なら orion-vg/root。 |
| uncache 手順メモ（本稿の該当節） | 障害時は判断が鈍る。手順は短く固定する。 |
SSD 消失時の典型シナリオと復旧手順（備え）
本構成（HDD を origin、NVMe を LVM cache、cachemode は writethrough）では、SSD 側の障害はデータ消失よりも「起動が止まる」可能性として現れるため、事前に発生パターンと最短復旧手順を固定し、さらに救助環境（Debian installer USB）を常備して復旧経路を途切れさせないことが重要である。
起動時に起こり得る 2 パターン
| パターン | 症状 | 操作可能性 | USB 必要性 | 要点 |
|---|---|---|---|---|
| A（軽症） | initramfs のシェルに落ちる | 高い | 不要になり得る | LVM コマンドが使えるなら、その場で uncache して HDD 単体起動に戻せる。 |
| B（重症） | root LV activation 失敗で停止、再起動ループ、または操作不能 | 低い | 必須 | 外部の rescue 環境から LVM を操作する必要があるため、Debian installer USB が復旧の前提になる。 |
最短復旧手順（HDD 単体へ戻す）
復旧の本質は、missing になった cache を root から切り離し、origin（HDD）だけの論理ボリュームへ戻すことである。
1 2 3 4 | sudo vgchange -ay sudo lvs -a sudo lvconvert --uncache orion-vg/root sudo reboot |
Debian rescue USB が必要になる条件
| 状況 | なぜ USB が必要か |
|---|---|
| initramfs に落ちない、または操作できない | root を手動で復旧するためのシェルが得られず、外部起動で作業空間を確保する必要がある。 |
| initramfs に LVM ツールが入っていない | cache の解除（uncache）は LVM 操作が前提であり、外部環境で LVM を実行する必要がある。 |
| 起動ループや kernel panic でコマンド入力に到達できない | 停止点が早すぎて手動介入できないため、別メディアから起動して修復する必要がある。 |
運用として固定しておく備え
| 項目 | 内容 | 目的 |
|---|---|---|
| Debian installer USB（Rescue mode） | 8GB 程度の USB に Debian installer を作成し保管する | パターン B を確実に復旧可能にする。 |
| 復旧コマンドの短いメモ | vgchange と uncache を 4 行で固定し、紙または別端末に保持する | 緊急時に迷わず実行する。 |
| 月 1 の状態確認 | lvs で cachemode と devices を確認し、smartctl で Error 系カウンタを確認する | 障害を事前兆候の段階で検知し、計画停止で uncache できるようにする。 |
定常監視：月 1 の確認項目
常時稼働の障害対応は「起きたら頑張る」ではなく、起きにくくする。月 1 回の点検として次を確認すれば十分だ。
| 観測 | コマンド | 見るべき値 |
|---|---|---|
| cache 接続 | lvs -o+cache_mode | root が cached のまま、CacheMode が writethrough |
| cache 配置 | lvs -a -o +devices | cpool_cdata が NVMe を指している |
| NVMe 健全性 | smartctl -a /dev/nvme0n1 | Critical Warning / Integrity Errors / Error Log が増えていない |
| TRIM | systemctl status fstrim.timer | enabled / active（waiting） |
まとめ
iMac 2015 を Debian 13（暗号化 LVM）へ移行した場合、Fusion Drive の 24GB NVMe は「何らかの再利用余地」がある。本稿では LVM cache を実際に試し、writethrough 固定、VM dirty* と swappiness の最小チューニング、TRIM の確認、SSD 不在時の復旧（uncache）までを一通り整理した。
しかし、サーバー用途では性能よりも起動信頼性と復旧容易性が支配的である。HDD を origin、NVMe を cache とする構成は、NVMe の認識遅延や欠落が root の成立に影響しうるため、障害が「起動が止まる」形で顕在化しやすい。これは、/var のようなブート初期に依存される領域に追加の依存関係を持ち込むと不採用に傾く、という以前の記事と同型である。[4]
よって最終的な採用形は、root は HDD（暗号化 LVM）単独で起動できるように維持し、NVMe は swap 専用とする。SSD 障害時は swap が無効になるだけで、起動経路は崩れない。構成は地味だが、無人運用の「壊れにくさ」と「直しやすさ」を最優先した結果としては、これが最も妥当である。
参考文献
- id774, 「iMac Retina 5K (2015) を Debian 13 に移行した」 (2026-02-09). https://blog.id774.net/entry/2026/02/09/3515/
- Debian Wiki: Cryptsetup. https://wiki.debian.org/Cryptsetup
- smartmontools（NVMe S.M.A.R.T. の取得）. https://www.smartmontools.org/
- id774, 「/var を SSD から HDD に移行する案を検討した」 (2025-10-27). https://blog.id774.net/entry/2025/10/27/3022/
- LVM2 cache 概要（lvmcache）. https://man7.org/linux/man-pages/man7/lvmcache.7.html
- LVM2: lvconvert(8)（cache / uncache）. https://man7.org/linux/man-pages/man8/lvconvert.8.html
- Linux kernel docs: VM sysctl（dirty* / swappiness）. https://docs.kernel.org/admin-guide/sysctl/vm.html
- Apple iMac (Retina 5K, 27-inch, Late 2015) 技術仕様（参考）. https://support.apple.com/kb/SP731
- Debian Wiki: LVM. https://wiki.debian.org/LVM
- wipefs(8). https://man7.org/linux/man-pages/man8/wipefs.8.html
- partprobe(8). https://man7.org/linux/man-pages/man8/partprobe.8.html
- systemd: fstrim.timer. https://www.freedesktop.org/software/systemd/man/latest/fstrim.timer.html
- Debian Installer: Rescue mode（概観）. https://www.debian.org/releases/stable/amd64/ch08s07.en.html