Ellinikonblue.com Weblog

　年末、相当すったもんだして、Samba と NFS の設定もに直して、 GIGABYTE GB-BXCE-2955 にインストールした NAS4Free v9.3.0.2.1213 がやっと安定して動作するようになりました。

　いやはや快適です ^^

　年末、 NAS4Free v9.3.0.2.1213 が安定してから、 VMware vSphere Hypervisor (ESXi) 上の 仮想マシン、特に Windows 7 をインストールした仮想マシンへ 相当無茶な負荷をかけても落ちなくなり、ずっとノンストップで稼働を続けています。

　ここに至って、 USB 3.0 が有効になった NAS4Free v9.3.0.2.1213 で どこまでパフォーマンスが上がったか？
　例のごとく CrystalDiskMark で、 仮想マシンのローカルディスクへのアクセス速度を測ってみた結果がこちら…どん！ 　実は以前に GB-BXCE-2955 に SSD をぶち込んで ZIL/L2ARC を有効にした直後に測定したときと、あまり変わってなかったりする f^^;
　ちなみに v9.3.0.2.1213 移行以前、 NAS4Free に繋がっている 外付けストレージはすべて USB 2.0 で認識され、 ZIL/L2ARC を有効にしただけのときの測定結果はこちら。 　全くの私見ですが、 L2ARC が効いているので、実際の HDD への書き込みのスループットが大きくなっても、 仮想マシンのディスクイメージ上へのベンチマークのための書き込み程度ならキャッシュに収まってしまって 大きく差は出ないのかもしれません。
　つまり、少なくともうちの環境では仮想マシンのディスクイメージ内でのスループットは、 このあたりが上限ではないかと思っています。

　しかし、Samba 経由での ディスクへの書き込みは、ベンチマークで比較するまでもなく（＜取るのが面倒なだけです m(_ _)m ）、 圧倒的に早くなったことを体感できています。
　またこれも私見ですが、キャッシュ (L2ARC) があふれたとき、もしくはミスヒット時、 USB 3.0 で認識されるようになった恩恵で HDD への書き込み速度が上がっているので、 明らかに仮想マシンもきびきびと動くようになりました。

　結論、大変満足です (^^)
　今年はこの環境を有効に活用していきたいと思います。

Ellinikonblue.com Weblog
「 Samba と NFS の設定を見直しました」
「 NAS4Free v9.3.0.2.1213 が安定したという話」
「 NAS4Free で L2ARC/ZIL を SSD に設定した効果」

　先般、 NAS4Free v9.3 系へアップグレードしたとき、 NFS の設定が原因で安定しなかった反省から、 Samba と NFS の設定を見直してみることにしました。

　一度、設定が安定してしまうと、オペレーティングシステムを入れ替えても、 Samba などの設定はそのまま引き継ぎ、 使い続けている傾向にあるので、いい機会だと腰を落ち着けてやってみました。

　いろいろ試行錯誤はあったのですが、その過程はすっ飛ばして、 まず NFS の設定から。
　うちでは Samba を動かしている CentOS から NAS4Free で管理しているストレージに NFS でマウントをかけています。
　/etc/fstab に記載して起動時にマウントがかかるようにしてあり、 今回の見直しによって以下のようになりました。

192.168.0.1:/mnt/mnt_zfs/Lib /mnt/mnt_nfs nfs rw,noatime,tcp,intr 0 0

　ずいぶんすっきりしました。
　読み込み・書き込み時のバッファサイズの指定がなくなったこともそうですが、 ファイルロックの無効化 (nolock) も外しました。
　これはあとで書きますが、 Samba のオプション指定を増やして、 Windows 端末からのファイル書き込み時のエラーを回避できるようになったからです。

　次にその Samba の設定ですが、 CentOS 7 になってから Samba のバージョンが 4.1 系になっており、 SMB2 が明示的に指定しなくても最初から有効になっていることを知りました。
　つまり Samba 4.1 系なら、 Mac 0S X 10.9 Mavericks 以降、 Mac でもファイル共有のための最優先プロトコルとされた SMB2 を、 何も指定しなくてもしゃべってくれます。
　よって max protcol オプションをわざわざ記載しなくてもよくなりました。

　逆にうちでは SMB2 をしゃべることができない端末はなくなったので、 min protcol オプションというのがあって、試しにこれを設定してみたのですが、 Samba (CentOS 7) サーバーが ネットワークコンピューターに表示されなくなってしまったのでやめました。
　Samba 4.1 からは プロトコル関係のオプションは設定しない方がすっきりするようです。

　また NFS でマウントした領域を Samba で共有すると Windows 端末の書き込みでエラーになるために、 これまで kernel oplocks オプションでわざわざ無効にしていましたが、 いろいろ調べる内に oplocks/level2 oplocks オプションを無効にするという方法を見つけて、 実際、設定してみると NFS の nolock オプションはなくても問題なく Windows 端末から書き込みができ、 また kernel oplocks の初期値は no と言うことを知るにいたって、 うちの環境に依存した部分を除くと、最終的に global セクションに特別な設定は以下のようなものだけが残りました。

[global]
：（略）
  oplocks = No
  level2 oplocks = No
：（略）

　以上のように見直して、まだ約三日目ですが今のところ快調です (^^)b
　問題が起きたらまた報告します (_ _;A

　最後に格言、「わからないんだったらデフォルト（初期値）が一番！」
　あしからず m(_ _)m Ellinikonblue.com Weblog
「 NAS4Free v9.3.0.2.1213 が安定したという話」
「 NFS でマウントした領域を Samba(CIFS) で公開してはいけないらしい」
「 Samba の SMB2 有効化で Mac OS X 10.9 Mavericks のファイル共有高速化！」

　Intel D34010WYK にインストールした VMware vSphere Hypervisor(ESXi) 上に 作成した仮想マシンが、GIGABYTE GB-BXCE-2955 に インストールした NAS4Free を 9.2 系から 9.3 系へアップグレードした途端、ファイル I/O で負荷がかかると、 すぐに落ちるようになりました。
　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 ）はなくなり、 精神衛生上も安心して使えるようになったので、 当面、この環境で安定運用できている限り、うかつにバージョンアップとかしないようにします。
　特にメジャーバージョンアップにはほんと気をつけます <(_ _; Ellinikonblue.com Weblog
「 NFS でマウントした領域を Samba(CIFS) で公開してはいけないらしい」
「 NAS4Free v9.3.0.2 系への移行に苦労した話」

　先般、リリースされた FreeBSD 9.3 がベースとなる 待望の NAS4Free v9.3.0.2 ですが、 喜び勇んでアップデートしてから、ひじょーに調子が悪い。

　何が悪いって、 Intel D34010WYK にインストールした VMware vSphere Hypervisor(ESXi) 上に作成した 仮想マシンがすぐ落ちるようになりました (T-T) 　うちの ESXi は、 GIGABYTE GB-BXCE-2955 にインストールした NAS4Free へ NFS マウントした領域に、 仮想マシンのイメージを記録しています。
　特に ESXi 上の Windows 7 をインストールした仮想マシンから、 NAS4Free へ NFS マウントしている領域を CIFS (Samba) で共有するファイルサーバーとなっている CentOS 7 をインストールした仮想マシンへ、 サイズの大きなファイル（ギガバイトクラス）を転送すると NAS4Free v9.3.0.2 にしてから頻繁に落ちるようになりました。

　NAS4Free がダウンするとファイル転送が失敗するのはもちろんですが、 仮想マシンイメージの記憶域にもなっているので、当然、仮想マシンそのものがストップします。
　現状、我が家のファイルサーバーを含むバックエンド環境はすべて、 ESXi による仮想マシンなので、NAS4Free のダウン一撃で全滅です。

　普段は特にファイル I/O で高負荷のかかる処理は滅多にしないのですが、 うっかり負荷をかけてしまってバックエンド全滅という事態を招く可能性を抱えているというのは、 精神衛生上よくありません。

　どうにかならないものか…
　いっそ 9.2 系へ戻そうかという考えも頭をよぎっていたところに、 12 月 20 日に 9.3 系の新リビジョン 1213 がリリースされたので、 藁をもつかむ思いでアップグレードしてみました。
# v9.3.0.2(rev1190) からは GUI 管理画面からアップグレードできます。

　しかし、結果………変わらん orz
　ここですでに半泣き (T-T)
# このあたりで Yosemite に逃避行 したり してました (_ _;;;;;

　本気で NAS4Free を 9.2 系に戻そうか、 それとも ESXi やめて、以前のように Windows 7 や CentOS を PC にいれて、アンチ仮想化、現物主義に戻ろうか… と言うところまで追い込まれました。

　途方に暮れる。。。頭が真っ白と言うところまで行ってひらめきました (T-T)b
（つづく）

Ellinikonblue.com Weblog 「 NAS4Free 9.3.0.2.1190 へアップグレード」

　やっとでました NAS4Free の 9.3.0.2(rev1190) 。

　今回の 9.3 系では、 我が家で NAS4Free をインストールして使っている GIGABYTE GB-BXCE-2955 に搭載されている ネットワークインターフェイス Realtek 8111G や USB 3.0 インターフェイスをデフォルトで認識してくれます。 　ただし、今回のリリースノートの冒頭にはこんな文言が…

Upgrading NAS4Free "Embedded" or "Full" from 9.2 or older to 9.3.0.2 from webgui or from LiveCD/USB is problematic, due a new size of boot partition.

この時点ですでにいやな予感はしていました (_ _;>

　おまけに Embedded 版の拡張子は .xz に変わっていて、当然、このままだと GUI の管理画面から アップグレードできませんでした。
　だったら .gz に変換して読み込ましてやれば…と思ってもやってみるべきではなかった orz
　ものの見事に再起動不能に。よい子はまねしないように… (T-T)b

　と言うわけで、管理画面からのアップデートはできませんでしたし、 Embedded 版のイメージを解凍して直接、 USB メモリーに転送する方法もとらず、 時間もなかったので一番確実な方法で CD から起動して、素直にインストールし直すことにしました。

　事前に設定だけはバックアップしていたもので、 ISO イメージを CD に焼いて、ここから起動して USB メモリーにインストールし直し、 バックアップしておいた設定を読み込ませて再起動。
　USB でつないだストレージがある場合、 9.2 系ではシャットダウンプロセスが止まるバグがありましたが、 9.3 ではこれも解消。すばらしい (^^)b
# 皆さんも無茶をするときは必ず設定のバックアップを。。。 少なくとも設定だけはバックアップから問題なくリストアできました。

　超すったもんだしましたが、何とかアップグレード完成です！
　ネットワークインターフェイスはなんにもせずとも認識し、 USB で外づけているストレージは管理画面で見るかぎりとちゃんと 3.0 で繋がってる！！
　紆余曲折があってやっとここまでたどり着きました。って感じで、ちょっと感動を味わっています (T-T)

　期待通りのパフォーマンスアップは望めたか？ それはもうちょっと使い込んでから報告します ^^

「 FreeNAS 9.3 が登場」 （ マイナビニュース より）

　9.2 に大きく機能を追加して FreeNAS の 9.3 が登場しましたが、 NAS4Free も 9.3 系がそろそろ登場するようです。
# あまり大きくは機能追加されないようですが…
## rev1179 アップ直後にバグが見つかって一旦削除されたようですが…

　次のバージョンはどちらも FreeBSD 10 系がベースになるようですが、 そんな先のことは（今は）結構、どうでもよく (^^;A 、 FreeBSD 9.3 がリリースされて以来、 これで手を加えずとも Realtek 8111G を認識してくれる上に、 Haswell プラットフォームでも USB 3.0 をちゃんと認識してくれるはずの、 首を長くして待っていたバージョンです。
　SSD で我が家の NAS4Free をインストールした GIGABYTE GB-BXCE-2955 を パワーアップしたところですが、 USB 3.0 が有効になればさらなるパフォーマンスアップが期待できます。

　焦らずじっくり攻めたいと思いますが、 冬休みに入るまでにはちゃんとリリースしてね (^^;A ＞ NAS4Free

FreeNAS Project 「 FreeNAS 9.3 Released 」 Ellinikonblue.com Weblog
「 NAS4Free を SSD でパワーアップしようという野望」
「 NAS4Free でスワップを有効にする」
「 NAS4Free で ZFS の L2ARC/ZIL を SSD 上に設定する」
「 NAS4Free で L2ARC/ZIL を SSD に設定した効果」

　先般、 SSD を購入して、 L2ARC/ZIL をこの SSD 上に設定したわけですが、 この設定後に困ったことが起きました。

　うちでは NAS4Free をインストールした GIGABYTE GB-BXCE-2955 に、 二台のハードディスクケースを USB で外付けしていて、起動時は HDD のデバイス名が認識順に決まるので、 一方はつなぎっぱなしで起動して、もう一方は OS 起動後につなぎます。
　このため、完全に起動した後に、管理画面からすべての ZFS プールをインポートし直していたのですが、 SSD 上に L2ARC/ZIL を設定したとき、最初につないだハードディスクケースの ZFS プールだけを認識してしまい、 ZFS の管理画面に行っても、あとからつないだケースの ZFS プールを GUI からインポートするためのボタンがでない状態になってしまいました。 　どうしよう、どうしようとひとしきりあたふたしたあとで、 「コマンドラインからインポートはできないのか？」とひらめきました。

　ありました。 CUI からインストールする方法 (^^)b

　まずは SSH で NAS4Free にログインします。 それから以下のコマンドでインポートできる ZFS プールを検索します。
# 注： スーパーユーザー権限で実行して下さい。

# zpool import

　インポートできる ZFS プールがある場合、それが表示されますので、 以下のコマンドを実行すればインポートできます。

# zpool import tank

　tank はインポートできる ZFS プールとして表示されたプール名です。

　以上の処理が終わった上で、 NAS4Free の管理画面 (GUI) から ZFS の設定を同期しておけば大丈夫かと思います。

　えーっと、おそらく FreeBSD を普通に使っている人なら ごくごく当たり前の対処法かと思います。
　お粗末様でした m(_ _)m

Ellinikonblue.com Weblog 「 NAS4Free で ZFS の L2ARC/ZIL を SSD 上に設定する」

　NFS でマウントしたストレージ領域を Samba (CIFS) 経由で 公開することは鬼門らしい。。。

　こういう話はずいぶん前から知っていました。
　ローカルのストレージ領域を CIFS で共有する場合と比較して、いろいろな問題が生じます。

　現在、我が家では NAS4Free で ストレージを集約しているわけですが、過去の経緯でネットワークパスを変更したくない理由があって、 Linux(CentOS) で立てたファイルサーバー （ Samba サーバー）に NFS でストレージ領域をマウントして共有しています。
　現在の環境に至るまで、自宅の環境を整備するたび調べて、試行錯誤を繰り返して対処してきたのですが、 自宅という超少人数（ほぼ自分一人）で使う分には、 不満のないレベルで安定したので、備忘録の意味もかねてまとめておきます。

　まずは NFS クライアント側のマウント設定。
　これを行わないとまずスループットが上がりません。 また Windows クライアントからのファイル書き込み時にエラーが発生する場合があります。
　Samba で共有する領域なので、 /etc/fstab に記述すると言う前提で以下のようになります。

192.168.0.1:/mnt/mnt_zfs/Lib /mnt/mnt_nfs nfs rw,noatime,tcp,intr,nolock,rsize=4096,wsize=4096 0 0

　NFS サーバー (192.168.0.1) の /mnt/mnt_zfs/Lib を自身の /mnt/mnt_nfs へマウントする際、 読み書き可 (rw) 、 inode のアクセス時間を更新しない (noatime) 、 TCP 使用 (tcp) 、障害時などに NFS 要求の割り込みを許可 (intr) 、 ファイルロック機能無効 (nolock) 、読み込み (rsize) ・書き込み (wsize) 時のバッファサイズを 4096 に指定します。

　バッファサイズですがいろいろ試しましたが、 8192, 4096, 2048 で最もスループットがでたのが今の環境 （ Samba サーバー： CentOS 7 /Samba 4.1.1 、 NFS サーバー： NAS4Free 9.2.0.1.943 ）では 4096 でした。

　nolock のオプションは本来多人数で単一ファイルへ同時アクセスされることが想定される場合、 使ってはいけないオプション（らしい）ですが、これを設定しないと、 Windows クライアントからのファイル書き込み時にエラーが発生してしまいます。

　一方で、 Samba 側の設定 /etc/samba/smb.conf で global セクションに以下のように kernel oplocks を無効にしさえすればよいとも 書かれていたところもあるのですが、うちの環境ではこの設定だけでは解消しませんでした。

[global]
: （略）
       kernel oplocks = no
: （略）

　我が家では NFS マウントの際の nolock オプションと、 上記の /etc/samba/smb.conf の kernel oplocks の設定は両方して施しています。

　以上、これで我が家のファイルサーバーはそこそこパフォーマンスがでています。
「これが決定版！おすすめ！！」って設定ではないですが、 NFS マウントの領域を Samba (CIFS) で公開する場合はお試し下さい。
　それでもっといい設定があれば、教えて下さい m(_ _;)m

　Crucial CT120M500SSD3 を NAS4Free をインストールした GIGABYTE GB-BXCE-2955 に追加して、 スワップの有効化と、 ZFS の L2ARC/ZIL を SSD 上に設定しました。

　スワップを有効にしてもパフォーマンスは変わりませんが、 果たして L2ARC/ZIL を SSD 上に設定してどの程度効果があるのか？

　半信半疑で、今回、 L2ARC に 20GB の容量をとってみましたが、 普段、ディスクイメージがこのサイズに収まる Linux 系の仮想マシンでは、 明らかに再起動等が早くなりました。これはすぐに実感できました。

　一方で、ディスクイメージがこの L2ARC のサイズに収まらず、 またファイル I/O に関する処理が頻繁な Windows 7 がインストールされた仮想マシンで、 客観的にどの程度パフォーマンスがアップしたかを確かめてみました。

　ちなみにこの L2ARC/ZIL の設定を行う前に、 CrystalDiskMark で、 ローカルのドライブへのアクセス速度を計測してみたところ、以下のような結果でした。 　さんざんです orz

　参考として普段、私が使っている自作機（デスクトップ）ではこんな感じです。 　Intel 製 SSD を搭載して Intel Smart Response Technology を有効にしてありますので、 かなり早い部類に入ると思いますし、これと仮想マシンのディスクイメージへのアクセス速度との 比較は酷だとは思いますが、それにしてもパワーアップ前はひどすぎました。

　それがここまでアップしました。 　いやまぁ通常のデスクトップ環境には遠く及びませんが、 それでも 3 倍から条件によっては 5 倍近くの改善がはかれました。
　ZIL だけ無効にしての計測はしていませんので、これだけでの威力は定かではありませんが、 仮想マシンのディスクイメージが小さい場合の威力は絶大なので、 おそらくこれは L2ARC の威力は偉大なように思います。

　NAS4Free が今後のバージョンアップで USB 3.0 にしっかり対応してくれれば、これ以上のパフォーマンスアップが実現できそうですが、 現時点で SSD 代 9,000 円弱の投資効果としてはかなり満足しています (^^)v

Ellinikonblue.com Weblog
「 NAS4Free で ZFS の L2ARC/ZIL を SSD 上に設定する」
「 NAS4Free でスワップを有効にする」

　NAS4Free をインストールした GIGABYTE GB-BXCE-2955 に、 ハードディスクケースに複数のハードディスクを装填して ZFS プールを作成したものを USB 3.0 で接続してストレージサーバーを構成しています。

　ところが現在使用している NAS4Free 9.2 系では、 接続しているハードディスクを USB 3.0 で認識してくれず、ここがネックでパフォーマンスが上がりません。
　特に VMware vSphere Hypervisor (ESXi) の 記憶領域をここに作成して NFS でマウントしているため、 ファイル I/O が頻繁になるとパフォーマンス低下が激しいのです。

　そこでこの問題に対して、 ZFS の Read 用の二次キャッシュ (L2ARC) と Write 用ログ領域 (ZIL/ZFS Intent Log) を SSD 上に置くことで、 パフォーマンスアップを狙ってみることにしました。 　まずは SSD 上に L2ARC と ZIL 用の領域を確保します。
　この作業は NAS4Free サーバーに SSH で接続してコマンドラインから root ユーザーに切り替えて行います。

　以下のコマンドで GPT で初期化された SSD （ /dev/ada0 と認識されているものとします）上に、 ZIL 用に 8GB と L2ARC 用に 20GB の領域を確保します。

# gpart add -a 4k -s 8G -t freebsd-zfs -l zil0 ada0
# gpart add -a 4k -s 20G -t freebsd-zfs -l l2arc0 ada0

上記では -l オプションでラベル（それらしき文字列でかまないと思います）を指定していますが、 こうしておくと、実際に L2ARC と ZIL を設定するとき、以下のコマンドで済ませられます。

# zpool add zpool log gpt/zil0 cache gpt/l2arc0

　上記の例では ZFS プール zpool に対して、ラベルを zil0 とした領域を ZIL として、 l2arc0 とした領域を L2ARC としています。

　これで実際 zpool コマンドで状態を確認してみると。。。

# zpool status
  pool: zpool
 state: ONLINE
  scan: none requested
config:

        NAME          STATE     READ WRITE CKSUM
        zpool         ONLINE       0     0     0
          mirror-0    ONLINE       0     0     0
            da1       ONLINE       0     0     0
            da2       ONLINE       0     0     0
        logs
          gpt/zil0    ONLINE       0     0     0
        cache
          gpt/l2arc0  ONLINE       0     0     0

errors: No known data errors

ってな感じで確認できます。

　これで大丈夫のはずですが、当方では設定が終了したあと一度、サーバーを再起動しておきました。

　で、実際、どの程度パフォーマンスが上がったかは、また次回 (^^)/