09/05/19 02:30:16
ただ、ZFSとなると結構マシンパワーが必要になってくるので
古いPCでは苦しいかもしれない。
エロ動画置き場にZFSは役不足ってもんだ。
60:DNS未登録さん
09/05/19 03:35:27
そう？
メモリだけアホみたいに食いまくるけどCPUはそれほどでもない気がする。
x64鯖が1万ちょっとで買えるんで、古いPC使う意味がなんぼのものか。
FUSE使えばLinuxでもZFS使えるみたいね。Openfilerで取り込んでくれないかしら。
61:DNS未登録さん
09/05/19 08:46:08
>59
RAID5の弱点は突然の電源断とかで起きうるwrite holeを抱えてることだから、マシンは古くて良くても、
UPS等の補助がないと怖すぎるって問題があるからね。ZFSはメモリ喰いではあるが、CPUパワーは実のところ
大食いという訳じゃないから、メモリさえ確保できるなら古めのマシンにはむしろ向いていると思われ。
まぁ、パワー不足に一番無難なのは素直にRAID1ってことなんだろうけど。
62:DNS未登録さん
09/05/20 01:16:41
Openfilerスレで続けるのも微妙だけど、よく比較されるFreeNASで手軽に使えるらしいZFSの特長として強調される
write hole問題について聞きたい。
突然の電源断が怖いというのは、RAID5とかRAID6は必ずライトバックキャッシュ的なものを介しているということなの？
だとしてもRAIDレベルでトランザクション処理をすれば、書き込んだはずのデータが実は正常に
書き込まれていないことなんて有り得ない気がしてしまう。
逆にパリティの不整合が有り得るなら、RAID1だろうがドライブ単体だろうが同じようにデータが壊れるような・・・？
63:DNS未登録さん
09/05/20 02:05:58
電源が落ちた瞬間に、「データは書き込まれたけど、まだパリティが書き終わっていない」
状態が起こり得る。
そうなると、データは正しく書き込まれたのにパリティが更新されていないものだから、
チェックしたときに不整合と判断される。（そのブロックだけ）
>62 の言うトランザクション的なものをファイルシステムレベルで実現するのが、ZFSなどの近頃FS
64:DNS未登録さん
09/05/20 07:40:35
ZFSでなぜライトホールが解消できていると言えるのか。
その理由はいくらググっても、確たる根拠が示されていない。
推測すると、以下の組み合わせと思われる。
・可変ストライプ幅により未確定状態での待機が最小
・ブロック単位でのチェックサム（により、データ破損が明確化できる）
・Copy on Writeによるロールバック
正直RAID5の実装を詳しく知らないんですけど、
RAID5では書き込み命令があるとラウンドロビン的にディスクに順次書き込み、
規定量に達した時点でパリティ計算し結果を保存する。
パリティ保存前に電源断等で中途半端に書き込みが終了すると、読み出し時、
RAID5ではデータ破損を検知できずにXORが0になる適当なデータを
捏造して返してしまうことになると思われる。
（そもそもどれがパリティなのか、判断できるフラグを持っていないのでは？）
一方ZFSの場合、可変ストライプ幅なので
書き込み命令が一定量に満ちるまで待機する必要がなく
電源断の影響を最小化できるものと思われる。
また、全ブロックチェックサムによりエラーが発生したブロックは自動破棄され、
他ディスクのデータからも元データを復旧できない場合は
Copy on Writeにより変更発生前のファイル抽出を試みる。
これにより、ファイルが復旧不可能だった場合には書き込み発生前の状態に
水面下でロールバックされる。
という理解なんだけど。間違ってるかしら。
65:DNS未登録さん
09/05/20 19:37:12
CoWとすることで、
・更新前の整合性のとれたデータ/パリティである
・更新後で整合性のとれたデータ/パリティである。
のいずれかの状態で、データは更新後、パリティは更新前みたいなwrite holeは
起きないというロジックだと思われ。
66:DNS未登録さん
09/05/20 21:39:33
>>63-65
ほぼ理解した、㌧。実際のところどうなのかの判断はできないけど、間違った推測にはみえない。
ジャーナリングファイルシステムの下のレイヤーでは、処理が中途半端に中断される可能性があるにもかかわらず
実装としてトランザクションになってないのか。ど素人考えだがなんか間抜けだな。事実だとしても納得いかない。
安全性がRAID1と同等になるように、パリティを算出してから3（以上）台に同時に書き込むとかできないものか。
というか、本当にそういう実装が存在しないのか？
非ジャーナリングファイルシステムのファイルシステムレベルでの不整合の危険性 ＞＞ RAIDレベルでのデータ化けの危険性
ということか。
OpenfilerつまりLinuxのソフトウェアRAIDのRAID5で、write holeが原因らしき壊れ方をした事例ってあるのかな。
67:DNS未登録さん
09/05/20 23:22:05
>66
> OpenfilerつまりLinuxのソフトウェアRAIDのRAID5で、write holeが原因らしき壊れ方をした事例ってあるのかな。
write holeの障害は結構深刻だから、まともなRAIDカードならバッテリーがなければwrite cacheが
オフになってるし。
OpenFilerってか、mdadmでソフトウェアRAID 5組んでたのが障害が起きて、kernelがパニくって
死亡みたいな話は珍しいって訳じゃないから当然あってもおかしくない。
68:DNS未登録さん
09/05/21 21:44:58
スナップショットとそのスケジュールが消せなくなる場合があるのは相変わらずだけど、
smb.confに余計な行が生成されてSMB/CIFSの認証エラーになるのはアップデートで解消されて、
やっと変な対処をせずに普通に使えるレベルにはなった、かな。
69:DNS未登録さん
09/05/24 16:13:28
RAIDが保証できるのはブロック単位の整合性。
ファイルの中身の整合性なんて、ファイルシステムレベルでないと知りようがない。
70:DNS未登録さん
09/05/24 17:27:44
ファイルシステムにRAIDが内包されてるZFSなら
ファイルの中身の整合性を取りつつRAIDできるので安心ですね、と。
71:DNS未登録さん
09/05/26 00:55:46
ZFSってそこまでやってくれるの？
72:DNS未登録さん
09/05/26 01:12:00
ＨＤＤ一台でbootからswapから全部まかなおうと思っています。
shareフォルダ作ろうと思ってますが、ボリュームの追加が出来ません。
何が間違っていますか
73:DNS未登録さん
09/05/26 08:54:04
>71
zfsはmdadm+LVM+fs(ext3,xfs,etc...)+(自動)/etc/fstab+dump/restore+ファイル毎のmd5sumみたいな代物だからなぁ。
74:DNS未登録さん
09/05/26 18:54:47
かなり痛い目にあったので報告。
ちょっと長くて，それでいて用語が正しくないはずなので
そのあたりはご容赦を。
5月にあったシステムのアップデートをかけて，その後再起動時に
fsck かけるようにして再起動。
なんだか接続できないなとモニタをつなげてみたら，起動時に fsck が
abort しておられる。シングルモードに落ちてるので再度 fsck しても
すぐに abort してしまう。
システム用の HDD はそこらに転がっていた古いのを使っていたので
お亡くなりになったのかなと思い，HDD を交換して再インストール。
再インストール時にデータの入っている Raid が認識されてるので
少し安心しつつ再インストールを進めるも，すべての設定が終わって
HDD のフォーマットが終わったところでスクリプトエラー。
madam がどうとか言ってるような気がしたので，Raid を組んでいる
HDD からケーブルを引っこ抜いて再挑戦。今度はすんなりインストール
できた。
（続く）