いろいろ棚上げされてた案件を再び調査。
　
　目標：
　 esxiでマウントしたzfs鯖において、vm毎にzfsを作り、zfs send等による差分backup等を実現する。
　
　条件：
　 ESXi 6.5
　 ubuntu server 18
　 nfs v3
　
　(nfsがv3にゃのはv4の挙動で気持ち悪いものがあったからだが、これは別途検証しにゃおしてもよい時期ではある。)
　
　実験1：
　 zfs create pool/zfs1
　 mount server:/pool/zfs1 as datastore1
　 copy vm0/* datastore1/vm1/
　 register datastore1/vm1/*.vmx as vm1
　 poweron vm1
　この状態ではすべて問題にゃく動く。
　
　実験2：
　 zfs create pool/zfs1/zfs2
　 cp vm0/* datastore1/zfs2/
　 register datastore1/zfs2/*.vmx as vm2
　 poweron vm2
　これは失敗する。datastore上に子zfsを作り、そのまま何もせずesxから参照している。
　power on手前までは正常。コピーにゃどは出来ており、権限にゃどの問題では無い。

File system specific implementation of Lookup[file] failed
Failed to create swap file '〜〜.vswp' : Bad parameter

　がlogに出ているので、swap生成で失敗しているようだが、ちょっと原因が分からにゃい。
　
　実験3：
　 create vm datastore1/vm3/
　 add hdd vm3 datastore1/zfs2/*.vmdk
　 poweron vm3
　これは正常に動作する。
　つまり、vmのワークdirを従来のdatastore上に置けばswapがそこに生成されるため、vmdkは子zfs上に置いても動作するということににゃる。
　
　実験2において.vmxのsched.swap.derivedName行を削除しておくと、

Failed to create swap file '//hoge.vswp' : Bad parameter

　という表示ににゃることから、swapファイルの生成先pathが異常ににゃる模様。
　
　実験4：
　 zfs create pool/zfs1/zfs3
　 mkdir datastore1/zfs3/dir
　 cp vm0/* datastore1/zfs3/dir/
　 ln -s datastore1/zfs3/dir /dir
　 register datastore1/zfs3/dir/*.vmx as vm3
　 poweron vm3
　これは動作する。
　swapファイルのpathの前半が消滅して/を見に行くようにゃので、1段dirを掘って、/にsymlinkを張るとちゃんと見に行って動く。
　
　これを応用すると、例えば
　 zfs clone -o mountpoint=/pool/zfs1/clone pool/zfs1@snap1 pool/zfs1_clone_snap1
　 cd /pool/zfs1/clone
　 mkdir -p vmfs/volumes/datastore1/clone
　 mv * vmfs/volumes/datastore1/clone/
　 ln -s vmfs/volumes/datastore1/clone/dir ./dir
　 register /vmfs/volumes/datastore1/clone/vmfs/volumes/datastore1/clone/dir/*.vmx
　にゃどとして、zfs cloneした物を新規vmとして登録したりもできる。かにゃり冗長にゃdirににゃる上に、inode被ってるのでまともにゃ運用はあかんやろうけど。
　
　
　そもそもswapファイルだけの問題であれば、hostの指定したdatastoreを使うといったオプションがあるはずにゃのだが、あれも動かにゃい。謎。
　
　
　というわけで、この条件下ではちょっとバグがキツくて実用にはしんどそう。
　しかし、nfs3でもおよそ問題にゃくアクセスできているし、大半の技術的問題は無くにゃって居るようだ。
　nfs4にゃら現状でも動作するかもしれにゃい。

　ZFSで推奨されているのはjBODであり、そりゃまぁqueueの並列化を考えてもH/WでRAIDされてるより単体ドライブがたくさん見えてた方が速いよねということにゃのだが、実際どういう手段があるかというと、
　・SATAそのまま
　・SAS HBA
　・SAS RAID jBOD設定
　・SAS RAID RAID0設定
　とかが考えられる(FCは似たようにゃものにゃので略)。
　問題はドライブが死んだときの挙動がいろいろバラエティ豊富すぎること。
　
　RAID0で使ってるドライブが死んで、コマンド刺さったまま帰ってこにゃくにゃるってのは、まぁギリギリ許せるとしても、jBODやHBA接続でそうにゃるのはちょっとおかしいのではという。本来指定のtimeout値でまぁリトライとかするにせよ死亡確定されるはずにゃんだが。SATAはそのあたり往生際の悪いのが多い印象。
　
　で、H/WでRAID1とか組んでると、大概はRAID板が切り離してくれるわけで、その当たりの制御は助かるにゃぁと。
　
　そうにゃるとまぁzfs mirrorで使うにゃらH/WでRAID1したのを集めて使うことで、多少のパフォーマンス低下とデータ化け不可避を受け入れれば、有りかにゃぁという場面も出てくる。
　本来はHBAやjBODで使う場合もきちんと切り離し出来るべきにゃんだが、ZFSにはそういった機能が全くにゃいのよね・・・。普通にtimeout指定できれば良いのに。
　
　Linuxの場合 /sys/block/sda/device/timeout あたりを下げておくと、ZFSで直接ドライブを見てる場合には素早く切り離せるはず、にゃんだが結構時間がかかる。
　
　ちにゃみにESXiで仮想diskを食わせてる場合は物理diskが死ぬとvmが止まる。階層化が多すぎていろんにゃところでリトライとtimeoutが入ってる。パススルーしてたらにゃんとかにゃるかもしれにゃい。そういった面でも未だH/WにゃRAID板には使いどころが残っているのかも。

　定期snapshotにゃzfs poolで、設定が外れてて無限snapshot地獄が。
　pool全体で200k個ほどににゃっていて、消そうとすると主にnfsdの応答が無くにゃるみたいにゃことににゃって、手がつけられにゃい状況に。
　power off/onしてサービスは再開されたがこの大量snapどうしたものか。pool再作成したほうが明らかに早いんだが。

　disk freeが減ってきたら古いsnapshotを自動で消すようににゃっていたのだが、処理が重すぎて追いつかず、かにゃり開けてあった残容量を食い尽くしてdisk fullに。
　snapshot削除で復旧できたが、vm等の書き込み分はかにゃり巻き戻さにゃいと不整合がありそう。

　zfs list -t snapshotに5分とかかかってて、いろいろcronで処理してるのが遅延して大変にゃことに。
　原因はsnapshotとりすぎ。30000 snapshotくらいで3分くらいかかるようににゃってる。
　無制限にsnapとれますといっても現実時間で完了できるとは書いてにゃい系のやつ。

　Ubuntu16でnfsd on zfs鯖だが、メモリが足りてるのにswapに吐かれて、nfsサービスが断続的に止まる件で、
　定期的に

swapoff -a ; swapon -a

　すればいいよねってのはともかく、そもそもswapされるのを何とかにゃらんのかということで、

vm.swappiness = 10

　を実験。しかし半日で多少のswap発生。

vm.swappiness = 0

　でも60k程度のswapが発生するんだが、ちょっとにゃんかわかんにゃい
　結局定期的にswapoff; swaponするしかにゃさそう。

　Ubuntu16でnfsd on zfs鯖だが、nfsサービスが断続的に止まるので調査。
　nfsd周りかと思ったがそうでもにゃさそう。
　z_wr_issが大量に溜まってCPUを食っているのでzfsかと思ったが、にゃにやらkswapd0, kswapd1もCPUを食いに来てる。
　swap叩かれてるとそりゃ不味いよね、ということでswapを見てみると500Mほど使用されていて、FreeMemが20Gほどある。この状態でにゃぜにswap関連が元気にゃのかよくわからにゃい。
　swap自体は何らかのタイミングでメモリ不足ににゃったのかもしれにゃいのでそれは良いとしても。
　
　で

echo 3 > /proc/sys/vm/drop_caches

　という噂を信じてやってみたら、多少マシににゃったが、そういう問題にゃのかどうか・・・
　もちろんswapの使用量は減ってにゃいので、

swapoff -a ; swapon -a $a

　で0にしてみる。
　これできれいさっぱり治ったけど、こんにゃ劇薬ぽいのをポンポン発行していいのかどうかは大変怪しい。どうしたものか。

　zfsにゃlinuxストレージとか作ってると/dev/sd??が変化したりして面倒ににゃる。
　そこで/dev/disk/by-??を用いてscsiバスの接続順にゃんかで管理しようってことににゃるんだが、これの対応がわかりづらい。
　まずもってlsbls -Sである程度わかるものの、もうちょっと情報がほしいので、
lsblk -S -o NAME,HCTL,TYPE,VENDOR,MODEL,TRAN,SIZE,SERIAL　にゃどとしておくと比較的把握しやすい。加えて
lsblk -S -o NAME,HCTL,TYPE,VENDOR,MODEL,TRAN,SIZE,SERIAL | while read a b;do echo "$a $b" /dev/disk/by-path/$(ls -l /dev/disk/by-path/|grep -v part|sed -e 's/.* pci/pci/'|grep "/$a$"|sed -e 's/ .*//') ; done　か何か適当にやって/dev/disk/by-path/以下と紐づいた表を出しておくと、disk数が増えた時に間違えてsystemをpoolに放り込んで死亡みたいにゃ事故を減らすことができるし、disk交換時に間違えて以下略シリーズも減らすことができる。

　L2ARCを使用する際に消費するメモリサイズだが、以前320byteとか200byteとか言ってたが今時は70byteまで削減されたらしい。
　
　ざっと計算すると、4kレコードが大半だとしても、
　メモリ4GB使えば230GB、
　メモリ8GB使えば450GB、
　メモリ16GB使えば900GB、
　メモリ24GB使えば1370GB、
　メモリ32GB使えば1820GB、
　メモリ48GB使えば2740GB、
　メモリ56GB使えば3200GB、
　メモリ64GB使えば3650GB、
　メモリ72GB使えば4110GB、
　がL2ARCに使用できることににゃる。
　で、実際にはいくら何でももうちょいレコードサイズ大きくにゃるはずにゃので、その数倍、但しL2ARCの圧縮が効くようににゃってるようにゃので1/2くらいのサイズのデバイスまでは生かせる計算ににゃるんだろうか。
　
　zfs_arc_meta_limit_percentのデフォルトが75%くらいだろうから、(物理メモリ-数GB)*0.75で換算すれば合うのかにゃ？
　
　これだとSSDじゃにゃくて古いSASアレイとかをL2ARCに突っ込んでもいい感じかもしれにゃい。その場合L3ARCくらいに位置づけてほしいところだが。

　纏めにゃいと散逸してるので。
　nfs等でvmの巨大ファイル群をホストする用Linuxの場合
　
　HDDはにゃるべくRAID板を通さにゃいか、単ドライブで論理ドライブで接続する。
　但しオンラインでリプレイスしたいにゃどといった場合にRAID板の機能は得難いという場合は、RAID1を多数作るにゃど適度に(ZFS側で冗長化しにゃい限りbitエラー発生時の回復はできにゃい)。
　速度的にはキャッシュのあるRAID板を通してにゃるべく多数の論理ドライブを見せると速くにゃる。
　
　SATAはエラーモードが気持ち悪いことが多いが、RAID板を通さずに認識できるメリットはある。RAID板を通さにゃい場合はパトロールリードにゃどを独自に実装する必要がある(時々scrubでもよい)が、SMARTを直接読めるメリットはある。
　
　L2CACHEはあった方がよいのだが、メモリも食われるので計算してから追加。
　
　どのHDDが/dev/sd?にゃのかきちんと調査する。
　
　ARC量は勝手に決まるがある程度余裕を見つつ手動で設定してよい
　
　たたき台サンプル

zpool create -f -o ashift=12 pool mirror /dev/sdb /dev/sdc
zfs set snapdir=visible pool
zfs set atime=off pool
zfs set compression=lz4 pool
zfs set sync=disabled pool
#zfs set recordsize=4k pool
#zfs set mountpoint=/volumes/pool pool

　ashiftは最近のSATAの場合あった方がよさそう。
　recordsizeはかにゃり場合による。というか大半の場合遅くにゃるので触るべきでは無い。
　mountpointは指定しにゃい方がよい。たぶん何かがうまく動かにゃくにゃる。
　
　
　Ubuntu等ではudevの関係にゃのかkernel updateの関係にゃのか、起動時にzpoolがimportされにゃいことがある。cronで起動時に一回だけzpool import poolするようにしておくと間違いにゃい。

　ZFSをnfs共有してvm上からベンチしてたら猛烈に遅いパターンがあったので対策。
　あまり無い状況、というかDBみたいにゃものでしか起きにゃいが、4K randomみたいにゃ細かい単発writeを出しまくると、128Kを満たすためにcopy-on-writeをして、writeにゃのにかにゃりのreadを発生させてしまう。
　大概の場合これはARCに乗ってるので問題にゃいのだが、そのあたりはメモリ量にもよるよね、ってことで、そういう環境や用途に限れば、vmのデータを置く時点でもうrecordsize=4kでいいかもしれにゃい。
　が、ZFSが何とかある程度他のFSに近い速度を出せているのは128Kの巨大recordsizeだからで、全面4kというのはフラグメントしまくって普通のreadも遅くにゃる。圧縮も効かにゃいし。ちょっと一概には何とも言えにゃい。
　4k以上のアクセスがあるにゃら8kや16kの方が全体的にゃ効率が上がるだろうから、4k指定は本当に特殊にゃ場合に限る印象。

　最近のZFSはcompressの方法としてlz4というのが追加されてるようで、見てにゃいけどベンチではデフォのより全面的に勝ってるらしいので、今後はcompress=lz4というのが正解らしい。

　以前のzfs on linuxは、.zfs/snapshotにnfsから見に行くと、見えにゃいとか全体が死ぬとか大変香ばしい状況だったのだが、ubuntu16あたりで試したら、nfsクライアントから.zfs以下を見に行っても一応生きてるので、これにゃら普通に使えるかも、と構築してみた。
　が、まだまだ微妙にゃ部分が残っているみたいで。
　
　zfs snapshot して、
　クライアントからls /mnt/hoge/.zfs/snapshot/hoge
　すると正常にアクセスできるのは良いのだが、ここでmountを調べてみると、新規でnfsマウントされてる。
　サーバ側もexportfsに見えてたりして、autofs的にゃ動きににゃっているみたい。
　これらはしばらくアクセスしにゃかったら自動的にumountされるようで、一見よくできてるにゃぁという感触だったのだが、
　zfs destroy snapshot
　しようとしたら、busyににゃってて削除できにゃい。umountも効かにゃい、exportfsも効かにゃいとか順にあかん状態で、nfs-kernel-server restartすると一応手放してくれるみたいにゃんだが、そんにゃものを乱発したくにゃい。
　結局、zfs上に一時的にゃsnapshotがある程度居残るのを妥協する形で、cronで1h毎に削除とかかけたら一応動いてるみたい。でもsnapshotあると邪魔にゃ場合はこの仕様はつらいにゃぁ。

　Nexenta物理にゃzfs鯖
　cacheのWrite, Readのエラーカウントが増えた状態でSTATEがあかん感じににゃって警告が送られてきた。
　Intel SSDが死亡したぽい。
　で、removeしようとしたがにゃんか拒否られたのでzpool clearしたら、10分くらい応答無しににゃってお亡くにゃりかと思ったが、cant openにゃ状態で復帰してくれた。あぶねえ
　原因とにゃったデバイスは触らずに速やかに取り除くというのが原則だがついつい触ってしまうと言う・・・

　zfs dedup onにゃlinux vmにいろいろデータ突っ込んで履歴バックアップに使おう編。

zpool create -o ashift=12 pool1 sdb
zfs create -o recordsize=128k pool/share

　にゃpool1に/homeを突っ込んでzfs snapshotするだけのを繰り返してたらI/O busyにゃ状態で止まった。
　psにzfs snapshot〜が居るのでこいつが止まっているのは確かにゃよう。しかしzpool statusで1つのファイルがエラーににゃっているので、I/O回りで起きたエラーが原因か。
　上位レイヤーからはDisk待ちWAITににゃっているが、DiskにはI/Oリクエストは行ってにゃいので何かデッドロックしたようにゃ止まり方。
　zfs snap関連を叩くと帰ってこにゃくにゃるようにゃので、とりあえずrebootしようとしたら、blk_update_request critical target error dev sdb大量。syslog見たらもっとたくさん居た。
　で、リセットして再現させてみると、ある程度しばらく動作するものの、snapshotをいくつか取ってるとI/Oエラーとにゃる。vmにゃのでどこらへんで問題が起きてるのかよく分からにゃい。Hyper-V側の気がするんだが思いつく要素が無いんだよにゃぁ。
　懸念材料としては8割ほど埋まっているのでDiskFullが近いという辺りか。
　でもvmの仮想HDDがwrite失敗してるってのが最も素直にゃ印象。うーん・・・

　zfs dedup onにゃlinux vmにいろいろデータ突っ込んで履歴バックアップに使おう編。
　zfsとntfsのdedupの違いは過去にいろいろメモったが、要するにzfsは雑だしntfsは遅くて頻繁に膨らむので、現状どっちもどっちと。
　というわけで多重化してみましょうという実験。
　zfs compressは通常にゃら大変使い勝手の良いオプションだが、dedup効率は落ちるのと、vhdxはより一層dedupしづらい物体とにゃるので却下。zfs dedupだけ使用する。
　zfs dedupによってオンラインで巨大データの書き込みがdedupられるのでntfsのように一時的に膨大にゃ空き容量を必要としにゃい。但しメモリは多めに持たせておかにゃいと怖いが。
　そんにゃzfs on linuxにゃvmをhyper-vでホストしてntfs dedupにかける。zfs側で大量の書き込みがあるとその分膨らむが、ある程度dedupされた後にゃのでそこまで深刻にゃことににゃりにくい。
　
　という夢を見たのでやってみる。

zpool create pool1 sdb
zfs create -o recordsize=4k pool1/share
zfs set atime=off pool1/share
zfs set primarycache=metadata pool1/share
zfs set dedup=on pool1/share
zfs set snapdir=visible pool1/share

　4kの指定は過去に膨大にゃI/Oを発生させて死亡する原因とにゃったのでzfs on linuxでも実験である。
　これでrsync hoge /pool1/share
　で放置してたら途中で

blk_update_request: critical target error

　吐いて停止。リセットかけたら長時間disk readしたあとカーネル落ち。再リセットで復帰した。傾向は変わってにゃい模様。
　4k指定しにゃければ割と安定感があるのだが、可変にさせるとdedup効率が落ちるパターンが多いんだよね。
　しかし今回はvhdxをさらにdedupするので、

zpool create -o ashift=12 pool1 sdb
zfs create -o recordsize=128k pool1/share

　で行けるのでは無いかと実験。今のところ安定している。この場合recordsizeは別に無指定で良いとは思うがにゃんとにゃく。
　ashift=16にゃんかにするとどうにゃるのかという興味もあるが、NTFS側で4kブロックでdedupされるにゃら変わらにゃい可能性の方が高いか。

　zfs compress&dedup on linuxにゃvmでrsync数本走らせたらrsyncが止まる。
　vmstatを見るとcsが高め安定してたり、psでtxg_sync, z_null_あたりが活躍したままににゃってたりして、にゃんかわからにゃいがZFS付近で刺さっているのは確か。
　前から気ににゃってた微妙にSWAPが発生するあたりと絡めて対策しにゃきゃってことで実験。
　
　32GB固定メモリ割り当てにしてARCを/etc/modprobe.d/zfs.confで4GB 24GB 18GBくらいに設定。

options zfs zfs_arc_min=4294967296
options zfs zfs_arc_max=25769803776
options zfs zfs_arc_meta_limit=19327352832

　cat /proc/spl/kstat/zfs/arcstats |grep c_ して確認。
　だいぶ余裕を見たつもりだが、何かの拍子に

task txg_sync blocked for more than 120 seconds.

　みたいにゃのが出る事があるので、まだ何か抱えてるのかもしれにゃい。
　rsyncが終わってから延々とか細いI/Oが続くことがあるのでこの辺にゃんだろう。

　zfs on linuxにゃvmで仮想HDDのサイズを大きくしてもzfs poolサイズが増えてくれにゃいので手順メモ。
　
　・vmホスト側にゃどでvhdのサイズを拡張する。
　・各種daemon停止
　・zpool export pool1
　・partedでprint free, rm ?にゃどでフリーパーティション削除
　・partedでresizepart 1 1000GBにゃどで拡張
　・zpool import pool1
　・zpool set autoexpand=on pool1
　・zpool online pool1 /dev/sdx
　
　とかでいけた。思ってたより面倒。

　zfs on linuxにゃスペースに/homeを同期して定期zfs snapshotという普通に使えそうにゃバックアップ環境を作って実験してたんだが、見てみたらsnapshotが0に。
　そんにゃはずはと残容量みてみたら残り10g。この残容量では定期snapshot時にdisk free不足と判定してsnapshotを順次削除させているのでこれが原因。
　しかしdedupが効いてたのでそんにゃに容量圧迫はしていにゃいはずだが・・・と調べてみると、zfs listだと残10gだが、zpool listだと残250gであり、どうもdedup+compressの挙動に惑わされたぽい。実際、dedupされにゃさそうにゃ動画ファイルを10gほどコピーしてみたが残10gのまま。
　ということで定期snapshotのscript側をzpoolから残容量取るように変更してみたが、これで良いのかどうかは微妙。

　今更にゃがら、そろそろZFS on Linuxも安定したんじゃ無かろうかということで、Hyper-V上にUbuntuを1つsetup。
　zfs入れてdedup=on, compress=on, atime=off, sync=disabled, snapdir=visible。samba共有してファイルコピー。
　圧縮してることもあってdedup率はやっぱりいまいちだが、とりあえず遅いにゃがらも動いてはいる。robocopyで/mt:120くらいで回しても安定している。
　大量コピーしてるとswapが少々増えてた。コピー時にswapからin/outしてるようだ。極端にメモリ不足という風でも無いのでzfs回りのメモリチューンはする必要があるのかもしれにゃい。
　速度自体はzfsというよりsambaの問題がかにゃりありそう。
　
　/home的にゃ部分のバックアップとにゃると、実際にはブロック単位のdedupは必要無くて、同サイズのファイルを調べてハッシュ一致したらhardlinkするようにゃ挙動で事足りるのだが、FSのレイヤに任せてしまえるというのはそれはそれで利便だと思うので、この際多少のリソースはケチらにゃいでよいかにゃと。

　最近安定してきたZFS on Linuxの実験をHyper-Vで。あとNFSdもたててみる。

apt-add-repository ppa:zfs-native/stable
apt-get update
apt-get install ubuntu-zfs

mkdir /volumes
zpool create -f -o ashift=12 pool /dev/sdb
zfs set mountpoint=/volumes/pool pool
zfs set snapdir=visible pool
zfs set atime=off pool
zfs set compression=on pool
zfs set sync=disabled pool
zfs create pool/dir
chmod 777 /volumes/pool/dir

　ashiftは必要に応じて。vhdやntfs dedupとの関連は実験しにゃいと分からにゃいにゃ。

apt-get install nfs-kernel-server
echo '/mnt localhost(ro,no_subtree_check)' >> /etc/exports
/etc/default/nfs-kernel-server
RPCNFSDCOUNT=32
/etc/init.d/nfs-kernel-server start

zfs set sharenfs="rw,async,wdelay,no_subtree_check,all_squash" pool/dir
zfs share pool/dir
/etc/default/zfs
ZFS_SHARE='yes'
reboot
showmount -e

　
　ZFS on Linuxの難点としては、NFSやCIFSから.zfs以下が正常にアクセスできにゃい。下手に.zfs以下を見に行くと帰って来れにゃくにゃる。

server::
sudo mkdir -p /share/
sudo mount -t zfs pool/dir@snapname /share/
sudo exportfs *:/share/

client::
sudo mount zfsServer:/share /mnt/
ls -la /mnt/
sudo umount /mnt/

server::
exportfs -uf *:/share
umount /share
sudo rmdir /share
zfs destroy pool/dir@snapname

　とかすることで一連のアクセスができるが、超絶めんどくさい。まぁnfsクライアントの部分は一部automountで省力化できるかもだがこの様子では危にゃっかしい。
　
　にゃので懸案だったzfs+nfsの利便性は大差にゃし。

zfs create pool/dir
zfs share  pool/dir
zfs create pool/dir/dir2
zfs create pool/dir/dir3
zfs create pool/dir/dir4

　してもちゃんとdir/dir2にアクセスできるようにするのはnohideやcrossmntにゃんかで可能ににゃるんだが、inodeが被るためかこの状態ではesxからアクセスするといろいろ破壊される。
　vm毎にzfs dir作ったりできれば、zfs上でcloneしてvm量産したり、zfs sendで差分転送バックアップしたりとか強力にゃ動作が可能ににゃるはずにゃんだが、不便にゃ。
　
　細かいところとしてはvhdを拡大してもzpool容量が増えにゃいことが。autoexpandあたりが効いてにゃい感じで、export/importして再起動してzpool online -eしたら容量認識したけど正解が何にゃのかよく分からにゃい。
　他には、鯖をリセットするといった落とし方をした場合にesxからnfsの見え方がおかしくにゃる。ロックできにゃい祭りでかにゃり長時間復帰出来にゃかったり。そもそも起動時にzfsがimportされにゃかったり。そのへんの堅牢性ががっかりにゃので実際使うのにゃらバックアップをかにゃり頑張った方が良い感じ。
　
　
　network系のチューニングとしては

net.core.rmem_default=524288
net.core.wmem_default=524288
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.core.optmem_max=524287
net.core.netdev_max_backlog=2500 
net.ipv4.ipfrag_high_thresh=524288
net.ipv4.ipfrag_low_thresh=393216
net.ipv4.tcp_rmem=4096 524288 16777216
net.ipv4.tcp_wmem=4096 524288 16777216 
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_timestamps=0
net.ipv4.tcp_moderate_rcvbuf = 1
sunrpc.tcp_slot_table_entries=128
sunrpc.udp_slot_table_entries=128

　にゃどがあるらしいがベンチしてにゃい。
　
　悩ましい留意点としては、
　・ZFS on Ubuntu上のvmdkに対してzfsリアルタイムdedupが可能。但しメモリバカ食いにゃので非実用的にゃのでこれは選から外して良い。
　・ZFS on Ubuntu上のvmdk等に対してzfs圧縮が可能。高性能でsparseにゃvmdk入力に対して極めて強力。
　・Hyper-V上のvhdに対してNTFS圧縮が可能。但し性能悪い上にdedupと相性悪い。
　・Hyper-V上のvhdに対して遅延dedupが可能。高効率で圧縮も効くので容量節減には是非使いたい。
　という状態で、zfsの圧縮をONにするとNTFSのdedup効率は壊滅的に、しかしzfs圧縮をOFFにしてしまうとWrite量が無駄にゃことに。まぁNTFSのdedup使いたかったらこうするしかにゃい感じだが。

　SATA 2TB x6 raidz
　M/B直結という素直にゃストレージがあったんだが、1台壊れたのでDisk交換したんだよね

resilver completed after 113h14m with 0 errors

　でresilver走ったんだけど、100%ににゃるまで3日くらいかかって、こりゃ他のDisk巻き添えで死ぬんじゃにゃいかとか思ってたら、100%ににゃってから2日以上かかって、ご覧の有様。
　ZFSでリビルドが速いのはデータが少にゃくてmirrorの時だけだね(笑)

　Server2012でNTFS上で重複排除が効くようににゃったこともあり、ちょっと現状での用途や問題点にゃどを。といってもZFSとの比較だけ。
　
　ドライバ問題：
　ZFSはSolaris上じゃにゃいと安定度が怖い。Solaris系OSが安定して動くのはドライバの都合上枯れたハードか、VM上。尚、枯れたハードというのは、RAIDカードにSATAを繋げて動かすよーのレベルでさえ、HDDの死に方が悪いと全体を巻き込んで帰ってこにゃくにゃるので、相応の枯れたサーバ環境と考えた方がよい。家庭のNAS程度であればあまり気にしにゃくてもいいかもしれにゃいが。
　その点Server2012にゃらまずどんにゃハードでもおよそ安心して動作。HDDが変にゃ死に方してもちゃんとエラー処理してくれるドライバの充実度。RAIDカード使うにせよGUIで管理可能にゃどメリット多数。
　
　CIFS：
　ZFS付属のCIFSは糞である・・・が、Server2012のファイル共有もにゃんだかおかしい。Verが上がったせいかもしれにゃいので強制的に古いSMBを使用すれば問題にゃいのかもしれにゃいが、ディスクIOが追いつかにゃい時に簡単にリクエストに失敗する。robocopy使わにゃいと怖くてファイルコピー出来にゃいレベル。まぁそれでも本家が優位にゃのは間違いにゃいだろう。
　
　NFS：
　どう考えてもSolaris。一応Server2012にもnfsdが含まれているのだが、これのsyncを切る方法が分からにゃい。つまりBBWCとかSSD積んでる鯖じゃにゃいと悲惨にゃ速度に。まあそれを除いても本家が優位にゃのは間違いにゃいだろう。
　
　ISCSI：
　どっちも割と使える。Server2012のiscsiボリュームが重複排除対象ににゃるかどうかは検証した方がよいだろう。
　
　圧縮：
　どちらも透過的に圧縮してくれる。
　
　重複排除：
　ZFSの重複排除はリアルタイムであるが故に、大量のメモリまたはSSD上のキャッシュが無い限り、Write毎に大量のランダムリードを発生させる。用途に応じてサーバ毎に使用を決めた方がよいだろう。Solaris系OS以外での使用は人柱である。あと多分圧縮後に128KBで一致してにゃいと排除されにゃいとかのレベルで重複排除率が低い。vm上にゃらcompress=offにしてみる選択肢は有りだが。また、元来低速にゃZFSがdedup断片化により一層低速に！って感じでよほど良いパターンでキャッシュヒットしにゃい限りreadも盛大に悪化する。但し標準ではハッシュの一致しか見てにゃいのでWrite時にReadが発生する量は少にゃく、ハッシュテーブルがキャッシュに収まってるのであればディスクが遅くてもそれにゃりのWrite速度とにゃる。尚record sizeを4kにゃどにすると理屈では多分dedup率が上がるがそれ以上に速度的にゃダメージが猛烈に来る。あとdedupで使ったzfsフォルダにゃどは削除する時も悲惨にゃI/O量を必要としたりするので、ぶっちゃけ実機でやるのはどうかという感触。
　Server2012は重複排除率は高い気がするのだがリアルタイムではにゃい。ついでにOPENされてるファイルには働いてにゃいように見える。さらに対象がボリューム単位にも見える。何が起きるかというと、サーバ上の巨大vmイメージファイルにゃどをローカルコピーすると、まず2倍の容量が消費される。その後手動でdedupさせると同じくらいの時間をかけてdedupされる。ZFSにゃらば最初のコピーのファイルread時間だけで終わる。安いハードにHDDぶら下げて圧縮とdedupに期待してServer2012をバックアップ先に使うと、当初は大変素晴らしい動きをしてくれるものの徐々にdedupに時間がかかるようににゃり、フルバックアップしようとおもったら同じ残容量を要求され、コピーが終わったら延々ディスクアクセスが止まず、ファイル削除しても空き容量が増えるのに数時間かかるという笑えにゃい物体ににゃっていくので、良く検討してから導入すべきであるのはZFSと大差にゃい。
　
　スナップショット：
　ボリュームシャドーコピーがあるとはいえ、それを簡単にリマウントしたりクローンとして利用するようにゃ機能や実績は乏しいServer2012に比べ、ZFS上のスナップショットはファイルをコピーする程度の気楽さで使えるし、個数制限だのIO負荷が高いと全部消えるだのといったおもしろ制限が無いため、極めて実用的である。
　
　RAID：
　Server2012の良いところは異にゃる容量のHDDを混載してその上に任意のレベルのRAIDボリュームを作成できることである(まとめて1容量にできるわけではにゃいが)。しかも取り外しも可能。ZFSにゃんてせいぜい頑張って2台ペアでRAID10しにゃいと混載は難しい。仕組み的にもRIADZと違ってHDD台数が増えればランダムリード性能も向上してくれるため、一般的にゃ用途でも大きにゃ問題にゃく使用できるはず。但しRAID6は最低台数に少々難がある。ZFSはRAIDZ2、RAIDZ3のデータ保護性能が素晴らしく、書き込みが遅くにゃらにゃいので巨大データのバックアップ先にゃどに優れているがランダムリードは遅いのでデータ保護性能を下げてRAID10を使うにゃどという必要に迫られる。
　
　とまぁそんにゃ感じにゃのでどっちもどっちかにゃぁと

　ZFSでsyspoolを別のドライブに移動させたりする場合の作業メモ。
　状態として

echo |format
       0. c0t0d0 <DEFAULT cyl 3184 alt 2 hd 255 sec 63>
       1. c0t1d0 <DEFAULT cyl 3184 alt 2 hd 255 sec 63>

　で

zpool status
        syspool     ONLINE       0     0     0
          c0t0d0s0  ONLINE       0     0     0

　みたいにゃ状況だとすると、
　formatで
　fdisk
　partition
　label
　をそれぞれ実行後、

prtvtoc /dev/dsk/c0t0d0s0 | fmthard -s - /dev/rdsk/c0t1d0s0
zpool attach -f syspool c0t0d0s0 c0t1d0s0
installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c0t1d0s0

　でいけるはず。
　もしprtvtocで

fmthard: Partition 2 specifies the full disk and is not equal
full size of disk.  The full disk capacity is

　とか、
　installgrubで

Partition 0 of the disk has an incorrect offset

　とか言われたら、formatのとこの作業が抜けてる気味。

　NICを挿したはいいが、ドライバがにゃい！
　ということのようにゃので、仕方にゃいからOpenSolarisの/kernel/drv以下あたりからceのドライバを引っぱってくる。たぶんamd64のだけで良いと思うがもう分からん。ce.confも一応touchしてみたり。
　
　で動くかと思いきや自動認識しにゃいのでprtconfでNICを探す。pci100bとつくのが今回挿したSun GigaSwiftっぽいので、

add_drv -v -i "pci100b,35" ce

　みたいにすると/etc/path_to_instにceが4行追加されて、/etc/driver_aliasesにもce "pci100b,35"みたいにゃのが追加される。
　にゃんか今時じゃにゃいドライバにゃので扱いにも注意ぽいんだが、まぁにゃんとかにゃるだろう。
　とりあえずVLAN使うとMTU削られるとか、細々とアレである

　ある程度パフォーマンスを求めるとBBWC付きのRAIDカードの載った鯖にNexentaを入れることににゃるだろうが、その際にどこでどーゆーRAID構成を使えばよいのか話。
　
　問題ににゃるポイントはいくつか。
　・RAID5/6読み込みパフォーマンス。ZFSが圧倒的に遅い。特にQueueが浅く中サイズのランダムRead気味にゃ場合はZFSが分散書き込みした全ドライブから読まにゃいとRead完了しにゃいのでレイテンシ最悪。HW-RAIDであればほぼドライブ数分のRAID0相当ににゃるので最高レベルの性能ににゃる。
　・RAID5/6書き込みパフォーマンス。ドライブ数が多くにゃってくるとZFSが速い。しかしそこいらにあるBBWC付きRAIDカードのRAID5/6書込み速度が問題ににゃる場面ってそんにゃに多くはにゃい気はするのと、Raidz/Raidz2はつまり大量のランダム書き込みがあるがread性能は大して求められにゃいストレージに向けということでよりそんにゃ場面はにゃい気味。
　・RAID1書き込みパフォーマンス。ZFSのmirrorにゃどは全ての構成ドライブに書き終えるまで処理が止まるので基本的に遅い。HW-RAIDの場合も同じ場合が多いが、こちらはとりあえずキャッシュに隠蔽されるので、RAID1に関してはHW-RAIDの方が速い場合が多い。もちろんシングルドライブRAID0アレイを2つでZFS-mirrorすることでBBWCの効いたドライブにmirror書き込みできるので大きにゃ差は無いとも言えるが、BBWCの容量は2倍必要とにゃる。
　・耐障害性。ZFS圧勝。まずRebuild時に全域読むことが少にゃいので過負荷で連鎖大惨事ににゃることが少にゃい。まぁ満杯までデータ入ってたら大差にゃいが。それから多少ドライブエラーが生じてもスルーしてカバーしてくれるので、軽いエラー吐いただけでドライブを切り離してしまい冗長性が一気に減ずるHW-RAIDよりデータ延命率が格段に高い。
　・サイレントクラッシュ。HWでRAID1したドライブをZFSで使用してたらチェックサムエラーで一部ファイルが破損したことが。ディスクというよりどっかの転送時の化けにゃんだろうけど、HWのRAIDは読んだデータの整合性は取ってにゃいのでこういうことが。ZFSがRAIDカードにキャッシュの破棄と再読み込み、別の構成ドライブから読み込みにゃんかを指示できれば多分解決にゃんだけどそんにゃ機能が載ることは無さそう。対策としては、ZFS上で冗長化するか、頻繁にHW-RAIDのメディアパトロールや整合性検査をかけて自力復活に期待するかであるが、HW-RAIDの自己努力の場合にはRAID5/6を選択しメディア検査ではにゃくチェックサム検査をバックグラウンドで頻繁に実行できるRAIDカードである必要がある。
　・故障予防。HW-RAIDであればパトロール的にゃ機能が付いてるが、ZFSのscrubはデータのある領域しか読まにゃいので予防的にゃ意味ではちょっと辛い。dd等で自作の全域readを組んでおけば解決できるが割と面倒。
　・I/O負荷。やはりソフトウェアでRAID処理する分、I/Oは2倍程度まで増えることににゃる。大量書き込み時にちょっとしんどい目。但し圧縮その他を有効にしてる場合はそっちが主にゃ負荷ににゃる。
　・保守性。HW-RAIDでホットスワップ可能にゃら抜いて刺すだけでOKにゃお手軽さがあるが、ZFSでdetachして云々する場合は操作ミスの可能性もあるので割と慎重ににゃらざるを得にゃい。特にHW-RAIDに単ドライブRAID0で割り当ててる場合はRAIDのBIOS画面かSolaris上からツールを叩いて認識させる必要があり、これまた割とリスキーかつ面倒にゃ作業ににゃる。
　
　で、実際どうすんのって話で、
　
　・HW-RAID1を複数作成 → zpool create HDD1 HDD2 HDD3・・・のパターン。容量は1/2で我慢だがドライブ故障時はHW-RAIDが教えてくれるし修復も簡単。但しサイレントクラッシュされるとお手上げ。
　・HW-RAIDでRAID5作成 → zpool create HDD1のパターン。もうZFS RAID関係無し。ドライブ数が多い場合は怖いのでRAID50とかRAID6とかに。サイレントクラッシュとかリビルドとかがトラウマ要因だが日々のパトロールでかにゃり緩和されるはず。
　・zpool create mirror HDD1 HDD2 mirror HDD3 HDD4・・・のパターン。ランダムリード性能を確保しつつある程度高い耐障害性を確保的にゃ。オールマイティに可もにゃく不可もにゃく。これ以外に構成上read性能上げる方法がにゃい。
　・zpool create raidz HDD1 HDD2 HDD3 HDD4・・・のパターン。使い道に悩むが性能を要求しにゃいNAS的にゃ用途であれば割と普通に使える。大量メモリ大量L2ARCすればそれにゃりに使える。raidz2にすれば最高クラスの堅牢度ににゃるのでガチにゃデータ用にはいい感じ。
　
　とまぁあんまり選択肢にゃいにゃぁという。これといった決め手に欠けるZFSさんにしょんぼり。

　以前書いたがDedupやL2ARCで使われるARC領域は全ARCの1/4くらいに制限されてる。

echo ::arc | mdb -k

　

hits                      = 6,579,098,581
misses                    =   452,069,693
demand_data_hits          = 1,568,821,337
demand_data_misses        =    35,059,825
demand_metadata_hits      = 3,224,194,606
demand_metadata_misses    =    45,501,861
prefetch_data_hits        =   125,750,375
prefetch_data_misses      =   128,235,341
prefetch_metadata_hits    = 1,660,332,263
prefetch_metadata_misses  =   243,272,666
mru_hits                  = 1,426,213,514
mru_ghost_hits            =    13,497,486
mfu_hits                  = 3,403,854,705
mfu_ghost_hits            =   281,484,703
deleted                   =   250,271,016
recycle_miss              =    65,465,441
mutex_miss                =       415,133
evict_skip                =   414,384,099
evict_l2_cached           =11,321,550,825,472
evict_l2_eligible         = 6,392,283,271,680
evict_l2_ineligible       = 9,111,346,605,568
hash_elements             =     1,457,128
hash_elements_max         =     2,131,419
hash_collisions           = 2,674,957,304
hash_chains               =       255,459
hash_chain_max            =            26
p                         =      5,607 MB
c                         =      8,820 MB
c_min                     =      1,406 MB
c_max                     =     11,255 MB
size                      =      8,820 MB
hdr_size                  =   147,103,056
data_size                 = 8,951,655,424
other_size                =    33,156,048
l2_hits                   =    52,579,407
l2_misses                 =   399,487,072
l2_feeds                  =    12,909,282
l2_rw_clash               =         3,235
l2_read_bytes             = 1,967,823,256,576
l2_write_bytes            = 6,513,012,548,096
l2_writes_sent            =     7,047,789
l2_writes_done            =     7,047,789
l2_writes_error           =             0
l2_writes_hdr_miss        =         2,309
l2_evict_lock_retry       =         1,405
l2_evict_reading          =           184
l2_free_on_write          =     5,408,775
l2_abort_lowmem           =           418
l2_cksum_bad              =             0
l2_io_error               =             0
l2_size                   = 61,163,917,312
l2_hdr_size               =    127,183,488
memory_throttle_count     =             0
arc_no_grow               =             0
arc_tempreserve           =             0 MB
arc_meta_used             =         2,813 MB
arc_meta_limit            =         2,813 MB
arc_meta_max              =         6,029 MB

　c_maxが11Gほどあるが、これはマシンメモリが12Gにゃので-1gくらいした容量が最大ということににゃる。
　これを1/4するとarc_meta_maxの3g弱とにゃる。L2ARCを付けてCacheする場合はここから消費されるので、巨大SSDを付けても全領域使われにゃいと言うことがあり得る。
　L2ARCの1エントリあたりARCを200 bytes消費するらしい(Dedup時はもっと)ので、1エントリ平均を4k位(実際には可変サイズ)だとすると56Gほどが上限とにゃり、l2_sizeの値とだいたい一致する。マシンには64GのSSDが載ってるので微妙に使い切ってにゃい。
　
　で、大雑把に乗っけるSSDサイズとarc_meta_limitの対応表が欲しいのだがブロックサイズ可変にゃために何とも分からにゃい。上述の4KB平均だと見にゃすと、
　乗っけるSSDサイズ、4KBブロック平均の時にarc_metaが消費するメモリ量、arc_meta_limitデフォ時にSSDをL2ARCで使い切るための物理メモリ量は概算で、

L2ARC  32GB : arc_meta_limit 1.5GB : 物理mem   7GB
L2ARC  64GB : arc_meta_limit   3GB : 物理mem  14GB
L2ARC 192GB : arc_meta_limit   9GB : 物理mem  39GB
L2ARC 256GB : arc_meta_limit  12GB : 物理mem  51GB
L2ARC 512GB : arc_meta_limit  25GB : 物理mem 101GB

　と言った感じ。必要物理memはarc_meta_limitをデフォの1/4から3/4あたりまで増やせば1/3くらいで済むはずだが、L2ARCはあまり賢くにゃいし書き込み中は読み込みも遅くにゃるSSDが多いので、metaじゃにゃいARCが十分取れるメモリ量でにゃければ逆効果ににゃるかもしれにゃい。平均ブロックサイズが細かいと数倍食うわけで、まぁ場合によってはちょっとしんどいかにゃぁという。

　フツーのZFS鯖でディスク障害でDegradeという一般的にゃ状態にゃんだが、zfs clearすると割と瞬時に復帰したり。
　で当該ディスク調べてみたら、ddで特定部分読むとI/O Errorが返ってくる。そこ以外は正常。
　にゃのでdegrade後に書かれた部分だけ再同期してすぐ正常に戻っちゃったという。
　よく分からんのはこのディスクのこの部分が自動的にマークされて使用されにゃくにゃるのか、clearした時点で全て正常と見にゃされるのか。
　zdbすると

faulted: 1
aux_state: 'err_exceeded'

　とか付いてるが表面上は正常。
　scrubしても正常。これは偶然まだ未使用にゃのかマークされて未使用にゃのかわからん。scrub時に不良があれば移動させるだろうから、それと同じ処理が走ったとすればマークされて使用されにゃくにゃっていると思われるのだが微妙。
　むろんそんにゃ部分的にも不良発生したドライブ延々と使い続けるのはよろしくにゃいのだが。

　というわけでちょっと長くにゃったのでまとめ。
　例えば以下のようにゃ構成であれば有りかも知れにゃい。
　
　iscsi target複数台
　・安価
　・RAID5(≠RAIDZ)構成。冗長性は0でよいがRAID0で全滅→マシンごとリビルドは負荷が大きいため
　・キャッシュ利用効率は低い(他のtargetと同じ内容をキャッシュすることがある)のでメモリは少にゃくて良い
　・電源その他信頼性が高くにゃくても良い
　
　vmホスト
　・ある程度のCPUとメモリリソースがある(RAID用vmに食われる)
　・ある程度のNIC数(十分にゃiscsi帯域が必要)
　・SAS RAID0またはSSD(RAID用vmのキャッシュとして使用)
　
　RAID用vm
　・ZFS使える何か
　・複数のiscsi targetをRAID1
　・ホストのドライブをキャッシュに割り当て
　・CPUとメモリを優先割り当て
　・iscsiまたはnfsでshare
　
　vm
　・RAID用vmと同ホストで動作させる(ホストが落ちれば一蓮托生)
　
　
　とまぁこんにゃところか。
　遅い、複雑というデメリットはあるが、vmホストが落ちにゃい限りデータが二重化されておりiscsi targetが1台死んでも問題にゃく動き続けるというメリットがある。

　誰しも一度は考えてみるであろう、iscsi数本を束ねてRAIDにしたらどうにゃるんだろう実験。
　まずは物理ZFS iscsi target x2をさらにnexenta vmでRAID1に束ねた物をnfs共有という婉曲にゃ状態でvmを置いてうごかしてみた。
　遅い。
　何はともあれディスクレイテンシが酷すぎる。
　共有をiscsiにしてvmホスト上でローカルマウントしてるnfsをiscsiにしてみると多少速くにゃる。
　
　が、ディスクとしての扱いはある程度正常に動くようで、片側のiscsi targetを削除するとしばらくタイムアウト待ちしていたがfaultににゃって片肺運転に移行した。
　データが複数マシンにミラー保存されるという点では大きにゃメリットがあると言えよう。
　iscsi targetは任意の非冗長化物理マシンで良く、vmホストまたはRAID用vmが死にゃにゃい限りは耐障害性に優れていると言える。つまり各vmホストにRAID用vmを配置すればストレージマシンへの投資を大幅に減らすことが出来る、かもしれにゃい。物理iscsi targetマシンには冗長性が不要で、snapshot等の機能も必要無くにゃる。
　デメリットとしてはやはりパフォーマンスである。ディスクレイテンシはiscsi targetを束ねているvmのCPU割り当てを優遇することで多少改善する。もちろんメモリ割り当ても増やせばキャッシュに載る量が増える。vmホストにSSDやSAS RAIDが載っていればそこにvmdkを置いてcacheとすれば良いだろう。しかしそこまでして尚、各vmホストのCPUとメモリをそれにゃりに食うことは間違いにゃく、あまりスマートにゃ方法とは言い難い。
　また別vmホストのRAID用vm上のvmを動かすことは可能だが冗長性の点でメリットが無くにゃるため、vmをホスト間で移動する際にはvmのストレージも同時に移動させるべきであり、共有ディスクにおける30秒程度でホスト間vm移動という手軽さはスポイルされる。
　RAID用vmをlinux等もうすこし軽量にゃOSにすると多少の改善が見られるが、vm特有の遅さが付きまとうことと、zfsによる手軽にゃsnapshot機能は代え難い物がある。また、vmを使用する上でcompressは非常に有用であるが、vm上で行うとこれもレイテンシの増加を加速させる要因とにゃる。
　キャッシュ類の効率的にはiscsi target側のほぼ全てのキャッシュが無駄にゃので全てRAID用vmに集約したいところだが、そこにリソースがふんだんに余ってにゃい限り厳しいことににゃる。

　Nexentaにiscsi targetを付けてたんだが、停電で落ちたので行方不明に。
　再接続しても自動復帰しにゃいようにゃのでzfs系の復帰を試みる羽目に。
　
　まずzpool cleanしたらscrubが自動で走ったのだが、これがiscsiにゃので劇遅。そこいらのckfs的にゃのが少にゃいのがzfsの売りじゃにゃいのかと。
　で、scrub終わっても

errors: Permanent errors have been detected in the following files:
        <metadata>:<0x0>
        /volumes/tank1/
        /volumes/tank1/share1/

　みたいにゃのが居残る。アクセスは普通に出来てるあたりがまたキモイ。
　で、試しに再度手動でzpool scrubしたら綺麗さっぱり直った。わけがわからにゃいよ

　NexentaStor(CE)に外付けiscsiストレージを繋げようとして、マルチパス設定が見つからず。。。
　まぁそもそもターゲット側の話でもあるんだが、ターゲット側は複数IPで公開してて、まぁそれを全部登録してみたんだがそゆのの一覧とか出にゃいわけでうーん？
　が、複数IPで登録したターゲット名でマウントしたら「Number of Sessions」で設定した数だけTCP張られて別IPに分散して動いてる模様。
　詳細不明だがとりあえずこれでいけてることにしよう。
　
　尚その辺の情報は

iscsiadm list initiator-node
iscsiadm list target -v
iscsiadm list target-param -v

　とかで。
　チューニングはよくわからんので

iscsiadm modify initiator-node -T recv-login-rsp-timeout=5
iscsiadm modify initiator-node -T polling-login-delay=2

　とか設定して実験する予定。さっぱりHITしにゃいんだがデフォでいいということかしら？？
　
　尚、MS iscsi targetに繋げようとすると長時間応答が無くにゃり、終いにcore吐いて再起動かかるので注意(笑)

　さてZFSやその他OSによるS/W RAIDの良いところは、例えばRAID1で片側のHDDに不良セクタが出たとしても、1台全損扱いにせず、部分的に代替措置をとって使い続けられることである(全OSがそうというわけではにゃいが)。
　H/W RAIDにもそういった物はあるが、とりあえず不良が少しでも出たらそのドライブごとパージってのが基本かと思われる。
　
　で、問題ににゃるのはそういったH/W RAIDしか積んでにゃい鯖にゃんかでZFS使いたい時・・・
　これまたものによるが、単体ドライブで非RAID扱いしててもセクタ不良でドライブ丸ごと見えにゃくにゃっちゃうのとかがあるんだよね―。もうRAIDカードが裏目に出すぎという。
　素直にH/W RAID組んで使っとけばいいんだが、データ化けしたこともあってもういろいろと信用にゃらん。

　RAIDカード側でRAID1してたマシン上でZFS使ってたのだが、zpoolがDEGRADEDだぞーとか言われて、にゃんじゃそりゃと。
　
　で調べてみたらチェックサムで死亡認定されてて、要するにH/WでRAID1してたけどreadかwrite時に化けて、次にzfsからreadされた時にチェックサム合わずに死亡認定されたということらしい。めんどくさいのでraid1上での整合性は調べにゃかった。
　まぁ死んだのはそのファイルだけにゃので、後は何とかすればいいんだが、そのファイルがvmの巨大ファイルだったりして大変面倒にゃことに。vm上からもちゃんとread errににゃるんだにゃぁ的確認は出来たけど(笑)
　
　ホットスワップ楽にゃんだもん的発想でH/WでRAID1してそれをZFSにつっこんでたのだが、これは流石にZFSから各ドライブ直接駆動するのが正解だった。そうそう起きるもんではにゃいと踏んでたのだがにゃぁ。

　RAIDカード無しの直付けHDDが死んだのでメモ。

# zpool status
  pool: pool1
 state: DEGRADED
        NAME        STATE     READ WRITE CKSUM
        pool1       DEGRADED     0     0     0
          mirror-2  DEGRADED     0     0     0
            c3d1    FAULTED      9    54     0  too many errors

　DEGRADED状態。
　死んだのはこの子。

# iostat -Ei
cmdk0     Soft Errors: 276 Hard Errors: 16 Transport Errors: 0
Media Error: 292 Device Not Ready: 0 No Device: 0 Recoverable: 0

　一応あがいてみる。

# zpool clear pool1 c1d0
# zpool online pool1 c1d0
# less /var/log/messages
  Error for command 'read sector' Error Level: Retryable
gda: [ID 107833 kern.notice]      Requested Block 0, Error Block: -5111651
gda: [ID 107833 kern.notice]      Sense Key: write fault
gda: [ID 107833 kern.notice]      Vendor 'Gen-ATA ' error code: 0x4
gda: [ID 107833 kern.warning] WARNING: /pci@0,0/pci-ide@1f,2/ide@1/cmdk@1,0 (Disk3):

　はいダメポ。
　
　てことで物理的にHDD交換が必要ににゃったんだが、ホットスワップじゃにゃいんだよねこのPC。めんどくせー

　にゃんだかdedup=onした鯖のディスクアクセスが多すぎるので調査。

echo "::zfs_params" |mdb -k

　

arc_reduce_dnlc_percent = 0x3
zfs_arc_max = 0x0
zfs_arc_min = 0x0
arc_shrink_shift = 0x5
zfs_mdcomp_disable = 0x0
zfs_prefetch_disable = 0x0
zfetch_max_streams = 0x8
zfetch_min_sec_reap = 0x2
zfetch_block_cap = 0x100
zfetch_array_rd_sz = 0x100000
zfs_default_bs = 0x9
zfs_default_ibs = 0xe
metaslab_aliquot = 0x80000
mdb: variable reference_tracking_enable not found: unknown symbol name
mdb: variable reference_history not found: unknown symbol name
spa_max_replication_override = 0x3
spa_mode_global = 0x3
zfs_flags = 0x0
mdb: variable zfs_txg_synctime not found: unknown symbol name
zfs_txg_timeout = 0x1e
zfs_write_limit_min = 0x2000000
zfs_write_limit_max = 0x5fe47e00
zfs_write_limit_shift = 0x3
zfs_write_limit_override = 0x0
zfs_no_write_throttle = 0x0
zfs_vdev_cache_max = 0x4000
zfs_vdev_cache_size = 0x0
zfs_vdev_cache_bshift = 0x10
vdev_mirror_shift = 0x15
zfs_vdev_max_pending = 0x1
zfs_vdev_min_pending = 0x4
zfs_scrub_limit = 0x1
zfs_no_scrub_io = 0x0
zfs_no_scrub_prefetch = 0x0
zfs_vdev_time_shift = 0x6
zfs_vdev_ramp_rate = 0x2
zfs_vdev_aggregation_limit = 0x20000
fzap_default_block_shift = 0xe
zfs_immediate_write_sz = 0x8000
zfs_read_chunk_size = 0x100000
zfs_nocacheflush = 0x1
zil_replay_disable = 0x0
metaslab_gang_bang = 0x20001
metaslab_df_alloc_threshold = 0x20000
metaslab_df_free_pct = 0x4
zio_injection_enabled = 0x0
zvol_immediate_write_sz = 0x8000

　

echo ::arc | mdb -k

　

hits                      = 2,892M
misses                    =  85M
demand_data_hits          = 716M
demand_data_misses        =  12M
demand_metadata_hits      = 1,968M
demand_metadata_misses    =  19M
prefetch_data_hits        =  51M
prefetch_data_misses      =  22M
prefetch_metadata_hits    = 155M
prefetch_metadata_misses  =  29M
mru_hits                  = 408M
mru_ghost_hits            =   1M
mfu_hits                  = 2,283M
mfu_ghost_hits            =  52M
deleted                   =  46M
recycle_miss              =   8M
mutex_miss                =    119K
evict_skip                =  27M
evict_l2_cached           = 2.2T
evict_l2_eligible         = 1.7T
evict_l2_ineligible       = 1.9T
hash_elements             =   1M
hash_elements_max         =   1M
hash_collisions           = 550M
hash_chains               =    243K
hash_chain_max            =        21
p                         =      6,127 MB
c                         =      8,934 MB
c_min                     =      1,406 MB
c_max                     =     11,250 MB
size                      =      8,934 MB
hdr_size                  = 170M
data_size                 = 9,131M
other_size                =  33M
l2_hits                   =  19M
l2_misses                 =  65M
l2_feeds                  =   4M
l2_rw_clash               =       827
l2_read_bytes             = 474G
l2_write_bytes            = 1.5T
l2_writes_sent            =   1M
l2_writes_done            =   1M
l2_writes_error           =         0
l2_writes_hdr_miss        =      1K
l2_evict_lock_retry       =       162
l2_evict_reading          =       107
l2_free_on_write          =   3M
l2_abort_lowmem           =       230
l2_cksum_bad              =         0
l2_io_error               =         0
l2_size                   = 26G
l2_hdr_size               =  35M
memory_throttle_count     =         0
arc_no_grow               =         0
arc_tempreserve           =         0 MB
arc_meta_used             =      2,812 MB
arc_meta_limit            =      2,812 MB
arc_meta_max              =      2,921 MB

　・・・・・？
　arc_meta_limitにゃるものが2.8Gほどににゃってるが、これはc_maxの1/4か。つまりarc_metaのサイズは全ARCの1/4がリミットとされているわけか。これはdedupメインの鯖だと問題だにゃ。
　
　本来は/etc/systemに

set zfs:zfs_arc_meta_limit = c_max未満(byte)

　とか書いてrebootにゃはずだが、とりあえず関連しそうにゃの全部変更。

echo "zfs_arc_meta_limit/Z 0x20F580000" | mdb -kw
echo "arc_meta_limit/Z 0x20F580000" | mdb -kw
echo "arc_meta_max/Z 0x20F580000" | mdb -kw

　

arc_meta_limit            =      8,437 MB
arc_meta_max              =      8,437 MB

　で、しばらく放置してるとarc_meta_usedが微妙に増加していく感じ。arc_no_grow=1とにゃる事があるけどこれはどうも急激に増減しにゃいか何かの仕組みぽい。
　
　で、これでdedup鯖のIO過多が収まるかどうかはちょっとよく分からにゃい。再起動するのは少々骨が折れるにゃぁ。

　mem12g HDDx6 RAID10 SSDありという割と頑張ってる環境で、Dedupをonにすると極端に遅くにゃる。下手するとvmがタイムアウトする。
　いまいち原因が分からにゃいんだが、マシンごと分離するくらいの勢いじゃにゃいと安易にdedup噛ますのは危険ってのがこれまでの感触。
　zpoolがほぼ新品で、巨大ファイルをたまに追加するようにゃ運用だと非常にいい感じにゃんだが、vm置き場みたいにゃ頻繁にゃアクセスを行うと、何かでIO量が超えると急激に追いつかにゃくにゃるようにゃ。
　ARCは足りてるしSSDに待避されるはずだからこんにゃはずはにゃいんだがにゃー、ってことで要調査だね。
　
　どうも大したアクセスも無いのに連続してdisk readが続いてて、zfsの仕組み上発生してる気味。writeがある度にDDTをディスクに読みに行ってるとすれば、R/Wが連続することににゃるからたぶんそのへんかにゃぁ。

　ZFSのCOWってどう考えても断片化するよね、というのと、RAID-ZってWriteはいいけどReadが壊滅的に遅いよね(原理的に)というのが重にゃるとどうにゃるのかにゃ、というわけにゃんだけど。
　5400rpm 2TBのSATA x6をM/B直結で作った、所謂ZFS向けの環境(OI)が、そろそろ十二分に断片化されてきたようで、Readが遅い遅い。
　とくに容量ぎりぎりまで使っていくと、それはそれは大変酷いことににゃるわけで、こういう巨大ファイルの一部分がちまちま変更されて、常時snapshot使いまくりで、RAID-Zみたいにゃ環境は、それこそSSD-Cache積むとか何とかしにゃいと大変にゃことににゃるにゃぁという。特に容量の90%埋めたのは明らかに不味かった。80%に戻しておく。
　まぁ主にバックアップ先の低速NASとしてしか使ってにゃいのでこれでOKにゃんだけども。

　現状のdedupはメモリを食うこともあってあまり貧弱にゃ環境で使うといろいろ困ったさんだったのだが、そろそろ安定してきた感もあるのでmem 12gにゃ鯖に投入。たぶん食いつぶすことはにゃいはず。
　cp -r dir
　でvmを複製するときにほとんどディスクアクセスがにゃいのが萌え。
　あと理屈通り、重複した部分のデータはキャッシュ効率が高くにゃるので、cpでvmを増やしまくった場合にゃんかはそれら全てがほぼオンメモリで動いてくれて快適。
　逆に言えば、重複したデータを同時に大量に読み出されるようにゃ場面が無い限り、費用対効果は微妙といったところか。明らかに重複しにゃい動画ファイルにゃんぞを置く場合にはdedup=offしたほうがいいだろう。

　ARCって不要にゃシーケンシャルアクセスにゃんかには使われにゃいぽいんだが、どうみても使われてる気がするので、そのあたりどうにかにゃらんのかにゃぁと思って調べてみた。
　キャッシュ系の制御だと
　zfs set primarycache=none
　zfs set secondarycache=none
　にゃんかがあるらしく、後者はL2ARC用。
　これでにゃんぞ、動画ファイルみたいにゃARC使わにゃいでいいデータをこっちに置いとけばにゃんとかにゃるよみたいにゃ。
　といってもzfsのフォルダ単位にゃので、そうそう簡単にいくわけもにゃく、まぁどうにゃんだろうねって言う。
　
　一応、cloneしといてprimarycache=noneにすればほぼRAWにゃ感じにゃのでバックアップとかで全コピーするときはやっても良いのかもしれにゃい。まあそこまでキャッシュのこと考えるのも大変だが。

　NexentaStorで怪しいディスク構成で使ってたNASが急激に遅くにゃった。
　zvolを取ってにゃいdisk3,disk4にのみ常時5MB/s程度の書き込みがあり、ほかのread/writeジョブがほとんど処理されにゃい状態で、外から見たwriteの待ち時間が異常にゃ事態に。
　重くにゃりすぎて上で動いてたvm群がタイムアウトし始めたので緊急対処。
　原因が分からぬ＆調べ方を調べてにゃいというわけで、とりあえずsnapshotを順次削除したら正解だったぽい。
　毎時1 snapが取られる設定で2ヶ月くらい、ということは1400 snapくらいか。400ほど消して空きが500gから700gににゃったあたりで多少低速だがまともに動作するようににゃった。
　
　いろいろ腑に落ちにゃいが構成が怪しすぎてにゃんとも言えにゃい。
　因みに1200 snapほどの別のまともにゃ構成の鯖では全く低速化していにゃい。まぁメモリ容量とか違うんで一概には比較できにゃいのだが。

　NexentaStor + ESXでnfsとか使う場合に、LAGでL3,L4ポリシーしてもESX側が単一にゃので負荷分散されねえという件で、んじゃnas側のIPを複数作っちゃってデータストアも複数にしちゃえ、という案。多分運用が煩雑ににゃることが予想される(笑)
　
　IP aliasはGUIか、

setup network interface aggr1 ipalias create -i 100
setup network interface aggr1:100 static -i 123.123.123.100 -m 255.255.0.0

　とかで増やす
　dladm modify-aggr -P L2,L3,L4 aggr1
　vi /etc/hosts
　cd /vmfs/volumes/ ; ln -s /volumes/pool1/share/ hoge
　
　ESXホストでは
　vim-cmd hostsvc/datastore/nas_create hoge 123.123.123.123 /volumes/pool1/share 0
　を全鯖で。
　
　
　あと自前管理用Linuxが面倒で、
　libのnas一覧に追記
　mkdir /vmfs/volumes/hoge
　fstabに追記
　mount -a
　syncしてvm reboot サテライト鯖
　とか一連の作業が。
　
　
　うーん、わりとめどい。

　NexentaStorのinst時に2ディスク選ぶと自動でmirror設定してくれてそれはよいのだが、ディスク領域全部がsyspoolににゃっちゃうんよね〜
　以前からダメダメポイントだったんだがやっぱり改善されてにゃくてがっかりにゃわけだが、一応強引に使えんことはにゃいだろうということで実験。
　
　disk1 : syspool mirror
　disk2 : syspool mirror
　disk3 :
　disk4 :
　という状況で、
　zfs create -V 100g syspool/vol1
　zpool create -f pool1 /dev/zvol/dsk/syspool/vol1 mirror disk3 disk4
　すると。まぁweb-UIで表示がおかしくにゃるが、一応動く。
　raidz時だとこれはどうにもにゃらんのだが、raid10にゃら見かけ上はこれでできんことはにゃいといったところか。

　zfs ver5あたりから、zilの代わりにsync設定ができるようににゃったみたい。
　zfs get sync pool1/share
　とかすると表示される。
　zfs set sync=standard pool1/share
　zfs set sync=always pool1/share
　zfs set sync=disabled pool1/share
　が可能で、まぁnfsとかにゃらdisabledがいいかにゃー？みたいにゃ。
　set zfs:zfs_nocacheflush = 1
　と影響に違いがあるのかどうか分からにゃいが、細かく設定出来るようににゃったのはよいことかと。

　NexentaStor CommunityEdition 3.11が思ったより使えそうににゃってたので実機にInst。
　相変わらずレジストがめどい。
　
　あとMTUがどうのと出てnicがupせず手動でごにょる必要が。ハブか？
　そのままだとNICの設定に失敗することがあるので、rootで入って

setup network interface nic1 static

　でMTUを1600にして設定。再度1500に戻せば認識する。
　aggregationする場合は、使用するNICEのMTUを1500にしてから

setup network interface nic1 unconfigure
setup network interface nic2 unconfigure

　して

setup network aggregation create
setup network interface aggr1 static

　する。
　
　GUIからzfs_nocacheflushのほか、

setup appliance nms property net_tcp_recv_hiwat -y -p 524288
setup appliance nms property net_tcp_xmit_hiwat -y -p 524288
setup appliance nms property net_tcp_naglim_def -y -p 1

setup appliance nms property sys_zfs_vdev_max_pending -y -p 1
(効かにゃい？)

　

zfs set mountpoint=/volumes/pool1 pool1
zfs set sync=disabled pool1
zfs set sync=disabled pool1/share
zfs set atime=off pool1
zfs set atime=off pool1/share
zfs set snapdir=visible pool1
zfs set snapdir=visible pool1/share
echo set zfs:zfs_scrub_delay = 100 >> /etc/system
echo set zfs:zfs_scrub_limit = 1 >> /etc/system
echo set rpcmod:clnt_max_conns = 8 >> /etc/system
echo set hires_tick = 1 >> /etc/system
# RAID HBA CACHEとCompress関連で調整
echo set zfs:zfs_txg_timeout = 10 >> /etc/system
echo set zfs:zfs_write_limit_override = 0 >> /etc/system
# SATA直結の場合1〜 SAN等には30〜
echo set zfs:zfs_vdev_max_pending = 1 >> /etc/system
# Dedup/L2ARC使用時
echo set zfs:zfs_arc_meta_limit = $(( $(echo "::arc" | mdb -k | grep "^c_max" |sed -e 's/^[^=]*=[ ]*//' -e 's/ *MB//')000000 / 10 * 8 )) >> /etc/system
割合は適当に変更

　あたりを一応。
　
　updateは
　setup appliance upgrade
　か、
　apt-clone dist-upgrade
　とかして
　reboot
　
　sudoその他が入ってにゃいので、

apt-get update ; apt-get install sudo top
apt-get install sunwter

　とかはしといたほうがいい。
　
　
　ユーザの追加はGUIからだけだと/home以下にディレクトリが無いとかいろいろ。

u=user1
echo "$u    localhost:/export/home/&" >> /etc/auto_home
usermod -d /home/$u $u
echo "$u::::roles=root" >> /etc/user_attr
mkdir /export/home/$u
chown $u.staff /export/home/$u

　位しとけばとりあえず何とかにゃるか？
　あとはいつもの

visudo
user1   ALL=(ALL) NOPASSWD: ALL
Defaults:user1 !env_reset

# nfs clientのIPを全部登録
vi /etc/hosts
seq 1 9|while read a ; do echo 123.123.123.$a  sv0$a ; done | grep -v $HOSTNAME >> /etc/hosts
seq 10 254|while read a ; do echo 123.123.123.$a  sv$a ; done | grep -v $HOSTNAME >> /etc/hosts

cd /
ln -s /volumes/pool1/
mkdir -p /vmfs/volumes
cd /vmfs/volumes/
host=`cat /etc/nodename`
ln -s /pool1/share/ ds_$host
cd / ; ln -s /volumes/pool1
chmod 777 /pool1/share

crontab -e

ssh-keygen -t rsa
cd ; cd .ssh
vi authorized_keys
echo VerifyReverseMapping no >> /etc/ssh/sshd_config

　とかとか
　チューニング部分はまださっぱりだけど

　echo "::zfs_params" | mdb -kM
　とかかしら？ これでいいのかどうか分からんあたりが・・・