韓国金浦国際空港にあるロッテシティホテル裏の公園にある道しるべです。帰りの便のチェックインまで時間が多めにあったので、食べ物を買い込んで外で遅めの昼食をゆっくり食べたときの写真だったと思います。韓国のオフィスは日本から一番近い外国のオフィスで、関空ー金浦便で１時間半、関空ー仁川便でも２時間弱で到着します。問題は空港から遠くて、リムジンバスで２時間ほど走る必要があります。電車でも同じ場所につけるのですが、乗り換えで熟睡できないのでバスを使うことがほとんどです。バスも目的地は終着駅ではないのですが、外人であることを前面に押し出して、このバスストップで降りたいので、着いたら教えて？とドライバーさんに伝えておきます。ちゃんと起こしてくれるのですよ、これが 🙂 宿とオフィスの間の移動は地下鉄を使用しますので、一度は地下鉄で空港からオフィスまで移動してみたいと思っています。いつのことかはわかりませんが。。。現在金浦空港は国内線がほとんどのようで、日本との直行便は羽田との間しかないようで、それ以外は仁川発着となるようです。この頃の韓国航空会社は大韓航空かアシアナ航空で着陸に失敗したり、離着陸時に管制官に怒られたりと話題の尽きない状況でした。ナッツリターンなどという間抜けた話も覚えておられる方も多いのではないでしょうか？
root file system
さて、package さんでアプリケーションをコンパイルしていたのですが、コンパイル開始前は余裕の 33% の使用だったのですが、
コンパイルが完了してインストールを終えた段階で 100% の使用率となってしまいました。make clean をすれば使用率はまた余裕になるのですが、大きかったポーツがアップデートされてコンパイルしなおしになるときにはディスクが溢れるのが目に見えていたので、忘れないうちにファイルシステムを拡張しておきたいと思います。使用している仮想環境は VMware Player であるせいか、ゲスト OS が動いている状態ではディスクサイズを大きくできませんでした。もしかしてライセンスを買って VMware Workstation にしたらできるのかもしれませんが、とりあえずできないので OS を停止します。
VMware Player の仮想マシンの設定を開いて、ディスクを選択すると Expand ボタンがディスクユーティリティに見えます。
Expand Disk Utility を開くと元々の 30GB の値が入っているので、例えば 32GB 程度にして、Expand ボタンを押します。
Expand は成功したとメッセージが表示されて、再パーティショニングとファイルシステムの拡張を行うようにとお知らせが表示されます。お知らせの通りに FreeBSD 内部で行います。
disk drive expansion in VMware Player
ディスクを拡張した仮想マシンを起動してログインします。ディスクドライブは拡張されているはずですが、OS からは何の変化も見られません。
まず古典的な方法の fdisk で状況を見てみましょう。すると、パーティションは1つで、EFI GPT の id が見えます。勿論インストールする時にどうしたかを覚えていれば GPT パーティションの変更することも思いつくかもしれません 🙂 しかし、非常に古いマシンや、他人がインストールしたマシンは素性がわからないので、まずは調べてみましょう。
gpart
FreeBSD で GPT パーティションを取り扱うには gpart コマンドを使用します。gpart で割り振りがどうなっているか見てみます。
ディスクの先頭には 512KB のブートブロックがあります。その続きの 28GB がファイルシステムに、その続きの 1.5GB はスワップに使われています。その続きに追加した 2GB ( 実際には 2.5GB 程度のようである ) が続いています。ファイルシステムタイプも調べておきます。
swapoff
さてここでやりたいことを整理しておきます。２つ目の UFS パーティションにスワップパーティションを隔てた空き領域を連続領域として追加するということになります。Linux でおなじみの LVM などを使えば連続していなくても追加は簡単なのですが、FreeBSD で行うにはスワップパーティションに移動してもらわないといけません。移動といってもズリズリと動いてもらうことはできないので、このような手順で行います。
- スワップ領域を削除
- UFS 領域を 2GB 拡大
- 残りの部分にスワップ領域を作り直す。
という手順を踏む必要があります。スワップ領域を削除するにはまずスワップ領域を使用しないようにする必要がありますし、再作成されたら再度使用するようにする必要もあります。それらを行ってみます。まず pstat でスワップ領域が使われていることを確認します。もし、pstat の Used が 0 意外であった場合、スワップを切り離すことができないと思います。swapoff のマニュアルにはこのようにあります。特に赤字の部分です。
The swapoff utility removes the specified swap devices from the system.
If the -a option is used, all swap devices in /etc/fstab will be removed,
unless their “noauto” option is also set. If the -L option is specified,
only swap devices with the “late” option will be removed. If the -q
option is used, informational messages will not be written to standard
output when a swap device is removed. Note that swapoff will fail and
refuse to remove a swap device if a very conservative check does not
conclude that there is sufficient VM (memory + remaining swap devices) to
run the system. The -f option turns off this check, which could deadlock
the system if there is insufficient swap space remaining.この記述からすると、仮のスワップファイルを作成して、削除しようとしているデバイスの使用済みスワップ領域を移動させることができるだけの余裕があれば swapoff は成功するようです。思うに物理メモリにこの領域を期待することはできないと思います。メモリに余裕があればスワップは使われないからです 🙂 ですので、できるとしてもスワップファイルを作成して、一時的にスワップとして使用できれば可能になりそうです。でも、これもあまり良いアイデアとは思えません。なぜなら既にファイルシステムも一杯なので、スワップ用のファイルが作れないと思います 🙂 もしこの条件を満たすことができても swapoff が成功しないならメンテナンスウインドウを設けて /etc/fstab のスワップをコメントアウトして再起動しましょう。起動直後であればスワップが使用されていない可能性は非常に高いですので。それでもだめならメモリを喰いそうなアプリの起動を止めて再起動、かな？
状況確認の上、swapoff コマンドでスワップ領域を使用しないようにします。
swap エリア削除
スワップ領域を削除します。
UFS パーティションを 30GB にまで拡大します。
スワップ領域を再度作成します。ディスクはできるだけ無駄のないように使用しましょう。因みに 1TB = 1024GB、1GB = 1024MB、1MB = 1024KB、1KB = 1024B のはずです。ですので、2GB と指定すると、実は 2048MB となり、1MB 足りなかったようです 🙂
スワップ領域のデバイス名は変わっていないはずなので、/etc/fstab に変更は不要ですし、swapon -a で全ての定義済みのスワップ領域を使用するようにしましょう。
growfs
さて、UFS パーティションも 2GB 大きくなったので、その部分をファイルシステムとして使用できるようにファイルシステムを拡張します。サイズを指定しなければ可能な限り大きくしてくれます。
これにて拡大完了です。
余談ですが、UFS には minfree と呼ばれる root ユーザだけが使用できる領域があります。昔の UNIX のファイルシステムではデフォルトで 10% 予約されていましたが、現在のデフォルト ( 少なくとも FreeSD ) では 8% となっているようです。ですので、一般ユーザがディスクを使用してゆくと 100% になった段階で File System Full となってそれ以上ファイルを作成や拡大ができなくなります。ところが root ユーザは 110% や 108% まで使用することができます。root ユーザはシステム管理を行いますので、一般ユーザに邪魔されないように余裕を持っています。minfree の領域が昔の 10% から 8% に変更になった背景にはディスクが安くなって巨大なファイルシステムが安価に利用できるようになったことがあると思います。私が UNIX を使い始めた頃のように巨大(?)な 512MB ディスクにファイルシステムをつくったとして、その 10% というと、約 50MB 程度になります。このエリアにファイルがいくつ作れるでしょう？ 一方、TB 級のファイルシステムだとどれくらいになるでしょう？1TB のファイルシステムとすると、100GB となります。さて、このエリアに 512MB ディスクがいくつ入るでしょう 🙂 これだけ巨大なファイルシステムが簡単に使える時代になっても未だに 8% の領域が予約されているのにはもう一つの理由があるからです。UFS の仕組み上、残りサイズが 10% を切ると、ファイルシステムとしてのパフォーマンスがガクッと悪くなってきます。そこでデフォルトを 8% にして、管理者の判断でこの大きさを変えることができるようになっています。例えばシステム領域のアップデートが緩やかなファイルシステムに使用する場合は 8% を 5%、4% などと変更できます。逆に /home などのアップデートの激しい領域には 8% を 10% にしたり 15% にしたりします。管理者の裁量です。方法的にはファイルシステムを作成後、tunefs で mnfree のサイズを変更します。1TB の全社共通の読み出しメインのソフトウェアアーカイブ領域に 100GB の minfree はあまりにもあまりなので、私なら 1% 程度に抑えたいところです 🙂 ご興味のある向きには man tunefs と叩いてみてください。
disk drive expansion in VMware ESXi
今回は VMware Player の制限 (?) でゲスト OS を停止して作業をしましたが、VMware ESXi などのハイパーバイザーなどだと OS を停止する必要もなくファイルシステムの拡張ができます。勿論メンテナンスウインドウを設けて作業できればそのほうが良いとは思いますが。。。手持ちの ESXi での実験です。インストール直後に dd コマンドで単一の巨大ファイルを作って 99% にしてみました。
ESXi の仮想マシンのプロパティを開くとディスクのサイズは変更できるようになっています。
同じように 2GB 拡大してみます。
拡大前後で OS には何の変化も知られません。
GPT ディスクの使用状況を見ても変化はありません。
camcontrol
そこで何をするかというと、ディスクを再度プローブして変化を OS に認識させます。camcontrol でつながっているデバイスを確認します。もし変化が認識されない場合はバス番号、ターゲット番号、LUN 番号を指定してディスクを再スキャンさせます。
camcontrol reprobe で再プローブさせます。エラーなく終了すると、指定したディスクは指定した分だけ大きくなっていると思います。今回の場合、サイズが 8.0GB から 10GB になっているのが確認できます。
後は VMware Player で行ったことをやってゆけば OS を止めることなくファイルシステムの拡張ができるはずです。
金浦空港着陸直前です。大きく旋回しているところです。日本からの3億ドルの無償提供資金で大きく成長した韓国経済の代名詞の “漢江の奇跡” でおなじみの “漢江” も少し見えています。
こちらが地上から見た “漢江” です。
日本でおなじみの食べ物ですが、見慣れぬ文字が書かれています 🙂 でもそれが何かすぐにわかります 🙂 ご近所の国アルアルです。
今回はヨーロッパから来た IT supporter との共同作業です。羽田で待ち合わせて金浦へ、そして晩飯へ 🙂 晩飯は重要です。彼も今では Microsoft Products の管理者に出世したようです 🙂
同じく海老せんとビールの組み合わせですが、問題はそこではなくテレビの画面です。画面の文字を見てみると、内閣解散の前後の安倍(当時)総理の会見と思われます。政治に明るいほうではなかったのですが、もう見ることもないのかと思うと寂しい限りです。。。
可能な限りデフォルト値を使用して最新の FreeBSD をインストールしてゆくと ZFS を使うことになります。ZFS は UFS に比べるとはるかに融通が利くボリュームマネージャのように見えますが、アーキテクチャに制限があるなど、公式のボリュームマネージャと言えるかというとちょっとクエスチョンマークがつきます。使用するメモリも大きいですし、OS がクラッシュしたときのリカバリなど、これまでの経験がそのまま使えるとも思いません。FreeBSD で得た ZFS のオペレーションが他の OS でそのまま利用できるかというと、そうでもなさそうな記事をよく見ます。ちょっと FreeBSD で ZFS を使った遊び、失礼、勉強をする必要があります。そのうちに ZFS 関連の記事も書けると思います。個人的には何か変わったものや独自のものもいいですが、Linux の LVM などのように枯れたソフトウェアもいいんじゃないかと思います。初めて LVM を使ったのは大昔に HP-UX を使っていた時だったと思います。その時に使っていた lvdisplay や lvcreate 等々関連のコマンドがそのまま Linux でも使えるということです。人気を得るには広く知られているものが使えるというのも大きなアドバンテージだと思います。
以下広告
コメント