VirtualBox を使って Linux ディスクのパーティションサイズ変更の練習をしてみました。
ある仮想マシンの仮想ディスクである ubuntu.vdi のディスク容量の空きが少ないからファイルを削除するようにという警告が出たので対応しました。
ubuntu.vdi の一部のデータを ubuntu-work.vdi といった別の仮想ディスクへ移動しました。ただ、移動した分量があまり多くなかったので ubuntu.vdi はそのままでいいか、という感じになりつつ、作業をしました。
バックアップしてから、ubuntu.vdi を操作することにします。
Ubuntu インストーラー用の iso ファイルを使って起動する仮想マシンを用意して作業しました。この仮想マシンを Ubuntu2204ja と呼ぶことにします。
- バックアップ用に新規に十分な容量を持つ空の仮想ディスク disk01.vdi を追加
- バックアップしたいディスク ubuntu.vdi のクローン ubuntu-clone.vdi を作成（作業中に壊した場合のため。心配がないなら不要）
- Ubuntu2204ja の設定でストレージデバイスへバックアップしたいディスク ubuntu.vdi を追加
- Ubuntu2204ja の設定でストレージデバイスへバックアップ先のディスク disk01.vdi を追加
このとき、SSD においてある仮想ディスクは、Ubuntu2204ja の設定のストレージの属性にある SSD にチェックします。HDD においてある仮想ディスクの場合は、Ubuntu2204ja の設定のストレージの属性にある SSD のチェックはしません。
設定ができたら、仮想マシン Ubuntu2204ja を起動。
ディスクユーティリティを起動して、デバイスファイル `/dev/sdb`、`/dev/sdc` に対応しているディスクがどれなのかを確認。disk01.vdi はフォーマットしていないのでわかる。
次に、`sudo gparted` コマンドで GParted を起動して、disk01.vdi のパーティションテーブル作成、パーティション作成、フォーマットの実施。
それから、ubuntu.vdi と disk01.vdi をマウントして、ファイルをアーカイブ。
ubuntu.vdi で Ubuntu の `/` ディレクトリーにマウントしていたパーティション（`/dev/sdb2`）を `/mnt/sdb2` へマウント、disk01.vdi のパーティションを `/mnt/sdc1` へマウントしたとします。次のようにアーカイブします。
cd /mnt/sdb2/ && sudo tar cvf /mnt/sdc1/ubuntu_root.tgz ./*
圧縮アーカイブしたら、230 GB が 32 GB ぐらいになりました。圧縮されすぎな気もしますが、どうなのでしょう。
それから、`/dev/sdb2` にあるファイルを削除してから、アーカイブファイルを展開しようと思ったのですが、念の為、`/dev/sdb2` をフォーマットしなおしました。これでちょっと大変なことになりました。実際のところは、ディスク交換するときは、そういうことになるから、まぁ、良いのですけど…
フォーマットをしたら、ディスクの UUID が変わってしまったので、grub の更新が必要になりました。`grub.cfg` ファイルの編集だけでは駄目なようで、`grub-install` コマンドと `update-grub` コマンドを使った起動用ファイルの方も再生成が必要なようでした。これについては、微妙なところはあります。
起動する仮想マシンとは別の仮想マシンで `grub.cfg` のファイル編集をしていて、別の仮想マシンを終了させるまで、これに反映がされなかったかもしれないという疑惑があります。編集で使っていた仮想マシンを終了すると、それが仮想ディスクに反映されて、そちらであれば、起動用ファイルの再生成まではしなくても良かったかもしれません。
grub の再生成には「2018年12月版 USBメモリ起動のLinux（Ubuntu18.04）をWindows10マシンで作成する方法 | hiro345」を毎回参照しています。過去の自分、ありがとう。
いずれにせよ、`/etc/fstab` の `/` 用 UUID をgrub の更新をしたら起動しました。整理すると下記の通り。
- フォーマットをすると、UUID が変わってしまった
- tar で保存し、tar で展開したら動いた
- EFI の /efi/ubuntu/grub.cfg に GRUB の設定ファイルがある
- UUID が変わった場合は、grub の更新をしないと起動しなかった
一応、動作したので、そのまま使い続けても良かったのですが、日常的に使っているものだったのでデータ欠損などがあったら嫌だなぁということで、バックアップしてあったディスクの方へ戻しました。
たぶん、tar でアーカイブしてから展開するというのは、ファイルシステムでのファイル操作となるので、仮想ディスク内でフラグメンテーションが発生していたとしても、それを解消する形で展開されるのではないかと想像していたりするのですが、そのあたりの確認はできませんでした。どうやれば確認できるかも調査できていません。
それから、ubuntu.vdi について、仮想メディアツールでディスクのサイズを増やして「適用」としました。本当は減らしたかっったのですが、ディスク容量が足りない警告が出ていたことへの対応が必要だったので、増やすことにしました。その後、Ubuntu2204ja を使って、ubuntu.vdi に対して GParted でパーティションの拡張作業をしました。
GParted は GUI で操作ができるからありがたいですね。パーティションのリサイズでサイズを拡大して、後は適用するだけでした。
さて、実際に対応したいことはできたのですが、Linux の ext4 ファイルシステムではデフラグはできないようなので気になっています。もともとの動機は、１度サイズが増えた動的に容量が変わる仮想ディスクについては、ファイル削除をしても仮想ディスクのファイルサイズは小さくならないので、これを減らしたかったというものでした。
ubuntu.vdi は 250 GB 以上のファイルサイズなので、これが連続して記録できた方がよいはずなのですが、今回は HDD へ保存しているわけではなく、SSD へ保存しています。SSD へファイルはどのように保存されているかの正しい知識がないのですが、SSD は HDD と違って大容量ファイルであっても連続している必要がないような気もしています。最近の HDD も、もしかしてそうだったりするでしょうか。SSD ではデフラグをする必要がないという話もあるので、「デフラグをそもそも気にする必要はないのかもしれないなぁ」とも思っています。
このあたりのディスクの記憶領域の物理的な話までは、最近は確認できていないので、とりあえずはデータ欠損がない確実な方にしておくということにしました。
ディスク操作は時間のかかる作業になるので、余裕があるときに、いろいろ試して知識のアップデートをするわけですが、なかなか大変です。仮想化ソフトウェアという特殊な環境でのファイル操作だというのも物事を難しくしています。やれやれ。