»SambaとZFSで大量のファイルを扱う時はcase-sensitiveの組み合わせを最適化する同一フォルダに大量のファイルがあるとSambaが超遅くなる問題、自分なりの知見が得られたのでメモ。結果だけ知りたい人は最後までスクロールしてくだしあ。おさらいことの発端は、数万個のファイルがあるフォルダをSambaのファイルサーバにコピーすると、速度が10kB/s前後まで低下する現象に見舞われた。速度はコピーが進むごとに低下し、比例してsmbdのCPU占有率が上がるというのが特徴。サーバ上で直接コピーすると何の問題もない。調査を進めると、Sambaはファイル名の重複チェックのため、ファイル作成時に作成先フォルダ内の全ファイル名を検査することが分かった。この時に行われる、ファイル名の大文字/小文字変換と比較処理がボトルネックとなっているようだ。Windowsでは歴史的にファイル名の大文字/小文字を区別しない1)が、UNIX系ではOS/ファイルシステム共に大文字/小文字を区別することが多い。このWindowsとUNIXの違いをSambaで吸収してやる必要があるわけだ。sensitiveをyesにせよ」(抄訳)と書かれており、ファイルコピーの進捗にあわせ指数関数的に速度が落ちる(CPU負荷が上がる)という挙動から、当たらずとも遠からずだと思う。yesにすれば万事解決かといえば、そう簡単な話ではない。前述の通りWindowsはFS的にはcase-sensitiveないしcase-preservingだが、表面的にはcase-insensitiveとして振る舞う。この仕様に胡坐をかき、ファイルパスを内部的に大文字または小文字に変換して扱うアプリケーションが少なくない。本来のファイルパスはC:\Data\FILE.datにもかかわらず、アプリケーション内部ではc:\data\file.datとして扱うことが往々にある。(自分もそういう処理をつい書いちゃうんだけど(;'∀'))。ローカルのファイルに対してなら、Windowsがよしなに取り計らってくれるので問題にはならない。共有フォルダのアクセスに関しては、忖度することなくリクエストされたファイルパスをそのままサーバに渡しているようだ。ゆえにサーバ側でそのあたりが考慮されてないと、意図したファイルが見つからないという事になる。sensitiveオプションは、まさにその辺の制御に関するオプションなのだ。sensitive=yesにするということは、\\Server\Data\FILE.datと\\Server\data\file.datは別のファイル扱いになるということで、手抜きアプリからすれば、case-insensitiveなら見えていたファイルが見つからなくなる。これでは使い物にならない2)ではどうするかそこでZFSのcasesensitivityプロパティの登場だ。その名の通り、ファイル名の大文字/小文字の取り扱いに関するプロパティで、デフォルト値はcasesensitiveである。これをcaseinsensitiveにしてやれば、大文字/小文字を区別しないようにファイルシステムが処理するようになる。“insensitive”とはなっているけど、挙動としては“preserving”のようだ。ちなみに、mixedというのもあるが、使いどころがよくわからない挙動なので指定しない方が無難(一応、Windowsを想定した挙動らしいんだけど...)。残念ながら、というか性質を考えたら仕方ないけど、本プロパティはFS作成時にしか指定できない。問題が起きてしまっている場合は、caseinsensitiveなFSを新たに作り、casesensitiveなFSの方からファイルコピーして移行するしかない。send/recvではプロパティが引き継がれるので意味がない。sensitive=yesとしてやれば、smbdの負荷問題は解決する。Sambaがファイル作成時にファイル名を全舐めしてしているのは、対象フォルダに対する変更をSamba側で検知する術がないからだと思われる。Sambaがファイルを作成しようとしたまさにその時、同名のファイルがサーバのローカルで作られたりする可能性があるから、キャッシュではファイル名のユニーク性を担保できず、都度確認せざるを得ないのだろう。してはSambaとZFSで以下の設定を行うと幸せになれる。no1)ファイルシステム上は区別して保存されている。Tags:FreeBSDPCSambaTipsZFSCommentsNameE-MailWebsite人間の証明として、ボックス内の全ての文字を入力してください。Decomoソースの表示以前のリビジョンメディアマネージャー文書の先頭へ。