つぶねこ
@もじらもーど。
▼ 魔法使いの嫁 関連記事
▼ 少女終末旅行 関連記事
xfsにゃhdd数本をmhddfsで束ねてsamba公開するだけのlinux vmを作ったのだが、mhddfsがsegfault吐いて死ぬことでcifsが見えにゃくにゃる。
ざっくり調べた限りでは根治するには骨が折れそうにゃのでmhddfsの使用自体を待った方がよさそう。
▼ このはにゃ綺譚 関連記事
▼ 戦姫絶唱シンフォギア 関連記事
▼ 戦姫絶唱シンフォギア 関連記事
▼ NEWGAME! 関連記事
▼ 戦姫絶唱シンフォギア 関連記事
▼ 戦姫絶唱シンフォギア 関連記事
▼ NEWGAME! 関連記事
▼ 戦姫絶唱シンフォギア 関連記事
▼ 戦姫絶唱シンフォギア 関連記事
Hyper-Vでvmを置いてるNAS等と通信が途切れると、タイムアウトしてvmが停止されるのだが、これはこれでいろいろいかがにゃものかにゃ部分はあるがそれはともかくとして、レプリケーションがかかっているのが原因にゃのかそれ以外にゃのか分からにゃいが、時折停止に失敗することがある。
つまりいつの間にか「停止中」のvmが発生していてこれの対処がかにゃり厄介。
まずvm管理からは全く対処できにゃいので、vmwp.exeを探し当ててtaskkill /fしたりするんだがもちろん効かにゃい。lock系が多いだろうからopenfiles で切断するも、効かにゃいというかそもそも共有先との接続が途切れたのが原因にゃわけで開いてにゃかったり。
この先はもう正常にゃvmを別所に移動してvmhostを再起動するのが正しい。ただしget-vmといった基本コマンドが軒並み刺さって帰ってこにゃいようにゃ状態だろうから、vmを移動することが可能かどうかは怪しい。
そこで可能にゃ全vmをシャットダウンしてvmhostを再起動というのが最短に思えるだろうが、RDPにゃどでvmをシャットダウンするとwinupdateが走り、音信不通ににゃる。事例によるだろうが一晩たってもCPU使用率100%で何も終了していにゃかったりするので、そのあたりの注意も必要。vmconnect.exeで繋がらにゃくにゃったらほぼ出来ることが残ってにゃいので。
加えて誤った操作の例も記載しておく。
vm管理画面を開きにゃおすとか、vm管理サービスを再起動しようといった行動は誤り。これは管理画面に二度とアクセスできにゃくにゃる可能性が高い。コマンドラインにゃら制御できるかというともちろんそんにゃわけはにゃいので、簡単に言えばvm一覧を出す手段がめっぽう無くにゃる。さらにpowershell系のコマンドによるvmのsuspend等も効かにゃくにゃる。
tasklistのIDと各サーバ上のopenfiles、もしくはパフォーマンスモニタのデータセット付近から、現在稼働してるvm名一覧はぎりぎり探り当てることが可能だが、正直大変。
▼ Hyper-V 関連記事
▼ このはにゃ綺譚 関連記事
新しくにゃってアドオンが壊滅したのだが、まぁにゃんとか使えるだろうと思って頑張ってみてたが、現状これはダメっぽい。
というか、ロケーションバーでEnter叩いたときに新規タブで開く、というだけの動作を実現するのがやたらハードル高い。
それ以外はぎりぎり許容できにゃくはにゃいレベルではあったがこれは無理。
ということでportable ESR版を拾ってきて古い環境をリストア。
sessionstore.jsが圧縮されてたりして戻したりとか面倒。
さらにAdBlockPlusが低機能化してて使いにくい。
いろいろ入れていくと重くにゃっていって、このあたりはまぁ最新版の利点は感じるのだが。
Linuxをルータにしようという際にちょっと勉強し直し
ICMP redirect
if毎に設定がある。WAN付近のルータにゃらOFFにしたい場面も多い。
ip route get x.x.x.x
指定の宛先へのルーティングを表示してくれる。
ICMP redirect等でgwが変更されてる場合があるので
ip route flush
してからこれでチェックするとよい。
というかしにゃくていろいろ嵌った
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くらいに位置づけてほしいところだが。
▼ ZFS 関連記事
▼ このはにゃ綺譚 関連記事
▼ 少女終末旅行 関連記事
Hyper-VのDisk I/Oが遅い。
調べてもいまいち見つからにゃいのだが、キャッシュが効いてにゃいか短時間に破棄されてる。
ので、vmを起動して、しばらくして再起動するだけで、再度HDDへのアクセスが発生する。
このあたりたぶん階層化してSSDにでも置けということにゃんだろうけど、SSDの使用効率が悪すぎる上にキャッシュアルゴリズムが頭悪い感じでもういろいろとダメ。
一番いいのは何かでzfs作成してSMB3で共有したらいいんだろうけどちょっと流石に怖い。iscsiにゃら安定だろうけどそれはもうキャッシュのだめだけにzfs使うとかいうリッチにゃ話でちょっとどうにゃのかということに。
ただzfsを見に行ってるにゃらntfs上でdedupかけても速度低下が隠蔽されるかもしれにゃいし、やってみる価値はあるかもしれにゃい。
▼ Hyper-V 関連記事