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セクション

通常、EmacsでTAB補完の時とかに表示されるCompletionsバッファは、フレーム³⁾下部を分割した一時的なウィンドウ⁴⁾として表示される。言葉じゃわかりにくいので、スクショを張っとくと↓こんな感じね。

自分のEmacsの使い方は垂直分割した2つのウィンドウ表示が基本で、Completionsバッファは非アクティブな方のウィンドウに出て欲しい。その方が補完候補の一覧性が圧倒的だし、ウィンドウがパカパカしないのがいい。スクショを張（ｒｙ

ここの回答に載ってるelispを参考に、ウィンドウが1つの時はウィンドウ幅に応じて分割方向を変えるようにしてみた。

(defun display-on-side (buffer &optional not-this-window frame)
  (let* ((window (or (minibuffer-selected-window)
                     (selected-window)))
         (display-buffer-function nil)
         (pop-up-windows nil))
    (with-selected-window (or window (error "display-on-side"))
      (when (one-window-p t)
        (if (> (window-pixel-width) (window-pixel-height))
            (split-window-horizontally)
          (split-window-vertically))
        )
      (display-buffer buffer not-this-window frame))))
(setq display-buffer-function 'display-on-side)

水平2分割した状態で使うと、非アクティブなウィンドウの方がCompletions表示時に勝手にリサイズされる問題があったりする…。自分は水平分割使わないので放置してます、すいません。えらいひと直して教えてください。

• emacs - Display compilation in inactive buffer - Stack Overflow
• How to force completions buffer to appear in a side window? - Emacs Stack Exchange
• Window Sizes - GNU Emacs Lisp Reference Manual

ネットギアのL2スイッチのLAG設定に「Admin Mode」なる項目がある。下図はXS512EMのWebGUIのもの。

LAGの管理モードの有効無効って何よ？と思い、WebGUIのヘルプを見るも“Admin Mode - Select Enable or Disable to set the Admin Mode.”としか書いておらず、全く役に立たないという…。いろいろググってみて、確実な情報は見つけられなかったんだけど、結局のところLAGのオン/オフを切り替える設定っぽい。言わずもがな、EnableがLAG有効でDisableが無効ね。

機種違いの回答ではあるが、公式フォーラムでは、Enableだとトラフィックが流れてDisableだと全く流れないとされているが、少なくともXS512EMに関してはLAG自体の有効/無効にしか影響してなさそうだ。実際試しても、Admin Modeの状態を問わずパケットは流れる一方、LAGを設定済みの状態でDisableならLAG StatsuはDownのまま、Enableにして初めてUpになった。

フォーラム回答の挙動は、マネージドスイッチ以上で設定できるポート毎のAdmin Modeの解説なんじゃないかって気がする。いずれにせよ、もっと分かりやすい項目名にしてくださいよとしか……

• What is the use of the "admin" settings in LAG con... - NETGEAR Communities