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