私のLinux Mint 17.2 VMwareゲストでは、df -h合計ディスク使用量は約10GBで安定していると報告されています。私は、Workstation 12.1.1 Proを実行しているWindowsホスト内でRuby on Railsを開発するためにこのシステムを使用しています。
ファイルは*.vmdk約100GBまで着実に増加しました。ズームインしてもズームアウトしてもvmware-vdiskmanager -k違いvmware-toolbox-cmd disk shrinkonlyはありません。
私は持っていますFilesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize。より完全なdumpe2fs出力は次のとおりです。書くことができる。
実行され、もはやスペースが回収されることを許可していません（最初のvmdk（約6 GBから始まる）が縮小の兆候を示さなかった後、縮小を終了しました。e4defrag /）e2fsck -E discard
最後の秘訣は、NUL利用可能なすべてのスペースをバイトで埋めることです。
dd if=/dev/zero of=wipefile bs=1M; sync; rm wipefile
今使用できます*.vmdk。vmware-toolbox-cmd disk shrinkonly
実際のデータが10GBの仮想マシンの場合、約85GBのスペースが節約されます。
未使用のブロックを要求すると、以前ext4に使用されたブロックは再利用されないように見え、以前は一度も使用されていないブロックを提供することを好むことがよくあります。
質問
古いデータをより長く保管するのは安全ではないようです。
ext4最近使用したブロックをできるだけ早く再利用するのはどうですか？ext4今使用したブロックを強制的に再利用する方法はありますか？定期的に空き容量を埋め
*.vmdkずにVMwareゲストファイルが大きくなるのを防ぐ方法はありますか？0- これを安全に自動化するにはどうすればよいですか（たとえば、ファイルシステムを完全に埋め込むことなく）。
ベストアンサー1
削除されたファイルブロックをゼロにするファイルシステムはありません。このクラスターを使用可能としてマーク。これが、修復ツールが削除されたファイルを別のファイルで上書きしなかった場合に回復できる理由です。ファイルシステムドライバがこれらのブロックをできるだけ早く再利用すると、誤って削除されたファイルを回復できなくなり、顧客は泣いてクラスタをゼロで上書きする必要がある場合、パフォーマンスに深刻な影響を与えます。
安全に保存する必要があるファイルは、ディスクに残さずに暗号化する必要があります。必要に応じてグラインダーツール良い彫刻を破るUnixとccleanerドライブワイパー、消しゴム、削除...Windowsから安全に削除します。
VMDKに関してセクターまれな形式、VHD、VDI、またはVM用に動的にサイズ変更される他の仮想ディスクイメージ形式と同じです。したがって、セクタを0に指定すると、そのセクタは次のように表示されます。不要これを超えると、コンプレッサはそのエントリを除いてファイルサイズが小さくなります。仮想マシンはそのセクタが削除されたファイルに属しているかどうかを知らないため、ゼロ以外のセクタは明示的に保存する必要があります。
使用するdd if=/dev/zeroのは悪いアプローチです。
- 遅いです。
- ディスクイメージが（一時的に）最大値まで増加します。
- （一時的に）ディスク上の利用可能なすべてのスペースを使用するため、他の同時書き込み操作が失敗する可能性があります。
で述べたようにzerofreeマンページ。ディスクをゼロにするために特別に設計されたツールを使用してください。zerofree代わりに。
仮想ディスクイメージの拡張を防ぐ方法はありません。ディスクにさらにデータを書き込む必要がある場合はどうなりますか？ファイルを削除しても、そのデータはディスクに残り、イメージファイルのスペースを占有します。ファイルを大きくしたくない場合、唯一の方法はファイルを大きくすることです。固定サイズ創造について。