2.5インチSATA HDD/SDDを3.5インチ相当のネジ穴、コネクタ位置に変換するセンチュリーのマウンタCRIN2535は15mm厚の2.5インチHDDでも問題なく使える。公式には12.5mmまでの対応となっているが余裕ではまる。とりあえず、手持ちの15mm厚2.5“ HDD MQ03ABB300を入れてみた之図。

ご覧の通り、マウンター上端まではまだ余裕があるので、仮に17.5mm厚の2.5インチストレージとかが出ても収まりそう。そんなストレージ出ないだろうけど。将来、マウンタの仕様が変わって使えなくなったらメンゴ。構造的によっぽどの事がない限りは大丈夫だろうけど。

ついでにSupermicroのHDDトレイにはめてみた之図。

ばっちりでんな！……と言いたいところだけど、CRIN2535の側面の穴の位置が僅かにズレているようで、トレイへの取り付けがなかなかシビアだった。

ひょんな事からPlayStation® 4 Pro (CUH-7000)に買い替えることになったので、発売日に買った初期型PlayStation® 4 (CUH-1000)との消費電力を比較してみる。ブーストモードはオフ……というか、計測したのはかなり前で、当時はまだ提供されてなかったのである。出力信号は1080p。うちに4kテレビなどというものはないのである。4kのプラズマはよ！（絶対に出ません

消費電力は概ね2割減ってとこですか。ブーストモードやPS4 Pro対応ソフトだと多分跳ね上がると思うケド…。

この状態に悩まされてる人は何よりも答えが欲しいだろうから、最初に結論を書いておくと、smb.confでcase sensitive = yesと設定すると多分直る。直下に大量のファイルを抱えたフォルダをコピーするとsmbdがCPUを100%近く消費し、コピー速度が極めて遅くなる現象ならほぼ間違いなく直る。

「”大量のファイル”ってどれくらい？」かというと、サーバマシンの性能にもよるがCore i系なら概ね1万ファイル、流行りのラズパイとかだと恐らくもっと少数、単純なクロック比で1/2、実性能はもっと劣るだろうから更に半分で2500ファイルくらい？。完全な当てずっぽうですけど。要はファイル名の比較のところがボトルネックになっているようなので、CPUのシングルスレッド性能に依存する。

例によってNAS4Free 11.0.0.4 (4303)[FreeBSD 11.0-RELEASE-p10/Samba 4.6.4]でNASをでっち上げたのだが、知人曰く、今までのNASに較べてファイルコピーが遅い、と。マシンのスペック的にはXeon E5-2620v3, メモリ8GB, 1GbE×2のLAGで、ストレージも3.5インチHDD2本でRAID-1のペアを3ペアでRAID10なので問題が出るとは考えにくい。実際、シェルでのシーケンシャルライトでは500MB/sくらい出てる。

様々なサイズのテストファイルを試してみるも、至って正常な速度が出るし、むしろ他のNASよりも速いくらい。ところが、知人が遅いというファイル群で試してみると、たしかに遅い。小さなファイルが多いためワイヤーレートには程遠いが、それでも初速は10MB/s超えてるのに、あれよあれよと速度が落ちて仕舞には100kB/sを切ってしまう。そして何故かsmbdがCPUを100%近く持っていく尋常ならざる状態に。Pen!!!時代のGbEじゃあるまいし、たかがファイル転送でCPU 100%ってどんだけー。

問題のファイル群をシェルでcpすると30MB/s出てるので、やっぱりマシンに問題はなさげ。さらに、NAS4Free 9 [FreeBSD 9.3-RELEASE-p14/Samba 4.1.18]搭載の別マシン（Xeon E3-1225v2/16GB/3.5“ HDD 6台でRAID-Z2なので性能は必要十分）で試すと、安定して数MB/sは出るし、CPU負荷も常識的な範囲。となれば、問題なのはSambaっぽい…？

ここまで絞り込んでからが大変だった。

情報がないない。マシンの省電力設定を切ってみたり、Sambaが速くなる各種おまじないを試してみたり、SMBのプロトコルバージョンを変えたり、LAGを解除してみたり、etc…するも効果なし。ググりにググって、ようやくFreeNASのフォーラムでcase sensitiveが原因じゃねという投稿を見つけた次第。

早速case sensitive = yesにして試してみたら、効果てきめん。転送速度もCPU負荷も劇的に改善された（テストファイルが32kBなので速度がそんなに出てないのは仕方ない）。論より証拠ってなもんで、比較画像貼っておきますね。

その後、Sambaのドキュメントのcase sensitive設定のところを見たら、思いっきり「As a special case for directories with large numbers of files, if the case options are set as follows, “case sensitive = yes”, (後略)」と書いてあったでござる(´・ω・｀)。

大文字小文字の変換処理ごときで遅くなるなよ！と思わなくもないが、ファイルの新規作成時はディレクトリ内の既存ファイル名と被ってないか総当りでチェックしているようなので、何も考えずに実装すれば計算量はO(n/^2^/)、ファイル数が増えると爆発的に比較数が増えるんすなぁ…。にしてもですよ、デフォルト設定のcase sensitive = autoは以前のバージョンから変わってないわけで、いきなり遅くなるなんてチョーひどくなーい？

case sensitive設定を変えるとWindowsからのアクセスに支障がでないか心配なところだが（なんたってWindowsは表面上は大文字小文字区別しませんからね！）、/-そこはエクスプローラが上手いこと取り計らってくれる模様。本当かどうかは知らない。-/ → (2019-05-19 追記)取り計らってくれなかった。例えばa.txtとA.TXTがあった場合、どちらのファイルを見に行くかは半固定。一度決まった同名ファイルのアクセス先は固定されるが、それらファイルを含むディレクトリの内容が変わるとアクセス先の選定が再度行われ、その結果は不定ってのがWindowsの昔からの仕様らしい…。

• Slow, terribly slow smb in directory with multiple files (+30.000 files) | FreeNAS Community
• smb.conf
• Does Samba work well with Windows when case-sensitive names are enabled? - Server Fault

予定通りFreeBSD 11.1-RELEASEがリリースされた。めでたいめでたい。特定条件下の11.0RでVirtualBoxが動かない問題が直ってるハズなので、早速更新することにした。

基本はいつも通りfreebsd-updateするだけなのだが、現在の環境がFreeBSD 11.1-RC2の人は要注意。リリースアナウンスによれば、RC2でVirtualBoxを使ってる人はシステム更新の前にvirtualbox-ose-additionsを再インストールしないとカーネルパニックを起こすようだ。

うちは見事に該当してるので、手順に従う。

# pkg install -f virtualbox-ose-additions

これもリリースアナウンスに書いてあるが、念には念を入れ、vboxguestサービスを無効化しておく。経験的にVirtualBoxのカーネルモジュールとサービスはシステム更新時のハマりの原因になるので、必ず無効化することをオススメする。今まで何度地雷を踏み抜いたことか…(ヽ´ω`)

/etc/rc.conf

#vboxnet_enable="YES"
#vboxguest_enable="YES"
#vboxservice_enable="YES"

準備が出来たらいよいよfreebsd-updateだ。といっても、ここからはいつもの通り。

新しいシステムを取ってきて、

# freebsd-update -r 11.1-RELEASE upgrade
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 11.1-RC2 from update4.freebsd.org... done.
Fetching metadata index... done.
...

カーネルをインスコして、

# freebsd-update install
Installing updates...
Kernel updates have been installed.  Please reboot and run
"/usr/sbin/freebsd-update install" again to finish installing updates.

再起動して、

# reboot

ユーザーランドをインスコして、

# freebsd-update install
Installing updates... done.

再起動して、

# reboot

無事、FreeBSD 11.1-RELEASEの環境へ。

$ freebsd-version -ku
11.1-RELEASE
11.1-RELEASE

Perforceでチェックアウト中のファイルに変更があるかどうか──P4Vで言えば、チェンジリストのファイルアイコンが青くなってるかどうか、を調べるにはp4 diff -sr /path/to/fileを使う。ファイルに変更があれば何も返ってこず、変更がなければ与えたファイルのフルパスが返って来る。

■ファイルに変更がある場合
$ p4 diff -sr modified_file.cpp
$

■ファイルに変更がない場合
$ p4 diff -sr no_changes_file.cpp
/path/to/no_changes_file.cpp
$

もっと直接的に確認できる方法は無いのだろうか・・・？

• p4 diff // P4コマンドリファレンス