Emacs上でソースコードのコンパイルを行うにはM-x compileコマンドを使う。するとmakeが走り、結果がCompilatinバッファに表示され、M-x next-errorなどでエラー行に一発ジャンプ出来て超便利ッ……という所までは良く語られる。が、しかーし、肝心のMakefileの指定方法に触れている解説が少ない。

実際のところ、M-x compileのmakeの引数指定のところで書いてやればいいのだが、カレントパスや取り掛かっているプロジェクトごとにアレコレ考えてMakefileを指定するのは現実的ではない。それする位なら、Compilationの利点を捨て、ターミナルのコマンドヒストリーでコンパイルした方がよっぽどマシである。たいてい、Makefileはソースフォルダのトップなりに置くので、編集中のファイルから上に辿り、見つかったMakefileでmakeしてくれれば済む話。

で、ようやくそれを実現する方法を見つけた。Recursively go up to find Makefile and compileに載ってるelispを使う。万が一消えた時用に転載。

(defun desperately-compile ()
  "Traveling up the path, find a Makefile and `compile'."
  (interactive)
  (when (locate-dominating-file default-directory "Makefile")
  (with-temp-buffer
    (cd (locate-dominating-file default-directory "Makefile"))
    (compile "make -k"))))
 
; C-x mでMakefileを探してコンパイル
(global-set-key (kbd "C-x m") 'desperately-compile)

上記サイトの回答に書いてあることだが、指定ファイルが見つかるまでディレクトリを遡って検索する打って付けのlocate-dominating-fileなる関数があるそうで。今回の用途だけではなく、様々な場面で役に立ちそう。

英語勉強のために宮崎駿作品集の北米版Blu-ray BOX「The Collected Works of Hayao Miyazaki」を買おうとしてるんだけど、どうも大量の海賊版が出回っているようだ。eBayは元よりメルカリやAmazon.co.jpでも“未開封新品”が販売されている。

正規品は2015年11月17日発売で、Amazon.com専売商品として希望小売価格249.99ドルで販売されていたらしい。当然ながら既に在庫はなく、日本国内から北米正規品を買うのはかなり困難だと思われる。2018年9月現在、12000円前後で新品未開封として販売されているものは、全て偽物と考えてよいだろう。

redditや解説動画によれば偽物の見分け方は結構簡単で、以下の部分に着目すれば良いそうだ。

1. パッケージを囲んでいる映画フィルム装飾が宮崎監督キャラ（ブタのやつ）に被っていたら偽物
   • 本物はTHE COLLECTED〜の題字の真下に来るようになっている。
2. 未開封パッケージ裏面に同フィルム装飾が見えたら偽物
   • 本物はボックスカバー紙（CDの帯カバー的なやつ）の下を通ってるので、見えるはずがない。
3. 内側のディスク収納ケースが外側ボックスの中央に格納されていたら偽物
   • 本物はブックレットの厚みの分、左寄りになっている。
4. 偽物はディスクの収納が雑。ディスク保護のビニールがはみ出している。
   • 本物はきちんとケース内に収まっている。

他にもシュリンクラップ（商品を覆ってるビニール）の形状が違うとか印刷物の色味が違うとかあるみたいだが、上記の特徴がわかれば十分かと。文字で説明すると何のこっちゃだが、映像を見れば一目瞭然なので、上記サイトの一読をオススメします。

ジブリの北米版Blu-rayは正規版が単品16ドル程で買えるので、微妙な値段で海賊版を掴まされないように気をつけよう！

• Beware of "The Collected Works of Hayao Miyazaki" Pirate Bootlegs! (Comparison of legit boxset vs. bootleg boxset) : ghibli
• The collected works of Hayao Miyazaki. Real VS Fake - YouTube
• THE COLLECTED WORKS OF HAYAO MIYAZAKI Blu-Ray Review | Nerdist

Windowsの記憶域階層について調べてたら、MSの中の人が書いたUnderstand Storage Space Tiering in Windows Server 2012 R2がとても分かりやすかった。Windows Server 2000 R2時代のものだけど、今でも通じる内容でしょう多分。記憶域階層使おうとしてる人は一読しといた方がいいと思う。

元記事の焼き直しでしかないが、気になったことをメモっておく。

• 記憶域階層に入ってくるデータは、まずはSSD層に満杯になるまで書き込まれる。
• SSD層が満杯になると、ランダムライトはSSD層内に予め確保されているライトバックキャッシュの方に書き込まれる。
• ライトバックキャッシュも一杯になると、HDD層の方に書き込まれると共にライトバックキャッシュのHDD層へのフラッシュが行われる。
• ライトバックキャッシュが空けば、ランダムライトは再びキャッシュの方に書き込まれる。

ここでのライトバックキャッシュとは、記憶域階層が持っている機能を指している。仮想ディスク毎にSSD層に確保される領域で、標準では1GBだがNew-VirtualDiskコマンドレットの引数-WriteCacheSizeで任意の容量を指定できる。前述の通り、SSD層が埋まらないとライトバックキャッシュは使われないため、あまり大きな領域を確保しても無駄だと思われる。

自分はてっきり、ライトバックキャッシュという名前の通り、その領域分が書き込み全般のキャッシュとして使われると思っていた。Crystal Disk Markでキャッシュサイズを超えるテストサイズでベンチ回しても速度が全く落ちずに不思議だったが、なるほどSSD層全体がキャッシュとして使われてたとはね。

読み込みの方は明確な説明がないので間違ってるかも…。

• SSD層にあるデータはSSD層から読まれる。
• SSD層にないデータはHDD層から読まれる。
• 毎日の記憶域階層最適化によりSSD層とHDD層でデータの入れ替えが行われ、よく使われるデータはサブファイル単位でSSD層に配置される。

自分はZFSしか知らんのでZFSとの比較になっちゃうけど、読み込みキャッシュの方は割と慎ましい挙動のように思う。記憶域階層最適化のサブファイル単位というのは、1MBブロック単位らしい。

これらの挙動から分かる通り、記憶域階層ではSSD層が酷使されるため、相応のSSDと相応のデータ保護手段を用いた運用にしないとトラブりそう。SSD層が死んだ場合に、記憶域スペース/仮想ディスクがどうなるかは未確認＆情報がない…。仕組み的にはSSD層にあるデータが死ぬだけで済みそうに思うんだけど、どうだかなー。現状、一旦記憶域階層として作ったが最後、後からSSD層を取り外す事もできないしなー。

• Understand Storage Space Tiering in Windows Server 2012 R2 – Larryexchange Blog
• The Effects Of WS2012 R2 Storage Spaces Write-Back Cache | Aidan Finn, IT Pro

Windows Storage Server 2016の記憶域階層から切り出したNTFSボリューム上に、CIFSで共有フォルダを作って別マシンからファイルを書き込むと、途中で処理が止まったようになり、当該フォルダを開くのですら超絶時間が掛かるようになる問題に遭遇中。なんとなく、SSD層が一杯になったタイミングで発生してるような気がするけど、有効な解決策は未だ見つけられず…。

記憶域階層は以下のような構成。

• SSD層
  • Intel DC S3500 240GB×2 (RAID-0。記憶域に割り当ててるのは160GBほど）
• HDD層
  • 8TB 7200RPM SATA×6（RAID-10。HDD×2のミラーリングが3セット。CMRなHDD）
• 記憶域プール全体を1ドライブに割り当てNTFSでフォーマット

いずれもRAIDカードで仮想ドライブになってるので、記憶域からはSSDとHDDが1台ずつ見えてる感じ（ま、この構成自体がそもそも非推奨なんだけど。）

そこに1KB～4GBの96ファイル計25.2GBをコピーすると、最初は順調なのに途中でパタリと処理が止まる。タスクマネージャを見ると「記憶域階層管理」なるものが動いているので、おそらくSSDが一杯になってHDDへのデータ移動が行われているのだろう。

でもって、リソースモニタでディスクの状態を見てみると、処理対象のファイルの応答時間がなんと1000ミリ秒を超えているじゃーありませんか。キューもめっちゃ溜まってるし（順調に処理が行われてる時は1未満。多くても3～4ってとこ。）データ移動待ちにしては、流石にレイテンシ長すぎじゃないですかね…。

実際の操作感としては、SSDに一定の空きができるまでファイルI/Oがブロックされてるような感じ。MSの中の人によれば、SSD層が一杯になるとIOPSが劇的に下がる──といってもHDD層相当の性能は出るんだけど(記事中のTest Case 1: Write to Used Storage Spaceらへん)、処理が完全に止まってしまうような感じにはならなさそう。

ネットに上がってる記憶域階層の使用例は殆どがHyper-Vがらみなので、ファイルサーバ向けに記憶域階層を使うってのがそもそもの間違いなのかしら？そうは言っても、使用頻度の高いデータをSSD層において高速化するって使い方はファイルサーバでもふつーにありそうな感じがするんだけどなぁ…。

Sambaだと大量のファイルの扱いに難あり、ってところからCIFSの純正実装なら安心だろうってことでWindows Serverを選択したのに、トホホですよ本当。僕たちの調査の旅はこれからだ…！

(2018-08-16 追記)

何の役にも立たないと（僕の中で）名高いMSKKのフォーラムに同様の報告があった→記憶域スペースで階層化構築時における急激なパフォーマンス低下について。いつものごとく箸にも棒にもかからない回答で乾いた笑いしか出ないわけですが。

https://h50146.www5.hpe.com/products/servers/proliant/essentials/ilo4/mo.htmlにiLO 4の分かりやすい機能比較表があったんだけど、リニューアル？でページがなくなってしまったのでスクショをうｐ。標準機能、iLO Essentials、iLO Advancedの比較表だよん。

気が向いたらStandard込みの表を作るかも…。StandardはPDFを読み解かないといけないのでちょい面倒なのよね。

それにしても、ネット上のHP/HPEへのリンク情報がほとんど使い物にならなくなっててつらたん。草の根情報って結構重要だと思うんだけど、HPEは一体何を考えとるのかね！？