VMWare4のせいか
vmshrinkでディスクファイル（VMDKファイル）がうまく圧縮できない。
この時点で使用容量は４．４Gバイト。なのにVMDKファイルは１２Gバイトもある。
仕方が無いので、X-Window上のVMWare-Toolboxを使うことにする。
しかし、X-Windowは入れてない・・・。
まずはX-Windowをインストから、

# yum -y groupinstall “X Window System”

# yum -y groupinstall “Desktop”

# yum -y groupinstall “General Purpose Desktop”

このまま startx するとマウスもキーボードも使えなかったので日本語化パッチも入れる。

# yum -y groupinstall “Japanese Support”

# startx

やっと動く。
本体のCPUがAMD E350で論理CPU１個、メモリ５１２MBしか割り当ててないのに、初期のVistaよりちゃんと動く、X-Windowって、とっても凄いと思う。
だがVMWareToolboxの動作が心配なので、一旦X-Windowを終わり、前にインストしたVMwareTools-8.8.1-528969.tar.gzをインストしなおす。

# ./vmware-install.pl

いっぱい応答入力が必要だが、全部[ENTER]で済ませる。

ここまでで使用容量は５．３Gバイトまで増量。環境整備で０．９Gバイトも増えた。
再起動した後に# startx。
メニュー⇒アプリケーション⇒システムツール⇒Terminalを起動。

中でVMツールをバックグラウンドで起動する。

# su –

# /usr/bin/vmware-toolbox &        （必ずバックグラウンドで起動すること。）

で、やっとVMWare-Toolboxの画面が出たら、先のTerminalのウインドウを必ず閉じる。

※閉じないとサービス終了待ちのプログレスバーが何時までも終わらなくなる。

shrinkタブを選択し、『 / 』を選択して下の【shrink】ボタンを押す。

確認メッセージで【Yes】を押す。

プログレスバーが長いので圧縮処理かと思ったら、ネットワークサービスを止めた後に、Nulデータを書き込んでいるらしい。

そのせいか、/rootディスクがいっぱいです、とかメッセージが出る時もあるが、当然【Ignore】だ。

先のプログレスバーが１００％（バーに隠れて見えないけど）になったら、shrinkしますか？で【Yes】を押してからが、本当のshrink処理が始まる。

そして長い長い処理が始まる。

終わったらちゃんとメッセージが出る。

でも、まだ９Gバイトまでしか圧縮できない。あと４Gバイトくらい圧縮できるハズなんだが・・・
すぐには思いつかなかったが、CentOS6は標準でディスクを２つのパーテーションに分ける。
１つ目は、ブートローダやカーネルが入っていて「/Boot」にマウントしているブート可能なパーテーション。

２つ目は、LinuxのLVMファイルで、

この中身は15Gバイトの「/」ファイルシステムと3.9Gバイトのスワップファイルだった。

# lvscan
  ACTIVE            ‘/dev/vg_******/lv_root’ [15.54 GiB] inherit
  ACTIVE            ‘/dev/vg_******/lv_swap’ [3.97 GiB] inherit

このスワップファイルは普通空のままだが、何かの原因でメモリ不足になると、とりあえず後回しにするデータが書き込まれる。実は、vmshrinkは「/」ファイルシステムの未使用部分にNulデータを書き込み、VMToolのディスク圧縮機能が働くようにしている様で、スワップパーテーションなんて眼中に無いようだ。
しかし、バックアップなどを簡単にするため、VLMにスワップファイルを入れることが多い、そうなると一度メモリ不足に陥ったサーバーでは、スワップファイルが最大まで実体化するので、このスワップデータ分がちゃんと圧縮できなくなるのだ。
ではどうすればよいのか？
一旦PowerOffし、VMWareでスワップ用のVMDKファイルを作り、2番目のディスクとして追加する。
起動後にスワップ用のVMDKファイルの中をスワップ形式でフォーマットし、再起動すればカーネルがSWAPパーテーションを勝手に認識するハズだったが、lvscanしてみると変化が無かったのでちゃんと開放した方がよさそうだ。
LVの情報を再確認。

# lvdisplay /dev/vg_******/lv_swap
  — Logical volume —
  LV Name                /dev/vg_******/lv_swap
  VG Name                vg_******
  LV UUID                ******- ******- ******- ******- ******
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                3.97 GiB
  Current LE             1016
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  – currently set to     256
  Block device           253:1

LVを削除。

# lvremove /dev/vg_******/lv_swap
Do you really want to remove active logical volume lv_swap? [y/n]: y
  Logical volume “lv_swap” successfully removed

削除後の情報を確認。

# lvdisplay
  — Logical volume —
  LV Name                /dev/vg_******/lv_root
  VG Name                vg_******
  LV UUID                ******- ******- ******- ******- ******
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                15.54 GiB
  Current LE             3978
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  – currently set to     256
  Block device           253:0

再び、X-WindowのDiskUtilityで見ると消したパーテーションがチャント消えていた。
再起動した後、VMWare-Toolboxのshrinkを再び実行すると、VMDKファイルは５．３６Gバイトまで圧縮された。
本来は「/」を容量いっぱいに拡張した方がいいのだろうが管理用の領域が増えるだけなのでこのままにしておく。

VMDKファイルが半分未満になったせいか、ブログの動きも速くなったかな。

しかし、唐突に
No root device found.
Boot has failed.sleeping forever.
になる。
再起動すると１００％再現する。
色々やってみたら、

１．スワップ領域を減らした場合は

swapoff     /dev/vg_******/lv_swap

lvreduce -L -128M  /dev/vg_******/lv_swap

resize2fs  /dev/vg_******/lv_swap

再起動しても問題ない。

２．スワップ領域を削除し、

swapoff     /dev/vg_******/lv_swap

lvremove /dev/vg_******/lv_swap

再起動すると、

No root device found.
Boot has failed.sleeping forever.

になった。

/etc/fstabからスワップの設定を削除し再起動した後にスワップ領域を削除しても同じだった。

インスト時に作成されたスワップ領域を削除すると、起動時にroot deviceが見つからなくなるようだ。
これはカーネルがLVMをどう検索してるのか調べてみないと直らないなぁ。
あ、スワップ領域を消した跡を/ に割り当てるなら、

lvextend -l +100%FREE /dev/vg_******/lv_root

resize2fs /dev/vg_******/lv_root

でいいらしい。
 

製造プロセス32nmの「Atom D2700」(クロック周波数2.13GHz)採用のファンレス小型ベアボーンと云うことで、ATOM初の2Ghz台。でもチップセットはNM10 Expressのままで、内蔵GPUはGMA 3150からGMA3650に替わっている。PowerVR SGX545をベースに組み込まれたものだそうだが基本性能はほぼ同じ（５０歩１００歩の差）でHDMIなどをサポートするようになった。それよりもメモリがDDR2-800MHzからDDR3-1066MHz対応に替わり、消費電力は１３W⇒１０Wに下がっている方に目が向く。
見つけた商品（もうすぐ発売予定）の情報は、

• ストレージ：mSATAインターフェースと2.5インチシャドウベイを1基。
• メモリー：DDR3 SO-DIMM×1、サウンド、ギガビットイーサネット×2。
• 映像出力端子にはDVI/VGA/DisplayPortの3系統を用意。
• ACアダプター付属、消費電力は15W(最大30W)。

ということでファンレス高級機らしく価格も5万5000円前後とリッパです。ファン必須ならJetwayのNC9KDL-2700などもある。
安いものだったはずのAtomのマザーボードがCPU付きとは云え、1万円以上するようになって人気落ちしていると思うのはボクだけだろうか？
実はファンレスPC（AtomでもAMD E350でも）って熱が篭るから２４時間稼動には向かない。
使う時だけ電源を入れて使い終わったら直ぐにパワーオフが原則だと思う。
使いっぱなしにしてメモリ化けし放題になったりHDDやSSDが逝かれても知らないよ？
（高価な車載専用パーツを使うなら別だろうけどね）
自分なり工夫してファンレス化した時は、２４時間稼動中で一ヶ月後に２．５インチのHDDからギーギー音が出てっぱ無しになりバックアップ完了と共にお亡くなりになりましたので、SSD化。しかしDC－DCコンバータに近いDDR2メモリが崩壊し交換。D510に変更後は再起動に失敗したり色々不具合が発生したので、音の小さな低速ファン付きのAntecのMiniITxケース（ＩＳＫ３００－６５※生産終了品）に変えちゃいました。そして今はAMD E350にしてみてる。

# ./vmshrink
(暫く後)
# BUG:  soft lockup – CPU#0 stuck for 1749s [vmshrink:27125]
どうやら、何度やってもダメ。
AMD E350を使っているせいかもしれないので、
Core i7 870でやってみたら、BUGは表示しなくなった。
だが、さっぱり圧縮しない。

ASCII.jpの

28nmの新設計GPU「Radeon HD 7970」は頂点に立つのか？

だ。
記事のグラフを見ると、GeForce GTX 580はなぜかOC（772GHz⇒816MHz）している。
１世代前のGTX５８０を用意したら偶然ASUSTeKのOC版製品だった？手配ミス？
NVIDIAの次世代GPU「Kepler」はフラグシップモデルが出るのは順当でも年末なので1月の今ならGTX580は現世代でいいんだけどな。
それでも、GeForce GTX 580（OC）は3DMark11でHD7970に及ばない。
３ページ目になると、SkyrimやFF-XIVで、やっとOCしたGTX580が逆転している。
nVIdiaの肩を持っているのかと思いきや、
消費電力もOCしたGTX580（当然多めになっているハズ）で出していて、訳が判らない内容になっている。
逆にHD7970の方だけOCすると凄いことになりそうだ。
※HD7970は、925MHｚ⇒1100MHzぐらいまでOC可。
それはそれで必死すぎだろう！とか言われそうだな。
なお、今年発売されたHD7970の価格は、5万円台前半（玄人志向　RH7970-E3GHD　￥52,800）～６万円台後半（アスク　HD 7970 3GB GDDR5　￥66,00）。

外付けの外部のHDDをe-SATAで本体と接続すると、
アクセスが遅くなったり、あげくにドライブリストの画面からHDDが消えてしまったり、異常続きでしたが、
USB接続に切替たところ、普通にアクセスできるようになりました。
他PCで接続しても同様の症状が再現できたので、
外付け用のHDD台のSATA接続機能に何がしかの問題が発生した模様です。
しかし、このHDD台は2台所有しており2台共同じ症状が発生したのでWindows７未対応なのかな？
実はこのHDD台がIDEモード専用でAHCIモードが未対応だったのかな？
気付かずにAHCIモードのまま使ってだけなのかもしれない。
そして段々と無理が溜まってエラー修復不能レベルまでゴミ情報が溜まってしまったのかもしれない。