qcow2形式のQEMUのディスクの実体サイズが大きくなってきたので縮小させたい。
ディスクにはWindows11が入っている。Windows11上で見るとディスク先頭の100MB程度のパーティションを入れても19GBほどしか使っていないにもかかわらず、qcow2イメージは44GBほどのサイズになっている。
ゲストOS（Windows11）側での作業
前提となる作業
仮想メモリは無し、ハイバネーションは停止（powercfg /h off）、復元ポイントは削除した状態でスタート
コマンドプロンプトから上記を実施したければ、管理者として実行したコマンドプロンプトから下記で実施できる。
> wmic computersystem set AutomaticManagedPagefile=False
> wmic pagefileset delete
> powercfg /h off
> vssadmin delete shadows /all
> vssadmin Resize ShadowStorage /For=C: /On=C: /MaxSize=320MB
Windowsシステムファイルの縮小
しばらく使っていたWindowsシステムは肥大化しているので、不要なファイルを削除しておく。
使えるツールや作業の例
cleanmgr.exe （Windows標準）
Dism.exe /Online /Cleanup-Image /StartComponentCleanup /ResetBase（Windows Updateで不要になったファイルだが、念の為に保存されている古いファイルを削除するコマンド）
Windows Updateの一時フォルダの削除（C:\Windows\SoftwareDistribution）
「管理者として実行」のコマンドプロンプトで下記を実行したあと、C:\Windows\SoftwareDistribution を削除する。
> net stop bits > net stop wuauserv
DriverStore Explorer（古くなったドライバの削除）
Uncleaner（古いが、上記作業実施後に数GB単位で削除できた）
Windows標準ツールとMS謹製ツールでできるボリュームの縮小
Windows11の「ディスクの管理」を使ってCドライブを「ボリュームの縮小」を行う。元々63GB程度割り当てられていたところから44GB程度の割当に縮小できたが、まだ未使用領域が25GB程度ある。
再度「ボリュームの縮小」を試みても、「縮小する領域のサイズ（MB）」は0のまま。「イベント ビューア」からApplicationログを確認すると、ソース Defrag、イベントID 259で縮小の邪魔をしている移動できないファイルを確認できる。
「最後に移動できなかったと思われるファイル」として「\$Extend\$UsnJrnl:$J:$DATA」が挙げられている。これは、USNジャーナルを削除することで対応でき、Windows標準ツールで対応できる。
> fsutil usn deletejournal /D C:
> fsutil resource setAutoReset true c:\
再度「ボリュームの縮小」を試みると6GBほど縮小できた。
続いて、移動できなかったファイルは\$Mft::$DATA。MFTのDefragはSysinternalsのcontigコマンドで実行できる。
Contigコマンド
https://learn.microsoft.com/ja-jp/sysinternals/downloads/contig
> contig -v -s $mft
Contig v1.83 - Contig
Copyright (C) 2001-2023 Mark Russinovich
Sysinternals
------------------------
Processing C:\$Mft:
Scanning file...
Scanning disk...
File is 212287 physical clusters in length.
File is in 4 fragments.
Moving 212287 clusters at file offset cluster 4 to disk cluster 12316797
File size: 869531648 bytes
Fragments before: 4
Fragments after : 1
------------------------
Failed to open :\$Mft::$BITMAP:
?????????????????????? ???????????????
------------------------
Summary:
Number of files processed: 2
Number of files defragmented: 1
Number unsuccessfully procesed: 1
Average fragmentation before: 4 frags/file
Average fragmentation after : 1 frags/file
>
ただ、残念ながら「ボリュームの縮小」を行っても数メガバイトしか縮小できなかった。
別のケースでは、\$Mft::$BITMAPが邪魔をして縮小できなかったが、その際にcontigを行っても、効果がなく縮小サイズは0だった。
> contig -v -s $mft
Contig v1.83 - Contig
Copyright (C) 2001-2023 Mark Russinovich
Sysinternals
------------------------
Processing C:\$Mft:
Scanning file...
C:\$Mft is already in 1 fragment.
------------------------
Failed to open :\$Mft::$BITMAP:
?????????????????????? ???????????????
------------------------
Summary:
Number of files processed: 2
Number of files defragmented: 0
Number unsuccessfully procesed: 2
All files were either already defragmented or unable to be defragmented.
>
defragをコマンドラインから行ってみる。コマンドプロンプトは「管理者として実行」が必須。
まず、空き領域をパーティションの最後に持ってくる/xオプションで実行してみるが、効果なしで、\$Mft::$DATAが邪魔する。
> defrag c: /v /x
(C:) の 空き領域の統合 を起動しています...
最適化前のレポート:
ボリューム情報:
ボリューム サイズ = 47.84 GB
クラスター サイズ = 4 KB
使用領域 = 30.00 GB
空き領域 = 17.84 GB
断片化:
断片化された領域の合計 = 41%
ファイルあたりの断片の平均 = 10.17
移動可能なファイルとフォルダー = 158462
移動不可のファイルとフォルダー = 8
ファイル:
断片化されたファイル = 4166
断片化されたファイルの総数 = 1324023
フォルダー:
フォルダーの総数 = 14111
断片化されたフォルダー = 1009
断片化されたフォルダーの総数 = 4369
空き領域:
空き領域の数 = 78672
空き領域の平均サイズ = 328.00 KB
空き領域の最大サイズ = 783.88 MB
マスター ファイル テーブル (MFT):
MFT サイズ = 829.25 MB
MFT レコード数 = 849151
MFT 使用量 = 100%
MFT 断片化の合計 = 0
注意: 64 MB よりも大きいファイルの断片は、断片化の統計情報には含まれません。
操作は正常に終了しました。
Post Defragmentation Report:
ボリューム情報:
ボリューム サイズ = 47.84 GB
クラスター サイズ = 4 KB
使用領域 = 30.00 GB
空き領域 = 17.84 GB
断片化:
断片化された領域の合計 = 41%
ファイルあたりの断片の平均 = 10.17
移動可能なファイルとフォルダー = 158455
移動不可のファイルとフォルダー = 8
ファイル:
断片化されたファイル = 4161
断片化されたファイルの総数 = 1324010
フォルダー:
フォルダーの総数 = 14111
断片化されたフォルダー = 1009
断片化されたフォルダーの総数 = 4369
空き領域:
空き領域の数 = 2378
空き領域の平均サイズ = 21.40 MB
空き領域の最大サイズ = 1.78 GB
マスター ファイル テーブル (MFT):
MFT サイズ = 829.25 MB
MFT レコード数 = 849151
MFT 使用量 = 100%
MFT 断片化の合計 = 0
注意: 64 MB よりも大きいファイルの断片は、断片化の統計情報には含まれません。
>
「シン プロビジョニングされたボリュームで、スラブの統合を実行してスラブの使用効率を高めます。」らしい、/kオプションをやってみたが、効果なし。
> defrag c: /v /k
(C:) の スラブの統合 を起動しています...
操作は正常に終了しました。
Post Defragmentation Report:
ボリューム情報:
ボリューム サイズ = 47.84 GB
クラスター サイズ = 4 KB
使用領域 = 30.00 GB
空き領域 = 17.84 GB
割り当て単位:
スラブ数 = 12541951
スラブ サイズ = 4 KB
スラブ配置 = 0 バイト
使用中のスラブ = 6048553
スラブ統合:
スペース効率 = 100%
消去可能なスラブ = 0
移動不可能なスラブ = 0
正常に消去されたスラブ = 0
回復した領域 = 0 バイト
トリムの再実行:
バックされた割り当て = 12541951
トリムされた割り当て = 6493398
トリムされた全領域 = 24.76 GB
>
3rd partyツールを利用した、より深いボリュームの縮小
Windows標準のコマンドでは埒が明かないので、最終的に、Paragon Partition Managerでパーティションのサイズを変更した。Minitools Partition Wiserdでは、再起動させてブート時にパーティションサイズ変更をしようとしてもDisk Driverを読み込めないというエラーが出てサイズ変更ができなかった。
なお、パーティションサイズの変更の前に、ディスクのチェックを行っておくこと。パーティションサイズ変更時にエラーが出る場合がある。
> chkdsk /r c:
ファイル システムの種類は NTFS です。
現在のドライブはロックできません。
ボリュームが別のプロセスで使用されているため、CHKDSK を
実行できません。次回のシステム再起動時に、このボリュームの
チェックをスケジュールしますか (Y/N)? y
次回のシステム再起動時に、このボリュームはチェックされます。
>
パーティションサイズ変更後の作業（ゼロフィル）
パーティションサイズが変更できたあと、最終的に、イメージファイルの中で0で埋められた領域を圧縮するコマンドを使って、イメージファイルを圧縮するので、パーティションの中身（不要領域）をゼロフィルする。
使うツールは、Sysinternalsのsdeleteコマンド
https://learn.microsoft.com/ja-jp/sysinternals/downloads/sdelete
未利用領域は、とりあえずNTFSでフォーマットして、D:のドライブレターを振った。「管理者として実行」したcmdプロンプトから実行。
> sdelete.exe -z d:
SDelete v2.05 - Secure file delete
Copyright (C) 1999-2023 Mark Russinovich
Sysinternals - www.sysinternals.com
SDelete is set for 1 pass.
Free space cleaned on D:\
1 drive cleaned.
> sdelete.exe -z c:
以下省略
（参考）ゼロフィルはWiddows標準のformatコマンドでもできる（/p:0オプション）のだが、シンプロビジョニングされたディスクイメージに対してはクイックフォーマットオプション（/q）の指定が必須のため、利用できなかった。
C:\Windows\System32>format d: /fs:ntfs /p:0 /norepairlogs /notrim
ファイル システムの種類は NTFS です。
簡易フォーマットを使用せずに仮想プロビジョニングされたボリューム D:をフォーマットすることはできません。
C:\Windows\System32>format d: /fs:ntfs /p:0 /norepairlogs /notrim /q
ファイル システムの種類は NTFS です。
警告: ハード ディスクのドライブ D: のデータは
失われます。
フォーマットしますか (Y/N)? y
クイック フォーマットしています 35.5 GB
ボリューム ラベルを入力してください。
(半角で 32 文字、全角で 16 文字以内)
必要なければ、Enter キーを押してください:
ファイル システム構造を作成します。
フォーマットは完了しました。
35.5 GB: 全ディスク領域
35.5 GB: 使用可能領域
C:\Windows\System32>
ホストOS側での作業
ゲストOSのイメージファイルのゼロフィルが終わったら、ホストOSのLinux側に戻り、qemu-img convertを行う
# qemu-img convert -O qcow2 元のイメージファイル.img 圧縮後のイメージファイル.img
圧縮後のイメージファイルで正常起動することを確認する。
2024年11月12日 公開（1月27日に基本部分は完了していたが、思ったレベルまで縮小できなかったようで書きかけだった）
0 件のコメント:
コメントを投稿