linuxを起動させると、OSの起動画面まではいくが、
その後、以下のエラー文を吐いてフリーズ。
「kernel panic - not syncing : fatal exception」

ということで
１．CentOS 5.5 を シングルモードで起動させる。

CentOS 5.5 のカーネルバージョン画面でキーボードの「e」を押す。
↓
OSの選択起動画面に移行するので、「kernel」から始まる行を選び。「e」を押す。
↓
コマンド入力出来るようになるので、
「スペースキー」で一文字空けて「single」と入力しエンター。
↓
「[スペース]single」という記載が追加されるはずなので、それを選択し、「b」を押す。


２．間違えてOSの選択起動画面でエンターを押したところ、
そのまま普通に起動してくれてしまった。
（日本語おかしいですが察して下さい。）

ということで原因は不明で根本的な解決には至っていませんが、
困っていたら試してみて下さい。

W-ZERO3[es]　に非常にシンプルなhtmlファイルを一つのみ設置し、
オートリロードツールで負荷をかけたところ動作を停止しました。

ということで、本サイトでの結論。
W-ZERO3[es] + ServersMan@Windows MobileによるWebサーバでは、
常時公開することは出来ない。

なお、iPhone版の動作は非常に良好なため、
今後はServersMan@iPhone を軸に実験を進めたいと思うのですが、
iPhoneは常時サーバ化させるほど暇ではないので、
中古のiPod touchを買ってこようかと画策中です。

うーん。しかし非常に残念。

補足：
複数のマシンから同時に負荷をかけた所、簡単に動作停止に追い込めました。
逆に、単一のマシンから負荷をかけても落ちたりはしませんでした。
その辺はちょっと気になってたりします。

結論から言うと動作改善はされませんでした。

iPhone　と W-ZERO3[es]　で全く同じファイル構成にして、
自動でリロードするプラグインをfirefoxに入れ、負荷をかけたところ、
iPhoneでは問題無く動作し、W-ZERO3[es]では動作が停止しました。

ということで、W-ZERO3[es]を利用したServersMan@Windows Mobileによる
Webサーバは端末の問題から限界がある、という結果でしょうか。

なお、現在は同じURLで、ServersMan@iPhoneにて公開しています。
後ほどページの内容を更新します。

これまで、長時間起動したり、同時アクセス要求がかかったりすることで
簡単にフリーズしていたSeversManですが、動作改善の見込みを得ました！

これまでjsとcssをデフォルト外のフォルダから参照する設定だったのを、
ルートディレクトリから参照することで動作改善の希望があります。

iPhone版との動作比較も行っており、今後に期待できるかも知れません。
以前友人にお願いし、同時アクセスをかけたところ３人で数回アクセスしただけでダウンしたので、
どれくらい改善されたかまた報告します。

iPhone版に同様のページを配置して動作比較を行おうとしたところ、
新規フォルダを作る手段がないことに気づきました。

ひょっとして、デフォルトのフォルダ外からのアクセスは負荷が高いのでは？
という仮説です。

もしこれで駄目な場合は、全く同じファイル構成・URLにてiPhoneで公開し、
動作確認を行います。

それによってハードウェア性能にどの程度依存するか見たいと思います。

取り急ぎの更新。
後日修正します。

外付けHDD増設によるファイルサーバ領域拡大

ファイルサーバの保存領域拡大のために、
外付けHDD(1TB×2でRAID1)をマウントした。

■作業内容
参考になったURL:
・マウントの流れ
http://d.hatena.ne.jp/SumiTomohiko/20080524/1211628731
・フォーマット手順・tips
http://www.obenri.com/_command/fdisk01.html

・外付けHDD(2TB)を1TBのRAID1で設定した。
（失敗1）その際ファイル形式をNTFSとしてしまった。

・ファイルサーバマシンにUSBにて接続した所、
/dev/sdb1/ と /dev/sdb5/として認識した。
しかしファイル形式が異なるため、フォーマットを行った。
 
その際ext3 / raiserfs どちらにするか悩んだが、
・raiserfsは細かいファイルが多数あるような場合に適している。
・ext3の方が参考文献がそろっている。
・他のディレクトリを確認した所、どちらのファイル形式も使用されている。
などから、ext3で再フォーマットを行った。

注意点として、
sdb1は操作できず(unable to open)、sdb5は操作できた。
これは、sdb1の方がraid1のバックアップとして働いているためだと思われる。

・フォーマット完了後、改めてマウントしなおし、
再起動時に自動的にマウントされるよう、fstabの設定を書き換えて作業を完了した。

■行った対応

 [Linux] 外付けUSBハードディスク全体をext3でフォーマットし、マウントする。

1.HDDをmanetに接続。認識したので、(NTFS形式のまま)一回マウントを実行する。

パーティションの確認
$ fdisk /dev/hdb
  　sdb1とsdb5で、RAIDが組まれていることを確認

実際にマウントしてみる。
$ sudo mkdir /mnt/usb-hdd
$ sudo mount -t auto /dev/sdb5 /mnt/usb-hdd

$dfコマンドで確認を行う。

2.ファイル形式をlinuxに対応しているext3にフォーマットする。

確認後、大丈夫そうだったので（フォーマットするために）アンマウントを実行する。
$ sudo umount /dev/sdb5
※フォーマットはマウントされている状態では実行できないため※

その後、ext3でフォーマットをかける。
$ sudo mkfs.ext3 /dev/sdb5

3.マウントを手動で行い、再起動時に自動でマウントされるよう設定を書き換える。

$ sudo mount /dev/sdb5 /mnt/usb-hdd でマウント完了
$dfコマンドで確認を行う。→大丈夫そう。

自動でマウントされるようにfstabの設定書き換え
$sudo nano /etc/fstab

以下を追加した。
  # file system  mount-point    type    options    dump  fsckorder
    /dev/hdb5    /mnt/usb-hdd   ext3    default       0          2

■現状
外付けHDDは/dev/sdbとして認識されており、
/dev/sdb5 が /mnt/usb-hdd/ にマウントされた。
(/dev/sdb1/ がRAID1のバックアップに使用)

使用した外付けHDDはUSB接続で、1TB×2HDDで構成されている。
ハードウェア上で設定してRAID1を組み、保存領域1TBの拡張が成功した。

参考
http://www.atmarkit.co.jp/flinux/rensai/linuxtips/756fstabnum.html
※dumpの項目は、ファイルシステムをdumpする必要があるか否かの指定。
   「0」または無記述の場合はdump不要のファイルシステムを示す。
※fsckorderの項目は、システム起動時にfsckチェックを行うか否かの指定。
   「0」の場合はチェックを行わない。
    ルートファイルシステムでチェックを行う場合は「1」を指定する。
    また、ルートファイルシステム以外でチェックを行う場合は「2」を指定する。