アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
snapshot (スコア:1)
Re:snapshot (スコア:1)
snapshot 機能は「LVMがファイルシステム層に」提供する機能ですが、それ自体は「破綻する事がない」機構ではありません。
.
snapshot をとったとしますよね?するとビットマップと、代替ブロック領域が用意されます。仮に、あるブロックを書き換えるとしますよね? すると次のことが行われなくてはいけません(この順序で、と言う意味ではありませんよ)
a）ビットマップを更新する(あるブロックが更新されたことを示すために bit が 0から1に変更される)
b) 代替ブロック領域管理テーブルが更新される(元のブロック番号と、古いイメージがどこに書かれたのかを示すブロック番号が記録される)
c) 古いブロックのイメージが、代替ブロック領域に書き込まれる
d) 新しいブロックのイメージが、基のブロックに書かれる
まず間違いなく、d は最後に行われるでしょう。しかし他の3つは??
とりあえず、壊しても大丈夫なイメージを持っているブロックへの書き込みは c しかありません。従って、c は最初に行われるはずです。
しかし、a, b はどちらの順序で行っても、そのままでは破綻をきたします。
c->a->b->d の場合、a が終わった後、b が始まる前に電源断が起こると、「代替ブロックにイメージがある」のは判りますが、それが「どこにある」のか全く判りません。
c->b->a->d の場合、b の直後で停止すると管理テーブルが更新されていても、bitmapが0のままなのでその管理テーブル変更は有効になりません。また、管理テーブル自体に登録されている情報が、どこからノイズなのかどこまでは正しい情報なのか、識別する方法がありません。
c で停止している場合は、何も情報を持っていないだけのブロックのノイズイメージが別のノイズイメージに変更されただけなのでOK、d だけが失敗した場合は、snapshot の前後で同じイメージを持っているLVMができるだけなので、これまたOKです。が、b->a, a->b のどちらであっても、操作の途中で止まると破綻したLVMに成り果てます。
この破綻を回避するには、ｂの管理テーブル自身を多重化する(LFS型)か、Journal を用意するしかない。しかし、どちらも聞いた事がない。
.
というわけで、単に寡聞ならどっちか知りたいし、そうじゃないなら LVM は実は破綻する危険性がある(Snapshot ごと)、という事になります。
fjの教祖様