差分

このページの2つのバージョン間の差分を表示します。

--- blog:2018:2018-07-03 [2018-07-03 11:55]
Decomo
+++ blog:2018:2018-07-03 [2018-07-17 11:49]
Decomo
@@ 行 1: / 行 1: @@
-====== ZFSとSambaで大量のファイルを扱う時はcase-sensitiveの組み合わせを最適化する ======
+====== SambaとZFSで大量のファイルを扱う時はcase-sensitiveの組み合わせを最適化する ======
-同一フォルダに大量のファイルがあるとSambaが超遅くなる問題、自分なりの知見が得られたのでメモ。結果だけ知りたい人は最後までスクロールしてくだしあ。
+[[blog:2017:2017-08-04|同一フォルダに大量のファイルがあるとSambaが超遅くなる]]問題、自分なりの知見が得られたのでメモ。結果だけ知りたい人は最後までスクロールしてくだしあ。
 まずはおさらい。
-ことの発端は、数万個のファイルがあるフォルダをSambaのファイルサーバにコピーすると、速度が10kB/s前後まで低下する現象に見舞われた。速度はコピーが進むごとに低下し、比例するようにsmbdのCPU占有率が上がるというのが特徴。ファイルサーバ上で直接コピーすると何の問題もない。
+ことの発端は、数万個のファイルがあるフォルダをSambaのファイルサーバにコピーすると、速度が10kB/s前後まで低下する現象に見舞われた。速度はコピーが進むごとに低下し、比例してsmbdのCPU占有率が上がるというのが特徴。サーバ上で直接コピーすると何の問題もない。
-調べてみると、Sambaはファイル作成時、ファイル名の重複チェックのため作成先フォルダ内の全ファイル名を検査することが分かった。この時に行われる、Windowsのファイル名規則（FS上は大文字小文字を区別するが、OSの表面上は区別しないナンチャッテcase-preserving。この差はOSが吸収する。）と合わせるための、ファイル名を大文字ないし小文字に変換する処理がボトルネックのようだ。
+調査を進めると、ファイル作成時Sambaはファイル名の重複チェックのため、作成先フォルダ内の全ファイル名を検査することが分かった。この時に行われるWindowsのファイル名規則（FS上は大文字/小文字を区別するが、一般的なファイルアクセス上は区別しないナンチャッテcase-preserving。この差はOSが吸収する。）と合わせるための、ファイル名を大文字ないし小文字に変換する処理がボトルネックのようだ。
 プロファイルしたわけでもソースコードを見たわけでもないので確証はないが、公式ドキュメントに「ディレクトリに大量のファイルがある特殊なケースでは、case sensitiveをyesにせよ」(抄訳)と書かれており、ファイルコピーの進捗にあわせ指数関数的に速度が落ちる（CPU負荷が上がる）という挙動から、たぶん当たってると思う。
-''case sensitive = yes''にすれば万事解決かと思えば、そうじゃない罠。
+では''case sensitive = yes''にすれば万事解決かといえば、そうじゃない罠。
-前述の通りWindowsはFS的にはcase-sensitiveだが、歴史的理由で表面上はcase-insensitiveとして振る舞う。この仕様に胡坐をかき、ファイルパスを全部大文字or小文字に変換して扱うアプリケーションが少なくない。つまり、本来のファイルパスは''\\Server\FILE.dat''にもかかわらず、アプリケーション内部では
+前述の通りWindowsはFS的にはcase-sensitiveだが、歴史的理由で表面的にはcase-insensitiveとして振る舞う。この仕様に胡坐をかき、ファイルパスを内部的に大文字or小文字に変換して扱うアプリケーションが少なくない。例えば、本来のファイルパスは''C:\Data\FILE.dat''にもかかわらず、アプリケーション内部では
-''\\server\file.dat''としてアクセスしていることが往々にしてある<fc #c0c0c0>（自分もそういう処理をよく書く(;'∀')）</fc>。
+''c:\data\file.dat''としてアクセスすることが往々にある<fc #c0c0c0>（自分もそういう処理をつい書いちゃうんだけど(;'∀')）</fc>。ローカルのファイルに対してなら、これでも問題はない。
-で、ローカルのファイルシステムに対してならWindowsがよしなに取り計らってくれるのだが、サーバの共有フォルダに対しては何の処理も行わず、アプリから渡されたファイルパスをそのまま渡しているようだ。アプリが''\\server\file.dat''を指定したなら、Sambaにも''\\server\file.dat''が渡ってくる。この時、''case sensitive''オプションがautoかnoならSambaが処理して無事''\\Server\FILE.dat''とマッチするが、yesの場合は…Ω＼ζ°)ﾁｰﾝ
+しかし、サーバの共有フォルダに対しては、アプリから渡されたファイルパスをそのまま渡しているようだ。故にサーバ側がその辺を考慮した処理になってないと、ファイルが見つからないという事になる。Sambaの''case sensitive''オプションは、まさにその辺の制御を設定するオプションなのだ。これをyesにするということは、\\Server\Data\FILE.datと\\Server\data\file.datは別のファイルと見なされる、ということだ。アプリからすれば、\\Server\Data\FILE.datが見つからないということになる。これでは使い物にならない。
-では、この差をどこで吸収させるかと言ったら、もうファイルシステムしかない。
+ではどうするか。ZFSの''casesensitivity''プロパティの登場だ。
-幸いにしてZFSには''casesensitivity''という、その名の通りのプロパティが用意されている。デフォルト値は言うまでもなく''casesensitive''である。
+お察しの通りその名の通りのプロパティで、デフォルト値は''casesensitive''である。これを''caseinsensitive''にしてやればいい。insensitiveという名付けではあるが、挙動としてはpreservingのようだ。ちなみに、''mixed''というのもあるが、使いどころがよくわからない挙動なので指定しない方が無難（一応、Windowsを想定した挙動らしいんだけど…）。
-Windowsとの共有は''caseinsensitive''なFSを新たに作って行うのが良いだろう。設定値はcaseinsensitiveだが、挙動としてはcase-preservingになるようだ。ちなみに、''mixed''は使いどころがよくわからない挙動になるので使わない方が無難（一応、Windowsを想定した挙動らしいんだけど…）。
+本プロパティはFS作成時にしか指定できないため、Windows共有用のFSを新規に作り、Sambaで共有フォルダに仕立て上げるのがよいだろう。
-そもそもSambaがファイル名をキャッシュせずファイル作成毎に全舐めしてしているのは、恐らく対象フォルダに対する変更をSamba側で検知する仕組みがないからだと思う。Sambaがファイルを作成しようとしたまさにその時、同名のファイルがサーバのローカルで作られたり、別のファイルがリネームされたりする可能性があるため、キャッシュではファイル名のユニーク性を担保できないという判断だと思われる。
+Sambaがファイル名をキャッシュせずファイル作成毎に全舐めしてしているのは、恐らく対象フォルダに対する変更をSamba側で検知する仕組みがないからだと思う。Sambaがファイルを作成しようとしたまさにその時、同名のファイルがサーバのローカルで作られたり、別のファイルがリネームされたりする可能性があるため、キャッシュではファイル名のユニーク性を担保できないのだろう。
 一方、ファイルシステムレベルなら、そのような変更の検出とアトミック性・ユニーク性が保証された素敵な仕組みがあるハズだから、アプリ側でファイル名の全比較を行うより効率的なんじゃねっていう目論見。