いくつかの前文:ツインホストから(つまり、同じ仮想化ハードウェアレイアウトとソフトウェアパッケージを使用しているが、使用履歴が異なる)ディスクデバイスのビット単位のコピーを(dd
コマンドを介して)取得しています。イメージサイズを最適化するために、パーティションのすべての空スペースをゼロで追跡しました(たとえば、/dev/zero
から)。パーティションごとに予約済みブロックも認識しており、その値を一時的に0%トレーリング前。
しかし、私は最終的に圧縮された(bzip2
によって)圧縮された画像の不一致に興味があります。すべてのホストのファイルサイズはほぼ同じtar-gziped
ですが、圧縮されたdd
イメージにはかなりの種類があります(最大20%)。では、どうすればよいでしょうか。ファイルシステムジャーナルデータにパージできなかった理由はありますか?ホストには10を超えるパーティションがあり、それぞれに128Mbのジャーナルサイズが報告されています。 (デフラグもチェックしました。すべて問題ありません:または1e4defrag
ツールレポートへ)
だから、私の質問は、どういうわけかext3/ext4
ファイルシステムジャーナルをクリーンアップすることは可能ですか? (もちろん、保存されたデータに対して安全に:)
[〜#〜]説明[〜#〜]
できればext3/ext4
filesystemのジャーナルをクリーンアップ(パージ/更新)する方法について質問をしました誤解されており、ファイルシステムジャーナルが占有しているディスク領域を再利用するなどの機能がないため、すべてのソリューションを歓迎します。私が前提として前文に入れた質問と私の質問への答えを尋ねる意図は、私が遭遇した問題を調査するのに役立ちます。
ジャーナルは、マウントを解除するか、読み取り専用で再マウントすることで消去できます(おそらくクローン作成時には良い考えです)。 ext4では、ジャーナルを完全にオフにすることもできます(tune2fs -O ^has_journal
)。.journal
マジック不変ファイルは自動的に削除されます。もちろん、ジャーナルデータは引き続き基になるディスクにあるため、ジャーナルを削除してから空き領域をゼロで埋めると、最良の結果が得られる可能性があります。
上記のコメントは頭に釘付けになりましたが、dd
はファイルシステムの下のビットを見て、それらが特定の配置になる方法は、最終的なものだけでなく、ファイルシステムに起こったすべてのことに依存しますファイルの内容。 機能 事前割り当て、遅延割り当て、マルチブロック割り当て、ナノ秒タイムスタンプなど、もちろんジャーナル自体もこれに貢献しています。また、潜在的にランダムな割り当て戦略が1つあります。 Orlovアロケーター はランダムな割り当てにフォールバックできます(fs/ext4/ialloc.c
を参照)。
完全を期すために、 安全な削除機能 ランダムスクラブを使用すると、(ゼロで埋められたバラストファイルを削除したと仮定して)違いが生じますが、その機能は(まだ)メインラインではありません。
多くのシステムでは、dump
コマンドとrestore
コマンドを同様のクローン作成方法に使用できます。これは さまざまな理由 Linuxでまったくキャッチされません。
問題の根本原因を見つけたので、ディスク全体ではなく各パーティションのビット単位のコピーをチェックして、冗長データがどのように分散されているかを確認すると、/dev/mapper
がlv_swap
ボリューム(パーティション)に配置されていることに気付きましたキャプチャされた同じディスク上で、スワップデータはもちろん最終イメージに含まれていました。すべての画像サイズのさまざまなデルタは、そのスワップパーティションにありました。noFS meta magic ..スクリプトがdf
コマンドから情報を取得するため、以前は表示されませんでした。 lv_swap
は計算されていません。
とにかく、誰かがext3/ext4
ファイルシステムのジャーナルの削除に関する質問に答えたら、私はそれを受け入れます。