9.2 系もかなり無茶な負荷をかけた場合には落ちましたが、 明らかに 9.3 系にしてから頻度が高くなり「もろく」なりました。
我が家ではバックエンドの環境を上記二台に集約していて、 かつ仮想マシンのイメージも NAS4Free が管理するストレージ上にいるので、 NAS4Free が落ちると、一撃全滅です。
この窮地に際して、まずは NAS4Free v9.3.0.2.1190 を 再度、クリーンインストールもしてみましたが、当然のことながら結果は変わらず、 途方に暮れ、真っ白になったところまで行き着いて… ひらめきました (^^)b
この症状が起こるのは、仮想マシンにインストールした Windows 7 からのみで、 Windows 7 をインストールした実機から ギガバイトクラスのファイルを転送しても起こったことがありませんでした。
仮想マシンのイメージは NFS でマウントされた NAS4Free の管理している ストレージ上におり、また転送先も Samba (CIFS) 経由しているとは言え、 NFS でマウントした NAS4Free の管理している領域です。
これが大きなサイズのファイルを仮想マシンから転送すると高負荷がかかる理由ではあるのですが、 こう考えたとき、直感的に NFS の設定が問題なのではないかと疑い始めました。
以前から Samba で公開している NFS マウントしたストレージ領域は、スループットを上げるために、 NFS マウント時のパラメータを初期値から変更しています。
ところが ESXi から NAS4Free への NFS マウントは、 何も考えずずっとパラメータ指定なし（初期値）でマウントしています。
通常、 NFS ではライトバッファ (rsize) ／ライトバッファ (wsize) の初期値は 65536 ですが、 ファイルサーバーとなっている CentOS からは、 これより小さい 4096 を指定していました。
これで実際、 NAS4Free v9.2 系を使っていたときは、 外付けストレージのインターフェイスを USB 2.0 でしか認識してくれなかったのですが、 その状況下ではスループットは上がっていたので、 v9.3 系にアップグレードしたときもそのままの設定にしていました。
なんの根拠もなかったのですが、これが何となくあぶなそうに思ったこと、 CentOS で指定している他のパラメータは、 NFS マウントしている領域を Samba で公開しているため、 このバッファサイズの指定以外のオプションを変更するとファイルサーバーとしての機能に問題が起こりそうだったので、 ひとまずバッファサイズだけ初期値に戻して（オプション指定なしにして）試してみました。
おっかなびっくりで 2GB 程度のファイルを転送してみると…落ちません！やりました！！ (^^)/
Samba 経由でのファイル転送時のスループットは若干落ちたような気がしますが、 それでも 9.3 系になって USB 3.0 が有効になった効果の方が大きく、 USB 2.0 でしか認識してくれなかった 9.2 系のときに比べれば、十分に早く、気になるほどではありません。
またこれまでファイルを転送すると、異常に CPU 負荷が高くなっていたのですが、これが少々ましになりました。
そして、それより何より、仮想マシン上からギガバイトクラスのファイルを同時に二つ転送（ 9.3 系にしてから 百発百中で落ちていたシチュエーション）しても、びくともしなくなりました (^^)b
そして、気をよくして、改めて NAS4Free を 9.3.0.2 rev1190 から rev1213 にアップグレードもしましたが、（今のところ）異常なし。
やってやりました (^^)v
# なんで 9.2 系の時は落ちなかったかという真の原因は理解できていないのだけれど…
22 日（月）に会社を休んで四連休を作り上げたのに、始終、この問題の解決に頭を悩ませ、 「優雅」とは縁もゆかりもないお休みになってしまいました orz
しかし、これでハードウェアを使いこなせない問題（ネットワークインターフェイス、 USB 3.0 ）はなくなり、 精神衛生上も安心して使えるようになったので、 当面、この環境で安定運用できている限り、うかつにバージョンアップとかしないようにします。
特にメジャーバージョンアップにはほんと気をつけます <(_ _;
「 NFS でマウントした領域を Samba(CIFS) で公開してはいけないらしい」
「 NAS4Free v9.3.0.2 系への移行に苦労した話」
