mhddfsをCentOS6.2に導入する（完全版）

CentOS5.7ではkernelとglibcが古くて入れようが無かったmhddfsですがCentOS6.2では問題ないようです。

■必要パッケージ
yum install make gcc glibc-devel fuse fuse-libs fuse-devel

■warning対策
mkdir /usr/include/attr
ln -s /usr/include/sys/xattr.h /usr/include/attr/xattr.h

■make
wget http://mhddfs.uvw.ru/downloads/mhddfs_0.1.38.tar.gz
tar zxvf mhddfs_0.1.38.tar.gz
cd mhddfs-0.1.38
make
cp mhddfs /usr/local/bin/

■動作テスト
mkdir test
mkdir brick1
mkdir brick2
mhddfs brick1,brick2 test

■/etc/fstabに書くときの書式
mhddfs#/kfs/fuse/brick1,/kfs/fuse/brick2 /kfs/fuse/test fuse defaults,allow_other 0 0

これで一応動いているようです。。

CentOS5.7 mhddfsのmake時のwarningを解消する

気持ち悪い、というかちゃんと動いていない気がするので、warningの解消を試みました。

■結論
CentOS5.7には入れられません。後日CentOS6への移行を試みます。

■xattr問題
警告：src/main.c:37:24: 警告: attr/xattr.h: そのようなファイルやディレクトリはありません
原因：CentOS5.7では sys/xattr.h に入っている。
対策：シンボリックリンクを作ってお茶を濁す。

mkdir /usr/include/attr
ln -s /usr/include/sys/xattr.h /usr/include/attr/xattr.h

■lutimes問題
警告：main.c:(.text+0x1ca9): warning: warning: lutimes is not implemented and will always fail
原因：Linuxシステムコールlutimesはglibc2.6で追加されたもの。CentOS5.7は2.5なので、搭載されていない。
対策：utimesに変えてしまえ。
注意：正常に動作しない場合がありそうな気がする。
utimesに変えると、シンボリックリンク自体のタイムスタンプを変えられなくなる。シンボリックリンクのリンク先ファイルのタイムスタンプが書き変わってしまう。シンボリックリンクを使わなければ問題にならないのでよしとする・・・ と思ったんですが、GlusterFSでミラーするのに正しくタイムスタンプが変えられないのは深刻な問題のような気がするので、今回の用途としてはCentOS5.7では安心しては使えなさそうな気がしました。

2012/1/29追記
> futimes() is available since glibc 2.3. lutimes() is available since glibc 2.6, and is implemented using the utimensat(2) system call, which is supported since kernel 2.6.22.
CentOS5.7の最新kernelは2.6.18なので、純正環境ではどうあがいても無理ですね。はい。

mhddfsをCentOSに導入する

warningを放置すると正常に動作しません！！ 次のエントリをご参照ください。

公式rpmは用意されてないのでソースから。
makeするとxattr周りでwarningが出ますが検証してませんので自己責任でどうぞ。

■make
yum install gcc glibc-devel fuse fuse-libs fuse-devel
wget http://mhddfs.uvw.ru/downloads/mhddfs_0.1.38.tar.gz
tar zxvf mhddfs_0.1.38.tar.gz
cd mhddfs_0.1.38
make
cp mhddfs /usr/local/bin/

■動作テスト
mkdir test
mkdir brick1
mkdir brick2
mhddfs brick1,brick2 test

■/etc/fstabに書くときの書式
mhddfs#/kfs/fuse/brick1,/kfs/fuse/brick2 /kfs/fuse/test fuse defaults,allow_other 0 0

GlusterFSはmhddfsと相性が良さそうだ

GlusterFSとZFSを組み合わせるのを、やめることにしました。mhddfsにします。

ZFSとGlusterFSの相性は、前回エントリの通り、最悪です。チェックサムによるデータ保護やsnapshotを諦めてしまえば、mhddfsがとても素敵に見えます。（どうしてもチェックサムやsnapshotが欲しければ、GlusterFS Geo Replicationかrsyncか何かでZFSに非同期バックアップを取っておけば、それで十分かなと思った。）

1ストレージサーバに複数ディスクを取り付けてGlusterFSで束ねるべく、1サーバに複数のbrick（1ディスク＝1brick）を割り当てると、ものすごく使いにくい。
ディスクが壊れてもbrickを個別停止できません。GlusterFSのデーモンを落としてサーバを丸ごと停止する必要があります。
デーモンを落とさずbrickをマウント解除すると空ディレクトリに書き込みを始めてしまうし、ディレクトリを消すとまともに動かない。
ディスクが壊れる前に事前にデーモンを落とせれば良いが、そうでない場合、致命傷を受ける可能性があります。
束ねる際に対になるディスクは容量が揃ってないと予期せぬ動作を催します。空き容量に関係なくファイル名ハッシュで満遍なく分散保存されてしまうので、対になってないディスクでも容量が大きい分が丸ごと無駄です。
brick内のファイルを直接触るのは危険です。容量が増えれば増えるほど再構成の負担が増大します。

そこで、mhddfsでディスクをコンカチして、そこにディレクトリを掘って、GlusterFSでサーバー間でミラーリングすると、全て解決します。
ディスクが壊れたら、そのディスクのマウントポイントを削除すれば、mhddfsはそのディスクが無かったものとして動作続行し、GlusterFSがミラー復旧に努めてくれます。（マウント解除されると空ディレクトリに書き込まれちゃうのは同じなんですが、マウントポイントが消失しても問題ないのが良い点）
ディスクとbrickが結びついていないので、brickをマウント解除したりディレクトリを消去することはありません。（外したディスク以外にディレクトリエントリが記録されていなかった場合を除くものの）
よって事前にデーモンを落とせなくても、GlusterFSの困った動作の影響は受けません。（大体は。まぁメリットはエラー対処よりディスク容量問題の方が大きいんで堪忍してください）
個々のディスクの容量を揃える必要はありません。サーバ間で揃っていれば良いし、あるいはまったく揃えずとも満杯になりそうになったらディスクを手軽に追加投入して解消できます。手持ちのディスクを空きポートの数だけ全部突っ込めます。
ディスクは前方から順番に使用されていきます。負荷分散はできませんが、各ディスクのファイルは直接触っても問題ないので、ファイルを手動でコピーすればいかようにも再構成できます。

まぁパフォーマンスは測定しないといけませんけど、いいことづくめではないでしょうか。ストレージプールに追加したディスクは絶対に取り外せないZFSよりもHA運用に向いていると言えなくもないくらいじゃないですか・・・？

この路線で考えてみます。

GlusterFSとZFSを組み合わせるには

GlusterFSとZFSを組み合わせて使うのに、一悶着あったので、書き残しておきます。
何かを見落としていなければ、かなりの冒険が必要のようです。

■結論（持ち越し）
・ZFSとGlusterFSは、そのままでは組み合わせ不可能（ZFSがxattrに対応してないから）
・ZVOLを作ってUFSフォーマットしてマウントすれば使えるが… えー、それマジっすか？

・ソリューション選択で何とかならないかなぁ。
FreeBSD＋ZFS(ZVOL)＋UFS＋GlusterFS
CentOS+ZFS-FUSE(ZVOL)+XFS＋GlusterFS
CentOS+mhddfs＋XFS＋GlusterFS（そもそもZFS無くても良くね？ と思ってきた）

■GlusterFSとZFSの併用について
GlusterFSはディレクトリを束ねるソリューションであって、ストレージの挙動には関与しません。データの中身の整合性であるとか、ディスクのリプレースとか容量拡張とか、考慮されていません。それはそれで正しいんでしょうけど、これで複数のディスクを束ねて順次拡張しながら長期運用しようとすると困難に直面することがあるようです。（ディスクを止められないとか、最小容量のディスクに引っ張られるとか、挙動が怪しくなるとか）

その点、ZFSが併用できれば便利そうです。データをチェックサムで点検したり、書き込みホール無しのダブルパリティで物理障害に備えたり、ホットスペアを用意したり、容量の異なるディスクを継ぎ接ぎしたり、スナップショットとれたり、持続的な発展的運用にはもってこいじゃないですか。（メモリ食うし安定させるの大変だけど）

■プラットフォームの問題
GlusterFSは一応RedHat系Linuxが推奨環境になります。ZFSはFreeBSDなら安心ですが、Linuxですと今のところZFS-FUSEになるかと思います。あんまり安心して使える感じじゃないんですよね。

ここはソリューション選択で解決できそうな気がします。
・GlusterFSでミラーされてるしバックアップもあるし、データ保護は半ばどうでもいいのでZFS-FUSEを使う。
・ZFSの安定性を重視するなら（いろいろ間違ってる気がするが）Debian GNU/kFreeBSDにGlusterFSを入れる。

うーん、一応両方評価してみようかなと思います。。

■ZFSの仕様の問題
しかし、しかしです。ZFSには重大な欠点があります。GlusterFSの必須用件であるattrがサポートされていません； GlusterFSとZFSを組み合わせることは、そもそも不可能なんです；

ZFS上でattrコマンドを実行するとエラーです。
zfs set xattr=onも通りません。

これはSolarisと他OSにおける「attr」の仕組みの違いによるものです。Sorarisにはext2/3やXFS、UFSでいうところの「attr」と一致するものが存在しません（しないようです）。なのでZFSではそんなものは仕様上考慮されておらず、搭載されていないと。こりゃ時間が解決してくれる手の問題ではなさそうで、どうにもなりません。

このattr問題に関し、FreeBSD.orgのドキュメントを参照しますと驚愕の対処法が書かれています。

# zfs create -V 10g tank/ufs
# newfs /dev/zvol/tank/ufs
# mount /dev/zvol/tank/ufs /ufs

引用元：http://wiki.freebsd.org/ZFSQuickStartGuide

なんと斬新な・・・ 驚愕を通り越して感動すら憶えます。しかし、最近のFreeBSDにはSoftUpdateが付いてるとはいえ、これでsnapshotとか取って大丈夫なんだろうか。。疑問疑問。。スマートとも言えない。。ですよね。。容量拡張はZFSでサイズ変更してからgrowfsか？

しかしZFSを使う限り宿命なので、これで検証することにします。フォーマットは、FreeBSDならUFS、LinuxならXFSでしょうか。

■ZFSやめようかな
単にHDDを束ねるだけならmhddfs（FUSE）という手がある。ディレクトリをコンカチしてくれる素敵ソリューション。

・ファイルシステムの上のレイヤーで動くJBODのようなもの。複数のディレクトリを束ね、1つのものとして見せてくれる。mhddfs自体は中継レイヤーであり、普通のファイルシステムではない。

・mhddfsで束ねたディレクトリに書き込むと、束ねる際に指定した順番で前方のディレクトリから順次、容量フルになるまで書き込まれていく（デフォルト設定ではフルになる前に次のディレクトリに移行するけど）。

・書き込みはブロック単位ではなくファイル単位で行われる。ファイルがディレクトリをまたがって書き込まれることは無い。追記途中でディレクトリが一杯になったら次のディレクトリに自動的にマイグレーションされる（けどサイズが大きいと時間かかりまくるんじゃないかなと想像。。これは善し悪しかも知れない。）

・束ねたディレクトリは1つづつ独立した普通のディレクトリなので単独でマウントして中身を拾えるし、マウントパラメータ以外に管理情報も持っていないので運用中に適当に抜いたり追加したりしても大丈夫。

・運用中に構成ディレクトリを外すとそこにあったファイルは見えなくなるが、元通りマウントすれば復活する。冗長性は無いが、ディスクが故障した場合、そこに記録されているファイルは失われるが他のファイルは無事なので全損にはならない。

・束ねるディレクトリ間でファイル名やディレクトリ名が衝突した場合、一番前方のディレクトリにあるもののみが読み書きの対象になる。ということは、ファイルを更新してもディレクトリのタイムスタンプが更新されないケースが生じうる。プログラム的にはここ要注意かも知れない。

冗長性はGlusterFSによるreplicaでカバーできるものとすれば、これこそGlusterFSと相性がいいと言えるかも知れない。

○ディスク数を減らしたい場合
・ディスクを外したいサーバのGlusterFSプロセスを落とす（自動フェイルオーバーで稼働継続）
・mhddfsをumountして交換したいディスクのマウントポイントを外してmountし直す（欠損が発生）
・GlusterFSプロセスを上げる
・欠損部分がミラーで自動修復される（笑

○ディスク数を増やしたい場合
・ディスクを追加したいサーバのGlusterFSプロセスを落とす（自動フェイルオーバーで稼働継続）
・mhddfsをumountして取り付けたディスクのマウントポイントを最後に追加してmountし直す
・GlusterFSプロセスを上げる
・既存ディスクが埋まり次第、新しいディスクが使われていく

というわけで、チェックサムによるデータ保護はないものの、brickの構成を変更せずに素早くディスクを切り替えられてhappyになれる。

しかし。

・mhddfsはFUSEを使う。FUSEが2重になるとパフォーマンスや安定性が微妙そうな気が何となくする。
・mhddfsをCentOSに導入するのは大変そうだ。公式パッケージは無い。

うーん、決定打がない。

いっそmhddfsを改造するとかして、同期レプリケーションに特化した新しいファイルシステムを作っちゃうか？

・write系は、両方に同期ミラーで書く。
・read系は、両方から読む。データは比較してもしなくてもいいや。
・read系で、片方にファイルが無かった場合は、もう片方からコピってくる。
・タイムアウトなりエラー検知なりした場合、そのディレクトリの使用を中止する。

これでNFSを束ねれば十分じゃないか？ ていうか、もしかして現存するんじゃないか？

なんか徒然と書いてしまいましたが、今日はこの辺で。

※2012/2/1修正
徒然し過ぎていたのでちょっと整理整頓しました。

GlusterFS 容量フル時の挙動を確かめてみた

容量フルにならない運用を心がけるのは当然なんでしょうが、一応、そうなっちゃった時の挙動を確かめておきました。

■使用環境
CentOS5.7
GlusterFS3.2.5

■テスト方法
ダミーファイルをxfsでフォーマットし、適当にマウントし、GlusterFSで束ねます。
ダミーファイルの大きさを不均等にしておいて挙動を見ます。
今回はローカルでのテストなので、ネットワーク越しだと違うかも知れません。

■用意(zero1だけ200MB、他は1GB)
dd if=/dev/zero of=/glvols01/disk01/zero1 seek=200 bs=1M count=1
dd if=/dev/zero of=/glvols01/disk02/zero2 seek=1000 bs=1M count=1
dd if=/dev/zero of=/glvols01/disk03/zero3 seek=1000 bs=1M count=1
dd if=/dev/zero of=/glvols01/disk04/zero4 seek=1000 bs=1M count=1
mkfs.xfs /glvols01/disk01/zero1
mkfs.xfs /glvols01/disk01/zero2
mkfs.xfs /glvols01/disk01/zero3
mkfs.xfs /glvols01/disk01/zero4
mkdir /glvols01/zero1
mkdir /glvols01/zero2
mkdir /glvols01/zero3
mkdir /glvols01/zero4
mount -t xfs -o loop /glvols01/disk01/zero1 /glvols/zero1
mount -t xfs -o loop /glvols01/disk01/zero2 /glvols/zero2
mount -t xfs -o loop /glvols01/disk01/zero3 /glvols/zero3
mount -t xfs -o loop /glvols01/disk01/zero4 /glvols/zero4
gluster volume create zero replica 2 192.168.0.252:/glvols/zero1 192.168.0.252:/glvols/zero2 192.168.0.252:/glvols/zero3 192.168.0.252:/glvols/zero4

■テスト結果：レプリカディレクトリの空き容量が均等な場合
空き容量不足で正常に終了するようです。

[root@kfs02 glvols01]# dd if=/dev/zero of=/zero/zero bs=1M
dd: writing `/zero/zero': デバイスに空き領域がありません
dd: 出力ファイル `/zero/zero' をクローズ: デバイスに空き領域がありません

[root@kfs02 glvols01]# df -kh
Filesystem サイズ 使用 残り 使用% マウント位置
/glvols01/disk01/zero1
197M 4.3M 193M 3% /glvols01/zero1
/glvols01/disk02/zero2
997M 4.3M 993M 1% /glvols01/zero2
/glvols01/disk03/zero3
997M 997M 20K 100% /glvols01/zero3
/glvols01/disk04/zero4
997M 997M 20K 100% /glvols01/zero4
glusterfs#192.168.0.252:zero
1.2G 1001M 192M 84% /zero

■テスト結果：レプリカディレクトリの空き容量が不均等の場合
片方が埋まっても、両方が埋まるまで超低速で書き込みが続いてしまうようです。
正確な速度は調べてませんが、0.5MB/sも出てない感じ。
未確認ですが、この状態で書き込みが集中すると鯖落ちということになるんでしょうか。

[root@kfs02 glvols01]# dd if=/dev/zero of=/zero/azero bs=1M

[root@kfs02 glvols01]# df -kh
Filesystem サイズ 使用 残り 使用% マウント位置
/glvols01/disk01/zero1
197M 197M 20K 100% /glvols01/zero1　←注目
/glvols01/disk02/zero2
997M 237M 761M 24% /glvols01/zero2　←注目（zero1を超えてる）
/glvols01/disk03/zero3
997M 997M 20K 100% /glvols01/zero3
/glvols01/disk04/zero4
997M 997M 20K 100% /glvols01/zero4
glusterfs#192.168.0.252:zero
1.2G 1.2G 0 100% /zero

■考察
ファイル名でハッシュ値をとって分散しているので、brick間での空き容量に関係なく書き込みが試行されます。
書き込み先のbrickが一杯になった時点で容量フルのエラー応答。
書き込み先のbrickのうちミラーの片割れだけが容量フルになっても、エラーを返さず超低速で動き続けます。容量フルのbrickのファイルのタイムスタンプも更新され続けているので、書き込みを試行し続けているのかな。動作が遅くなるのはxfsのせいだろうか？ CPUはほとんどidolで、何をやってるのかよくわかりません。
レプリカの正誤判定は、タイムスタンプの新しいほうを正とみなす、なんてロジックでしたっけ？　だとすると破滅的な挙動に繋がるかも知れませんが確かめておらず。

■まとめ
brickごとに容量監視が必要です。
replicaで対になるbrickの容量は揃えておいたほうが良さそうです。
対にならないbrickに関しては容量が揃っていなくても深刻な問題は無さそうですが、分散アルゴリズム上、容量差は考慮されないので、容量が大きい方が無駄になる可能性が高いようです。
適当にディレクトリを切ってbrickごとの容量差を近づければ無駄にはなりませんが、パフォーマンスが落ちるであろう点と、後でbrickを1つに合併させるのは困難であろう点が気になります。
長期運用中にディスクを追加したくなった場合に、その時点でバイト単価の最も安いディスクをチョイスしても無駄になっちゃいますね。
しかし全リプレースするにしてもreplace-brickにかかる時間が馬鹿にならないだろうし、ディスク追加のパフォーマンスは良くないように思います。

このへんはZFSを組み合わせてローカルディスクを単一ディレクトリにまとめてしまえば回避できますが、メモリ＆CPUリソースが食われるんでGlusterFSの長所が一つ潰れてしまいます。
しかもZFS＠FreeBSDではattrが使えないんで、そもそもだめですね。
ついでにGlusterFS公式ではFreeBSDやZFSでの動作は検証の対象外のようですね。そりゃGlusterFS自体がRedHat傘下だしなぁ。大量データを任せるのはハイリスクなんじゃないでしょうか。

なんだか、スモールスタートでの長期運用には向いていないんじゃないか、って感じがします。
最初から構成を固定するとか、一時的かつ再現可能なデータに限って使用するとか、将来的に代替ハードを用意＆大容量データを全コピー（低速）する羽目に陥るリスクを受容するとか、何らかの妥協がいりそうです。。

ZFSとGlusterFSの操作の対比

最近GlusterFSをいじっています。
ZFSが長年染み付いているので、対比表を作ってみました。

1年以上前にも導入を検討しましたが、いろいろあって見送りました。
最近システム構成を考える中で意外と行けるかもと思い直すようになりました。
ZFSよりもメモリへの要求が少ないのが、特にいいですね。

■確認したバージョン
GlusterFS 3.2.5（CentOS5.7）
ZFS v28（FreeBSD9.0）

まずは概念図から。
GlusterFSのマニュアルはZFSと同じだけど意味の違う用語が入り乱れているので、読んでて混乱します。
頭に叩き込んでおきましょう。



次にファイルシステムを作成する段取りについて。

ZFSでの操作	GlusterFSでの操作
サーバにデバイス（ディスク）を設置する /dev/ada0 /dev/ada1 /dev/ada2 /dev/ada3 /dev/ada4 /dev/ada5 /dev/ada6 /dev/ada7	サーバを信任する（例：2台） gluster peer probe 192.168.0.131 gluster peer probe 192.168.0.132 ブリック（ディレクトリ）を作成する mkdir /gluster-bricks/brick01 mkdir /gluster-bricks/brick02 mkdir /gluster-bricks/brick03 mkdir /gluster-bricks/brick04
デバイスからストレージプールを作成する zpool create tank0 mirror ada0 ada1 mirror ada2 ada3 mirror ada4 ada5 mirror ada6 ada7 ストレージプールからファイルシステムを作成する zfs create tank0/hogemoge	ブリックからボリュームを作成する gluster volume create hogemoge replica 2 transport tcp 192.168.0.131:/gluster-bricks/brick01 192.168.0.132:/gluster-bricks/brick01 192.168.0.131:/gluster-bricks/brick02 192.168.0.132:/gluster-bricks/brick02 192.168.0.131:/gluster-bricks/brick03 192.168.0.132:/gluster-bricks/brick03 192.168.0.131:/gluster-bricks/brick04 192.168.0.132:/gluster-bricks/brick04 ボリュームを利用開始する gluster volume start hogemoge
マウントポイントを設定する（マウント自体は全自動） zfs set mountpoint="/hogemoge" tank0/hogemoge	マウントする echo "192.168.0.131:hogemoge /hogemoge glusterfs default,user_xattr,_netdev 0 0" >> /etc/fstab mount -a

---

最後に、もうちょっと細かい操作コマンドの違いについて。
オプションは一切省いているので、説明書を必ず熟読してください。
GlusterFSは設定ファイルを直接いじれば、リネームとかも可能なんだと思いますけれども、覚えるのが面倒なのでコマンドラインツールで操作できる内容に絞りました。

ZFSの操作	ZFSでのコマンド	GlusterFSでのコマンド	GlusterFSの操作
ZFSにはGlusterFSの"信頼されたストレージプール"に相当する概念はない。 サーバ構成は自分自身の1台のみで完結なので関係ない。		gluster peer probe	サーバを信任する（"信頼されたストレージプール"に追加する）
		gluster peer detach	サーバを信任解除する（"信頼されたストレージプール"から取り除く）
ファイルシステムのマウント許可（デフォルト）	zfs set canmount=on	gluster volume start	ボリューム利用開始
ファイルシステムのマウント禁止	zfs set canmount=off	gluster volume stop	ボリューム利用停止（デフォルト）
デバイスからストレージプールを作成する	zpool create	gluster volume create	ディレクトリからボリュームを作成する
ストレージプールからファイルシステムを作成する	zfs create
ストレージプールを破棄する	zpool destroy	gluster volume delete	ボリュームを破棄する
ファイルシステムを破棄する	zfs destroy
ストレージプールにデバイスを追加する（容量拡大、ホットスペア、ZIL、L2ARC）	zpool add	gluster volume add-brick	ボリュームにブリックを追加する（容量拡大のみ）
ZFSでは容量は縮小できない（通常デバイスは取り外せない）		gluster volume remove-brick	ボリュームからブリックを取り外す（そのブリックに記録されているデータはボリュームから消失する）(*1)
ストレージプールからデバイスを取り外す（ホットスペア、ZIL、L2ARC）	zpool remove	GlusterFSにはそうした特殊デバイスは存在しない。
デバイスを入れ替える	zpool replace	gluster volume replace-brick	ブリックを入れ替える
ZFSでは記録済みデータはリバランスできない		gluster volume rebalance	ブリック間で記録済みデータをリバランスする
ストレージプールにミラーデバイスを追加する	zpool attach	GlusterFSではミラー数は途中変更できない。
ストレージプールのミラーデバイスを削除する	zpool detach
ストレージプールの一覧を表示する	zpool list	gluster volume info all	ボリュームの構成情報を表示する。ただし容量は表示されない。(*2)
ストレージプールの状態を表示する	zpool status
ファイルシステムの一覧を表示する	zfs list
デバイスの使用を停止する	zpool offline	GlusterFSではブリックは個別停止できない。(*3)(*5)
デバイスの使用を再開する	zpool online
エラーチェック＆修復	zpool scrub	レプリケーションはファイルにアクセスする度に自動修復される。(*4)
ファイルシステムをリネームする	zfs rename	GlusterFSではボリューム名は途中変更できない。

(*1)ファイル消失について
ボリュームの構成情報のみが削除され、データは残る。
各ブリックはただのディレクトリなので、ストライピングしていなければ直接救出可能。
ストライピングしている場合はファイルの一部分がsparseで欠損しているので非常に大変だと思うが、不可能ではないだろうとは思う。
まぁディスクなりブリックなりを一度追加したら簡単には外せないというのはZFSもGlusterFSも似たような状況ということで。

(*2)容量の確認方法
容量はマウント先でdf -kコマンド等で確認すればよい。
ただしGlusterFSのボリュームは普通のディレクトリの寄せ集めのため、ディレクトリ毎に空き容量がバラバラなので、df的には空いててもバランシングの状況次第では容量フルでエラっちゃう可能性がある気がする。
容量オーバーを防止するなら構成ディレクトリをそれぞれ個別に監視しないといけませんね。

(*3)ブリックは個別停止できない件について
ミラーされていて、かつNative Clientでマウントしていれば自動でフェイルオーバーされるので、停止させずに抜いちゃっても問題ないはず・・・（と思うけど確かめたわけではない）(*5)

(*4)レプリケーションの修復について
インデックスのみで良ければ find <gluster-mount> -print0 | xargs --null stat >/dev/null
ファイル内容まで完全に find <gluster-mount> -type f -exec dd if='{}' of=/dev/null bs=1M; > /dev/null 2>&1
チェックサム情報は（多分）持っていないので静的なデータ破壊までは点検できない（と思うけど確かめたわけではない）


以下20120124追記

(*5)試してみた
稼働中に、brickに使ってるディスクをマウントしてあるディレクトリをumountしてみました。
umountされてもGlusterFSは何事も無かったかのように稼働し続けました。素晴らしい。ではなくて、大変な事態に陥りました。

マウントポイントはマウント解除されることによって単なる空ディレクトリに変わりますが、GlusterFSはその空ディレクトリを使って勝手にレプリカの復元を始めてしまいます。おそらくファイルシステムの異変は感知せずレプリカの片割れが欠落したとだけ認識してしまうんでしょう。USB起動だったので起動ディスクが一瞬で埋まってしまいました・・・orz

では単にumountするだけではなくマウントポイントのディレクトリを削除するとどうなるかというと、復元動作は一応停止しますが、レプリケーションの片割れが読み書きできないことでクライアントにinput/output errorが返ってしまい、稼働継続できませんでした。レプリケーションの片割れは正常であるにも関わらずです。

シンプル設計との観点でいえば妥当な動作ではあろうと思いますが、運用中にマウントが外れることは、異常/正常を問わず有り得ると思うんですよね。これじゃ単発ディスクがSPOFになっちゃう。その対策としてディスクとファイルシステムで2重に冗長化するのはコスト高でしょう。やっぱりbrickは明示的に個別に一時停止できたほうが、いいんじゃないかなぁ。

これがネットワーク切断やサーバダウンによる片割れ停止だったら異常検知されて稼働し続けられるのかなぁと想像しますが、どうなんでしょう。後日、試してみたいと思います。