opensolarisを新規に入れる機会があったので、とりあえずpfexec pkg image-updateして5.11 snv_134bにしてzpool zfs upgradeしてzfs create -o dedup=onでいろいろファイルコピー。
ここまでは大変調子が良かった。
compressはoffだが、そんにゃに速度も低下しにゃいように見えるし、dedup率も1.5〜2程度ににゃった。
が
deleteが致命的に遅い。
ファイル削除するのに数時間かかっててこりゃダメだと放置してたらハング。
これは酷いってことでzfs destroyかけたらこれまた数時間しても終わらにゃい。zpoolを消すべきだった。
rreadが大量に出て遅くにゃってるようにゃので、SSDにゃらある程度瞬時に消せるのかもしれにゃい。
ということでよほどものすごい削減効果があるとかじゃにゃい限り、特にvmdkにゃどの巨大ファイルをdedupにゃzfsに置くと、かにゃり死ねる結果が待ってる気がする。
WinXP + AD + DFS + フォルダリダイレクトにゃ環境で、何をするにも異様に重いという不具合。デスクトップをクリックして反応が返ってくるのに10秒ほど待たされたりとか。但し不定期。
感触としては、ネットワーク系のタイムアウトを待って、反応が返ってきている。例えばDFSの存在しにゃい鯖を見に行ってタイムアウト待ってるとかそんにゃ感じ。一度タイムアウトすれば、しばらくはまともに動くというのも、多分ネガティブキャッシュに載ってるから。
・・・が、サーバ周辺のDNSやDFS関連を見直したが、いまいちおかしにゃ設定は見あたらにゃい。イベントも正常。
フォルダリダイレクトをやめればかにゃり全体がまともに動くようににゃるので、smb関連にゃのは間違いにゃいのと、DFSが原因ではにゃさそう。
ファイル鯖がnfs上に乗ってるvmだったりするのでファイル鯖のHDDが遅延しているのかと思ったが、多数のクライアントで非同期に固まるようにゃのでこれは違いそう。
というわけであちこちいじくって分からずだったのだがかにゃり使い物ににゃらにゃい遅さにゃので本格調査した結果、vmwareが原因と判明。といってもクライアントのvmwareが生成した仮想NICの問題。こいつらのファイル共有が有効ににゃっていたので、smbアクセスする度にブロードキャストかにゃにか投げようとしていたらしい。で、繋がってにゃいのでタイムアウトと。このWinの動作自体がにゃにか間違ってる気がするっていうか、名前解決にせよにゃんにせよADに繋がっててそんにゃ動作をする必要が感じられにゃいので、やはりにゃにか設定の問題かと思うのだがわからず。
フォルダリダイレクトにゃ環境にゃどでしか体感出来にゃいから表面化してにゃいのかもしれにゃいが、このあたりの動作は複雑怪奇。
にゃんか最初から兄が暗黒面、妹がその真逆状態にゃので、いつものように途中でマコの超絶鬱設定にゃ過去が大暴露みたいにゃことににゃらず安心して読める(と書いてる時点で安心して読めてにゃかったが)。