つぶねこ

　気ににゃってはいたんだけど、にゃんか上手いことやってくれるんだろうと放置してたらトラブった。
　各vmのNICに動的MACを指定するとホストで指定した範囲のMACが順に割り振られるんだと思われるんだが、この範囲が00-FFまでしかにゃい。このへんで、大量に作ったり消したりしてると一周してくる。
　それから、これをマイグレーションで他ホストと行き来させたりするとかにゃりの確率で同MACが出現したりする。
　そんにゃわけで、Hyper-Vホスト導入時に初期設定としてMACの範囲を思い切り広げておくと良さそう。
　あとMAC重複のメッセージは運用イベントログに出てるんだが管理画面には出てこにゃいので注意。

　幼先輩萌え

　結構嫌がってる(笑)

　もうヒロインでいいよ

　本当の姫は別の場所で大変にゃことに・・・

　久瑠美ちゃんの困り顔が卑怯

　まって、熊はいいけど茸は何の心理的繋がりが・・・

　今回出番が無いことが確定的に明か

　うわああ今とほぼ変わらん幼萌え

　もうずっとその時代の描写でいいや

　良い展開ぽいけどそれはそうとして座り方萌え

　どっかに有りそうにゃ展開だけど萌え

　うわーい魔法少女プリティーサm・・・

　時間経過してるが1日未満で済んだのか

　良い話しすぎる
　でも困り顔の方がもっと好きです

　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されるにゃら変わらにゃい可能性の方が高いか。