英語勉強のために宮崎駿作品集の北米版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は一体何を考えとるのかね！？

同一フォルダに大量のファイルがあるとSambaが超遅くなる問題、自分なりの知見が得られたのでメモ。結果だけ知りたい人は最後までスクロールしてくだしあ。

ことの発端は、数万個のファイルがあるフォルダをSambaのファイルサーバにコピーすると、速度が10kB/s前後まで低下する現象に見舞われた。速度はコピーが進むごとに低下し、比例してsmbdのCPU占有率が上がるというのが特徴。サーバ上で直接コピーすると何の問題もない。

調査を進めると、Sambaはファイル名の重複チェックのため、ファイル作成時に作成先フォルダ内の全ファイル名を検査することが分かった。この時に行われる、ファイル名の大文字／小文字変換と比較処理がボトルネックとなっているようだ。Windowsでは歴史的にファイル名の大文字／小文字を区別しない¹⁾が、UNIX系ではOS／ファイルシステム共に大文字／小文字を区別することが多い。このWindowsとUNIXの違いをSambaで吸収してやる必要があるわけだ。

プロファイルしたわけでもソースコードを見たわけでもないので確証はないが、Sambaのドキュメントに「ディレクトリに大量のファイルがある特殊なケースでは、case sensitiveをyesにせよ」(抄訳)と書かれており、ファイルコピーの進捗にあわせ指数関数的に速度が落ちる（CPU負荷が上がる）という挙動から、当たらずとも遠からずだと思う。

ではcase sensitive = yesにすれば万事解決かといえば、そう簡単な話ではない。

前述の通りWindowsはFS的にはcase-sensitiveないしcase-preservingだが、表面的にはcase-insensitiveとして振る舞う。この仕様に胡坐をかき、ファイルパスを内部的に大文字または小文字に変換して扱うアプリケーションが少なくない。例えば、本来のファイルパスはC:\Data\FILE.datにもかかわらず、アプリケーション内部ではc:\data\file.datとして扱うことが往々にある。（自分もそういう処理をつい書いちゃうんだけど(;'∀')）。

ローカルのファイルに対してなら、Windowsがよしなに取り計らってくれるので問題にはならない。

しかし、共有フォルダのアクセスに関しては、忖度することなくリクエストされたファイルパスをそのままサーバに渡しているようだ。ゆえにサーバ側でそのあたりが考慮されてないと、意図したファイルが見つからないという事になる。Sambaのcase sensitiveオプションは、まさにその辺の制御に関するオプションなのだ。

case sensitive=yesにするということは、\\Server\Data\FILE.datと\\Server\data\file.datは別のファイル扱いになるということで、手抜きアプリからすれば、case-insensitiveなら見えていたファイルが見つからなくなる。これでは使い物にならない²⁾

そこでZFSのcasesensitivityプロパティの登場だ。

その名の通り、ファイル名の大文字／小文字の取り扱いに関するプロパティで、デフォルト値はcasesensitiveである。

これをcaseinsensitiveにしてやれば、大文字／小文字を区別しないようにファイルシステムが処理するようになる。“insensitive”とはなっているけど、挙動としては“preserving”のようだ。ちなみに、mixedというのもあるが、使いどころがよくわからない挙動なので指定しない方が無難（一応、Windowsを想定した挙動らしいんだけど…）。

残念ながら、というか性質を考えたら仕方ないけど、本プロパティはデータセット作成時にしか指定できない。既に問題が起きてしまっている場合は、caseinsensitiveなデータセットを新たに作り、casesensitiveの方からファイルコピーで移行するしかない。（zfs send/recvではプロパティが引き継がれるので意味がない。）

そのうえでSamba側のcase sensitive=yesとしてやれば、smbdの負荷問題は解決する。

Sambaがファイル作成時にファイル名を全舐めしてしているのは、対象フォルダに対する変更をSamba側で検知する術がないからだと思われる。Sambaがファイルを作成しようとしたまさにその時、同名のファイルがサーバのローカルで作られたりする可能性があるから、キャッシュではファイル名のユニーク性を担保できず、都度確認せざるを得ないのだろう。

一方、ファイルシステムレベルなら、ファイル名の一意性やアトミック性の保証が効率的に行えているだろうという目論見。

結論としてはSambaとZFSで以下の設定を行うと幸せになれる。ZFSじゃない人はスマン…

• ZFS
  • ファイル共有用にcasesensitivity=caseinsensitiveなFSを作る

    zfs create -o casesnsitivity=caseinsensitive ztank/path/to/cifs

• Samba
  • ファイル名の扱いをcase-sensitiveにする

    case sensitive = yes
    case preserve = yes
    short preserve case = yes

• smb.conf — The configuration file for the Samba suiteのNAME MANGLINGセクション