社長：Firefoxのmakeはどうなりましたか？
開発：それが、makeを走らせておいたら1時間くらい走った後にディスクフルで終わってまして。それでどうやってこの仮想マシンで使えるディスクを拡大しようかということであれこれ、1日潰してしましました。
基盤：そもそもがこれ作る時に、まあ32GBあれば足りるだろうと思って、Hyper/Vで仮想ディスクの最大サイズを32GBに設定してしまったのが敗因ではあります。Hyper/Vの、使ってる分しか割り当てないモードで作ってるので、上限を厳しくする必要はなかったのですが。
開発：ディスクを大きくするのって、バックアップして差し替えてリストアするとか、すごく面倒臭いイメージがあるので、何かもっと簡単な方法はないかなーと。別の仮想ディスクをつけたほうが良いかなとか、この際リモートドライブにしたほうがにしたほうが良いだろうかとか。
基盤：で、バックアップも含めていろいろ作業しようとしたら、そもそもあちこちの物理ディスクが満タンになってしまって身動きがとれなかくなってたんです。作業スペースとして50GB程度は欲しかったのですが、Hyper/VホストのLenovoのSSD 250GBも満杯、MacMiniの250GBも満杯。Googleドライブも今のところ100GBしかなくて満杯。あれって、1TB付きのサブスクリプションてまだ契約してないんでしたっけ？あと、Macには一応、3年前に買った4TBのHDDがついてて3TBばかり空いてるんでしすが、リモートにHDDというのにどうも抵抗感があり・・・
開発：1TBのOneDriveは十分空いてるのですが、どうも様子が変で。結果的に気づいたのは、OneDriveはマウントするとローカルにキャッシュを持つので「OneDriveに移動した」はずのデータが実はローカルディスク上にあったというオチでした。これを消して80GBくらいローカルSSDが空いたので、ようやく作業に着手できました。
基盤：念のためVMごとバックアップしてはおきましたが、実はバックアップ作業不要でした。必要な作業はこれだけです。所用時間約5分。
1. Hyper/Vで仮想ディスクのサイズ上限を変更する
1.1 チェックポイントをマージして単一ディスクにする
1.2 ディスクの上限サイズを変更
2. 仮想マシン（Linux）でパーティションを拡大する
2.1 parted コマンドでパーティションをリサイズ （resizepart）
2.2 resize2fs コマンドでファイルシステムに反映
社長：ひゃー、マウントしたまま拡張できるですか。まあ長年、そうあって欲しいものだと思ってましたが、イマドキのOSではそうなってるんですね。良い時代になりました。
開発：いずれやってみますが、縮小するとどうなるかですね。
基盤：デフラグ的に前のほうに詰変えするでしょうから、きっと時間がかかるでしょうね。でも、データ転送量的には数ギガバイトなら、まあ1分仕事かなという気もします。
開発：VMごと配る時に、中身がちょうど収まるサイズにしたら、ゴミの入る余地がなくなって、多少小さくなるかなとは思いますね。
--
2020-0604 SatoxITS