現在自分は実家でのうのうと暮らしているわけですが、誰も階段を下りていないのにもかかわらず、誰かが降りてきたような足音と気配がすると母親がよく言うのです（たまに父親と母親両方もある）。「さっき降りてきた？」と訪ねられるのですが、自分はずっと部屋にこもっていた、と言うことが何度か有りました。妹が2匹いるのですが、それらも当然動いていないというのです。

　階段を降りる際の最初の一段を踏み出すときに、荷重を右足から左足へ変えるときによくきしむ事があるので、自分はずっと自然現象の勘違いだと思っていました。ですが、母親の話によるときしむ音だけではなく足音も聞こえるそうです。

　また、この家には和室があるのですが、妹2（次女）がまだ幼いときにそこで大泣きしたことが何度か有るらしく、そのことを妹1（長女）に訪ねると「黒い棒があったって言って泣いてた」と答えたそうです。当然、もう両方ともこの事について何も覚えていないそうですが。

　何なんでしょうね。つかれてる（いろんな意味で）のでしょうか。自分は全くそっちの気はないので、妖怪鍵隠しやスマホ隠しやドライバ隠しや財布隠しに物を隠されることくらいしか有りませんが、気がついていないだけで何か不可思議なことが起きているのかもしれません。

　プロジェクトで色々手が回らなくなってくるとプロジェクト内に人を増やそうとする訳ですが、人が増えるとそれだけ何かを訪ねようとしたときに経由するホップ数も増えます。自分は出来るだけ人とのコミュニケーションを取らず、粛々と作業をしたいタイプの人間なので、この問題は非常にめんどくさいのです。

　作業Aの確認をするために上長Aに聞き、上長AがチームBの上長に聞き、チームBの上長が実際に作業した作業者Aへとネゴシエーションを取り、やっと自分と作業者Aとのコミュニケーションを取れる、と言うルーティングを経由しないといけないのですが、一々メールのCCにあの人この人を入れて送信して…というのがもう煩わしい。一々言葉遣いなども気にする必要があるので更に煩わしい。

　このため、どうしても自分で分かりそうなところはやってしまおうとするのですが、カオス最盛期のプロジェクトのドキュメント管理なんてちょろっと入った人間から分かるはずもなく、あそこかここかと探っているうちにハマってしまう、というのがよくあります。ネットワークドライブからドキュメント全て持ってきてGoogle検索アプライアンスにぶち込みたい気分です。使ったことありませんが。
　しかし、ここでハマっても前述の人間のネゴシエーションするのめんどくさい（と言うか気力が要る）病にかかっているのでデッドロックに近い状態になるのです。運良くドキュメントを見つけられたとしても、非常に時間がかかってしまうという。

　そんなことを、某女に「何でも自分で片付けようとするのはやめた方が良い、人間それほど万能じゃない。分からなかった時点で聞くべき」と言われてふと内省しました。しかしあの人は一体どんな戦場を駆けてきたのだろうかと言うレベルの強さ…ただひれ伏すのみです。


　ITと言えば電子なイメージがありますが、ITこそ人間とのアナログ通信というどうしようもない結論に行き着きます。まあ、認識合わせとか言う何かで1時間2時間も話あってるだけで仕事したつもりになってるのは日本だけらしいですけどね。
　「認識合わせ」については以下が詳しいです。
http://glossary.tank.jp/t0E75.html
　別件で議論しているときの「そういえばアレどうなった」は本当にやめていただきたい。

　やー、ゴミな環境にいると吐き出すゴミの量も増えますね。

某所の何かで起きた問題。

某所の何かではVM基幹にVMwareを使用しているのですが、VMwareのファイルシステム（データを保存する方法）としてVMFS3とVMFS5と言う物があります。

概要だけ言うとVMFS3はデータストアに対する割り当て可能ディスクサイズが2Tまでで、3Tとかのディスクを割り当てても2Tまでしか使われません。また、2Tのディスクを最大32個のディスクを割り当てられ、合計64TBまでのデータストアを作れます。

　VMFS5は割り当て可能なディスクサイズが64TBまで拡張されました。ただし、データストアの合計最大値は64TBまでのままです。しかしながら、割り当てる方法としては64TBのでかいディスクを作成するか、32Tx2にするか、今までと同じように2x32で作るか…などの選択が出来るようになりました。VMFS5はESXi4以降であればそのまま利用することが出来、ESXi5に関してはデフォルトでVMFS5を利用します。

　そんな中、実績が云々という理由でVMFS5がつかえる中、あえてVMFS3を使っている場所がありました。普段2TBと言う容量はそう使い切る容量ではないのですが、色々なバックアップで使用すると2TBでは足りず、8TBへ拡張する必要が出てしまいました。
　どう拡張するかというと、前述のLVMを利用し、2TBのLUNを4つ作り、それをRDMでVMに割り当て、LVにまとめ2Tx4=8TBという容量にするという算段でした。この段階ですでに何かがおかしいと思いますが、どうやらこの方法で行くことになったようです。

　しかし、ただこれだけの作業であっても何か問題が起きるのがどこかのクオリティーで、どういう訳だか4TのLUNを作成し、起動できないVMが出来上がったようです。意味が分からない。その確認を依頼されたわけですが、そもそもどうやったらそのゴミが作れるのか？と言うのが疑問だったので自宅の環境で試してみました。

　まずは、同じ環境であるESXi5u1をインストールし、targetcliからiscsiポータルを作成し、2TのLUNを2つと3TBのLUNをzfs create -Vでメインストレージから切り出しました。詳しい方法は表のブログではないので省きます。

　


　某所のポリシーとしてはRDM(Raw device mapping)という方式でLUNをマウントしているのですが、そもそもVMFS3で2TB以上のLUNを割り振れるか試してみたところ、以下のようにRDMであっても2TBまでしか認識できません。と言うかそもそもあの構成ではRDM使う理由がないんですが…。

　


　そこで、データストアに2TBのLUNを2つ割り当て、4TBのデータストアを作成し、vmdkで割り当ててみます。




　ここから、VMの構成を変更し3TBのVMDKを作成しようとしたところ、以下のような警告が出ました。




　まあですよね。

　あれこれ考えたところ、先に2TB以下のRDMを作成し、その後無理矢理ディスクサイズを拡張したらどうか？という疑問が湧いたので試してみました。




　この3TBのLUNをサイズ変更します。
#zfs set san/rdm volsize=100G

　このコマンドを実行後、再度ストレージのスキャンを行います。




　すると、指定した100GにLUNがリサイズされています。
　その後、そのLUNをRDMでマウントします。この段階では矛盾がないので、当然エラーなどは起きず正常にマウントされます。データストアを見てみると、100Gのvmdkファイル（中身はRDMへのリダイレクト）が出来上がっています。




　正しくデータが見えることを確認後、認識したLUNのサイズを拡張します。

#zfs set san/rdm volsize=3T

　再度データストアのスキャンし、対象のディスクのサイズが3TBに拡張されていることを確認します。




　その後、データストアを見ると、先ほどの100GのLUNが3TBに拡張されています。制限を超えたので表示がおかしいです。




　その状態で構成変更をせず、VMの電源を入れます。VMなのに電源を入れるという言い方も変ですが。
　すると…





　おめでとうございます！電源の立ち上がらない立派なゴミが出来上がりました！！！

　…どうしてこう普通は警告に引っかかるところを、わざわざ引っかからない裏道ルートですり抜けて自爆するんでしょうか、某所は…。検証途中で「マジどうやったらこの4Tのゴミを作れるんだ…」と何度も悩んだので、このゴミが出来上がったときは「やったー！うごいたー！」と言ってしまいましたが、結果的に出来上がったのはゴミなのでうごいてないですね。

　言われている前提としては「4TのLUNは消して良い」との事ですが、この方法だと「以前割り当てられていた」LUNを拡張することになるので、本当に消して良いのか、以前何かに使っていなかったのか、と言うのが不安です。仮に、どこかのLVに割り当てられていたとしたら、それを消した瞬間…。しかし、出来上がってしまったゴミの中身確認するにはVMFS5へ変換するか、VMFS5で作成したVMからこのLUNをマウントする必要があるのです。しかしどちらも無いので、もう知りません。VMFS5で本番環境VMサーバにマウントするためだけのマシンを作ればいいのかもしれませんが、申請とか凄くしんどいのでやりたくないですし、もう自分の担当範囲ではないです。




　この「VMFS5へアップグレード」を押せばそれだけで終わるのですが、ここを押すにはまたあれこれしないといけないので、すぐそこにありながら誰もさわれない、近くて遙かに遠いボタンなのです。

　ほんと、3歩進んで5歩戻りその先で地雷を踏んで足を吹っ飛ばしているような感じです。ああ、不毛すぎる…

―クソみたいなアフィブログだ！

何か商品で悩んでいるときに、その使用感やベンチマークなどを載せず、「～が発売されるようです（されました）」とだけ記述し、また、深い考察などもせず、大手メディアのコピーのみのゴミ情報を見つけると本当にイライラしますね。そんなゴミ情報/dev/nullにでも書いておけクソがっっっ

今年から新しいプロジェクトに出向しているのだけど、この先がいろいろとひどい。

例を上げると、ハードディスクの記憶域管理方法にLVMという歴史のある技術があり、これを利用することにより柔軟にデータ域を管理することができるんですよ。データ域が足りないならディスクを足せばいいじゃない、的な。

普通、データ域が足りなくなった場合の拡張方法としてだいたいどちらかのパターンで拡張します。

□=物理記憶域
■=OSから見える論理領域（合計は物理記憶域を全てたしたサイズ）
横列が別のディスクを指し、縦列がパーティションをさします。

パターン1
ストレージサーバーなどに接続していてディスクサイズが拡張可能の場合、割り当ててるディスクサイズの大きさを増やし、増えた分を新しくパーティションとして割り当てる

■
＿
□
□
＋
□

パターン2
新しくディスクを割り当てる

　■
＿＿＿
□＋□
□

普通はこのどちらかでどうにかします。大体は後者かなと思うのですが…
さて、わかる人はわかると思いますが、パターン1は制限があります。そう、BIOSの制限からくる、物理パーティションの最大数制限です。物理パーティションは最大4つまでなのです。

つまり、パターン1の場合、既にパーティションが4つある場合、ディスクサイズを拡張しても使えません。

■
＿
□
□
□
□
＋
※

※=未割り当て領域

LVMに関していえば、一度fdiskからパーティション情報を消し、拡張済みのサイズで定義し直せばデータを消さずに拡張しなおすことはできます。イメージとしては最後の□を消し、※と合体して縦に二つくっついた長方形として定義するようなものです。記号がないですが。

まあ、そういう方法があるにはあるのですが、その方法を知ってなお作業責任を取りたくないからなのか知らないからなのかは不明ですが、最終的には以下のようなりました。

　■
＿＿＿
□＋□
□
□
□
※

※は犠牲になったのだ…事前確認漏れのな…

過去に何度か拡張作業があったらしいのだけど、この拡張方法もサーバーによってパターン1だったりパターン2だったりしたので、もうカオス…


そして、このあとディスクを拡張したことにより、バックアップに必要な領域が増えてバックアップ先があふれることになるとは、誰も気がつかなかった…


いやー面白いですね、この業界は！！！！！！



はーさっさと別のところ行きたいです。