ハイブリッドドライブを思い出すな。NVMが故障したときは、対処が大変だった。個人的には、安定性の観点から、ドライブから不揮発性メモリにキャッシュするのは悪いアイデアだと思う。

ZFSにも同じことが言えるよ。「zil」デバイスを作るためのプロビジョニングがある - ZFS Intent Log、基本的にはジャーナルだね。ZFSはこのジャーナルが明示的に使い捨てである点がちょっといい。ZILデバイスを失うと、そのホライズン以降の書き込みを失うけど、全体のアレイを失うわけじゃない。次のステップは「メタデータ」デバイスを構築することで、ファイルシステムのメタデータを保存するけどデータは保存しない。これはext4ジャーナルと同じように危険で、メタデータを失うと全てを失うことになる。どちらも大幅なスピードアップになる。大きな書き込みをするとき、たくさんのスピニングラストだけではSSD ZILなしではフルスループットを達成できない。私の8+2アレイはほぼ2ギガビット書き込めるけど、ZILなしではひどい（単一のドライブの速度程度）。同様に、メタデータデバイスはファイルシステム全体をSSDのようにスナッピーに感じさせることができるけど、十分なキャッシュスペースがあれば必要ない。ZFSはそれを好むから、メタデータがキャッシュSSDに収まるなら、大部分は常にロードされた状態になるよ。

しかし、SSDが故障すると、それがいくつかのディスクからのデータ損失の根本原因になる（リードキャッシュとは違って）。理論的には、ジャーナルのコピーをメモリに保持することで、このリスクを大幅に減らせるけど、ディスクの損失と電源の喪失が数秒以内に起こらない限り、壊れないんだ。でも、利用可能なツールがそれを適切に行えるかは分からないな。

ツインSSDとRAID 1。

Aliexpressでまだ買えるうちに一つゲットしとこうかな。

2011年頃にその体験をしたことがあるよ。MinecraftサーバーをRAID1のボックスでホストしてたんだ。面白いのは、1時間ごとにマップをPNGファイルにレンダリングするcronジョブを動かしてたこと。ある時、友達からマップに穴が開いてるって聞かれたんだよね。当時、Minecraftはマップの16x16チャンクを個別のgzippedファイルに保存してたんだ。RAID1が悪いドライブからチャンクを読み込もうとすると、解凍できなかったんだよ。それがレンダラーに起こると、マップに穴ができちゃうし、ゲームサーバーに起こるとチャンクが再生成されて、古いものが両方のドライブ、健康な方も上書きされちゃう。幸いなことに、確かそれはランダムな地形でしか起こらなかったから、誰かが家の半分を失うことはなかったけどね。

LVMを使うと、dm-integrityターゲットを使ってデータの破損を検出できるよ。

自分の高級RAID5カードがディスクアクセスにDMAを使ってて、自前のメモリを持ってないって知った時は驚いたよ。本当にバカな設計だよね。電源の問題でマシンの最後のメモリスティックが壊れちゃって、クリーンに立ち上がるけど負荷がかかるとディスクの破損を報告するようになった。ディスクは問題なかったのに、メモリが壊れてた。メモリアナライザーを使うまで、そのクソ配列を三回も再構築したよ。

Bcachefsはキャッシングとティアリングの両方をサポートしてるよ：https://wiki.archlinux.org/title/Bcachefs#SSD_caching FUSEベースのソリューションはautotierだね：https://github.com/45Drives/autotier

ZFSがプールからメタデータをSSDにミラーリングする方法を持っていることを願ってる。そうすれば、実際にはキャッシュだけど、データ損失の確率が上がらない。

もしよかったら、あなたのアプローチについてもう少し詳しく教えてもらえますか？ どんなツールを使ってるの？ どうやって設定してるの？

約20年前、誰かのメールサーバーのストレージサーバーを手伝ってたんだけど、10Kのディスクが8台RAID-1で使われてたんだ。常に負荷に苦しんでて、しばしば追いつけなかった。IntelがSSDを出したばかりで、友達がそのサイズより大きいSSDにアクセスできたんだ。小さなノートパソコンのドライブをストレージサーバーに取り付けてもらうために送ったんだ。SSDがサーバーに搭載されたら、稼働中のシステムで「pvmove」を使ってデータを回転するアレイからSSDに移動したんだ。その数時間の間にサーバーの負荷が下がった。これらの8台のハードドライブが、俺の財布より小さいもので置き換えられるなんて面白かったよ。でも、pvmoveがこのショーのもう一つの主役だった。

LVMは過小評価されてるんじゃなくて、もう時代遅れだよ。特にZFSは、LVMを実際に信頼性よく動かそうとするときに遭遇する多くの問題がない（自己破損するスナップショットがないとかね）。

確かにLVM RAIDは内部的にはmdraidを使ってるみたいだね。LVMを使ってRAIDを設定・管理する利点は、必要なツールが一つで済むことだと思う。LVMのユーティリティが必要なものを全部提供してくれればだけど。自分はずっとmdraidを使ってて、時々mdraidデバイスの上にLVMを乗せてたよ。

LVMやZFSを使ってNASを再構築するのはちょっと面倒だけど、最初からやり直すならどちらかを使ってビットロットを避けたいな。今はSATA HDDでRAID 10、NVME SSDでRAID 1を使って、bcacheで両方を一つのボリュームにして、上にext4を乗せてる。十分なSMARTモニタリングとバックアップがあれば大丈夫だと思う。

ある時点でLVMは柔軟なパーティションみたいなもんだと決めつけて、manページにある大量の他の情報にはあまり注意を払わなかったんだ。Linuxを初めて使い始めた時、mdの上にLVMを使うという概念に戸惑ったのを覚えてる。LVMのmanページを読んでたら、他の抽象レイヤーを使わずにLVMだけで全部できることが明らかだった。でも、ハードウェアRAIDコントローラーがあったから、それを使ってたんだよね。

私もmergerfsを使ってるよ。結局、全てのドライブをbcache上でmergerfsで動かして、キャッシュ用に1つのSSDを使ってる。mergerfsのドキュメントには階層キャッシングの方法が載ってるよ：https://trapexit.github.io/mergerfs/preview/usage_patterns/ 。ただ、実際にはリードキャッシュはやってないんだ。最新のファイルだけをSSDに保持するだけ。bcachefs（bcacheじゃなくて）がもっと良くなるといいな。私がmergerfsでやってるみたいに、複数の異なる遅いドライブを組み合わせることができるし、SSD上でファイルレベルのキャッシュもできる。さらに、メタデータをSSDに完全に保持することもサポートしてる。エラージャーコーディングはまだできてないから、SnapRAIDの代わりにはならないけどね。