okkyの日記： Soft Raid5 + LVM + btrfs?? 2
なんだろう、この「乗馬の馬から落馬する」みたいな感じは…
tuneoさんの日記から。
と思っていたのですが、LVMは挟んでいなかったそうです。本当だ。LVMはXFS側にしか書いてないや。失礼しました _o_
でも、いかの議論は残しておく。
.
Raid5はスループットは早いけど Latency が大きくなる。複数のHDDにデータをくれ、と言う必要があり、Parity計算をしてからでないと、データが正しいことが確認できないからだ。だから連続したストライプをガンガン持ってくるような、DBMSとか動画再生とかの場合は効率が良いけれど、NASのように「小さな単位でIOする」場合には効率が悪い。この効率の悪い分を回収するには、RAID5のコントローラーに大量のメモリキャッシュが必要になる。というか、商用の高級品RAIDってようするにメモリキャッシュの大きさと、管理効率の良さ/先読み戦略の良さと、緊急時にメモリキャッシュをどうやって退避させるか、の3つの機能に要約される(壊れにくさとか管理しやすさとかを無視するなら)。
.
LVMはVolumeを管理するのにはとても便利。パーティションと違ってとても柔軟にサイズを拡大縮小できる。特に古いディスクを新しいディスクにしたい時に、一旦新しいディスクをつないで、LVMで共有した上で、古いディスクの方をLVMから外す…という形でサービスを止めずに(性能は落ちるかもしらんが)、ファイルシステムをあっちのディスクからこっちのディスクに動かすとか色々便利。
便利なのだが…それは「新しいディスクと古いディスクが共存できる」ような世界だけ。Software RAID5のように「よーし、ディスクあるだけ並列化しちゃうけど、パリティのお陰で1つまでは壊れても大丈夫だ」的な世界では、LVMを使ってもこんな平行移動みたいなことはできない。ディスクがないからね。
となると、素直に、RAID5全部を1つのファイルシステムにした方が便利。
というか、LVMが間に入ると、RAID5的に連続していて欲しい stripe が PE 単位でぶった切れる。上から見て連続しているはずのブロックが連続してない、というフラグメンテーションを起こすのが LVM の特徴なんだから。
それでも、snap shot は取れるし、大きな単位でIOするなら Raid5+LVMも悪くない。上位層であるファイルシステムが「大きな単位で」IOしてくれるなら。
.
で、btrfs。
btrfsを使うなら、まず LVM を間に挟む理由が判らない。btrfsは実質的に LVM の能力を全て持っている。だからこそ btrfsで snapshot が取れるし、btrfsに「参加しているデバイス」を個々に追加したり削除したりできる。どうしてもRaid5を使いたい場合でも、btrfs+Raid5で十分だ。
というか、LVMのsnapshotが中途半端になりがちなのは、snapshotを取ったときにファイルシステム的にはまだ dirty page がメモリ上に残っていることをLVMが追跡できないからだ。snapshotを取るには、dirty pageの管理がLVM側に渡らなくちゃいけないのに、ファイルシステム側はそれを保証していない。btrfsのように「ファイルシステムが」snapshot機能をもっていると、flush 前のdirty pageも含めて snapshot を作ることができる。btrfsの snapshot が軽い理由はここにあるし、snapshotをファイルシステムがサポートするべきなのであってLVMではない理由もここにある。例外は、AIXのJFSのようにファイルシステムとLVMが実質的に連動するものだけだ(LinuxのJFSはこの連動機能がない。だから「AIXとは別物」「OS/2由来」と一生懸命言うわけ。「LinuxのJFSとAIXのJFSは全然性能が違いますよ～」という事だ)。
さらに、btrfs にはオンラインデフラグ機能がある。が、これは
「ファイルシステムから見て連続である事が、高速に read できる順序である」
という前提に従うようにファイルを並べる、ということだ。でも、LVMはその仮定を崩す。LVMが間にいると、『LVM的に連続』だが『物理的に不連続』な状態になる。
一方で、btrfsはB-tree ベースに作られている。つまりそもそもが木構造管理を前提としているので、メタデータ操作がちまちましたサイズになりがちなのだ。結果、btrfs の構造は Raid5 と相性が悪い。ちまちました変更を巨大な stripe に対して行うと、read-modify-write の山になる。
btrfsがSSDを特別視しているのは、SSDが内部的には Raid5 と同じぐらい大きな stripe 単位でIOしないと read-modify-write だらけになるからだ。
もし、これが XFSやext4のように file extent とか領域予約とかを使い、同一ファイルに関するIOだけが1つの stripeに集中するならまだいい。btrfsはそうはならない。1つのstripeの中に、複数のファイルの情報が交互に並び、後でそれを並び替えるためにさらに read-modify-writeを繰り広げる。
.
つまり…
- btrfs を使うなら、Raid化しない。で、btrfsのRAIDアルゴリズム+チェックサム機能を使う。
- btrfs を前提にしないなら、ext4 か XFS にして、Raid5が良い。スナップショットが欲しい場合だけLVM
のどちらかを選ぶ、というのが正解…だと思う。
# btrfs ってまるでラオウだな。
btrfsにLVMなんて挟みませんよ？ (スコア:1)
っていうか、そんなこと俺書いてませんけど。
RAID5 + LVM + XFSという構成からRAID5 + btrfsという構成に変えたら大失敗、という話です。
Re:btrfsにLVMなんて挟みませんよ？ (スコア:1)
…っ!!! 本当だ。失礼しました。
fjの教祖様