変人御用達の Courier Mail Serverのバージョンが、9月にめでたく1.0の大台に乗っていた。
その一方、FreeBSDのportsのmail/courierは何年も0.65止まり。メンテ自体は行われていて、0.65.3のまま周辺環境の変更に追従している感じ。なぜ本体のバージョンアップを行わないのか不思議だったんだけど、MLによれば、メンテナが他の件で忙しいのと、0.65より新しいCourierは依存関係が増え、その解消のために新たなportsを作らなきゃならんのが原因らしい。まぁ、その投稿（2014年）から4年が経つわけですがね…。
早く追従してくれないかなー（人任せ
FreeBSDでPortsからMySQL/MariaDBを入れる際、盲目的に指定するオプションにWITH_CHARSET, WITH_XCHARSETがある。Ports独自のオプションで、しかも日本以外での使用例が殆なく、これぞという解説も見当たらない。仕方ないのでportsの更新履歴や8-RELEASE以前の古いportsツリーを調査してみたところ、なんとmysql55で廃止されてるっぽい。
mysql51-serverのportsのMakefile（MySQLそのもののMakefileじゃないよ）には以下の記述があるが、mysql55-serverからは消えているのだ…！MariaDBはMySQL 5.5からのフォークなので言わずもがなである。
.if defined(WITH_CHARSET) && ${WITH_CHARSET} != ""
CONFIGURE_ARGS+=--with-charset=${WITH_CHARSET}
.endif
.if defined(WITH_XCHARSET) && ${WITH_XCHARSET} != ""
CONFIGURE_ARGS+=--with-extra-charsets=${WITH_XCHARSET}
.endif
見ればわかるが、portsのWITH_CHARSET, WITH_XCHARSETオプションは、それぞれMySQLの–with-charset, –with-extra-charsetsオプションに対応している（正確には“していた”）。そして、MySQL 5.5からは–with-charset自体が消えてるっぽい。–extra-charsetsってのはあるみたいだけど。–with-extra-charsetsの方もデフォルト値がallとなり、ports側から敢えて指定する必要性もなくなったのだと思われる。
WITH_CHARSET, WITH_XCHARSETオプションは、2001年1月25日にmysql323-serverに対する追加が初出のようだ。その時の更新メッセージは「Add options for alternate charsets (WITH_CHARSET and WITH_XCHARSET).」といったもの。
というわけで、MySQL/MariaDBインストールでWITH_CHARSET, WITH_XCHARSETを付けるのはもう止めよう！
OpenZFS Developer Summit 2018を眺めてたら、Device Removalなるスライドを発見。タイトルの通りvdevの取り外しに関する機能である。
ご存知の通りZFSでは、一度プールに組み込んだデバイスの削除に非常に厳しい制約がある。プールのスケールアップは極めて容易な一方、スケールダウンは事実上不可能だった。しかしDevice Removalによって、ミラー構成のvdev限定ではあるものの削除が可能となる。
嬉しい人には嬉しいと思われるこの機能、なんとFreeBSD 11.2-RELEASEで既に取り込まれてた。11.2Rのmanから説明を引用してみる。
Removes the specified device from the pool. This command currently only supports removing hot spares, cache, log devices and mirrored top-level vdevs (mirror of leaf devices); but not raidz.
スライドの方にしか書いてないけど、この機能でミラー構成トップレベルvdevを削除するには、各vdevのashiftが同量じゃないと駄目らしい。ashiftはvdev単位での設定なので、デバイス追加時は注意が必要。
RAID-Zでも使えるようになってほしいけど、実装面ではRAID-Z Expansion頼みかしら…？こっちの進捗具合はどうなってんだろうなー。去年のちょうど今ごろRAID-Z Expansionに関する記事を書いたものの、とんと続報がない。FreeBSD 12で実装見込みとのことだったが、十中八九間に合わないだろうなー。現時点で12.0Rは12月頭のリリース予定だし…。
家のFreeBSDサーバのportsたちをportmasterで更新していたところ失敗するやつがあった。失敗自体は取り立てて珍しいことでもないが、今回はThis command has been saved to /tmp/portmasterfail.txtという見慣れない行が現れた。メッセージの通り、失敗した時の結果が保存されるらしい。中身はというと…
portmaster <flags> lang/php71-extensions graphics/php71-gd x11/libXpm x11-toolkits/libXt x11/libICE x11/xorgproto x11/libSM x11/libX11 x11/libXau x11/libxcb devel/check x11/libXdmcp x11/xcb-proto x11/libXext math/php71-gmp security/php71-filter security/php71-mcrypt security/libmcrypt security/php71-openssl sysutils/php71-fileinfo sysutils/php71-posix textproc/php71-ctype textproc/php71-dom textproc/php71-simplexml textproc/php71-xml textproc/php71-xmlreader textproc/php71-xmlwriter www/php71-opcache www/php71-session
あ、うん、はい（白目
失敗部分のログが保存されてるかと思いきや、portmasterコマンドのログだけだった…。この機能は2017/2/3のportmaster 3.17.10で実装されたっぽい。まぁ、何も無いよりはマシか。
ちなみに今回の直接の失敗原因はxorgprotoとglprotoの競合だった。
===> Installing for xorgproto-2018.4 ===> Checking if xorgproto already installed ===> Registering installation for xorgproto-2018.4 as automatic Installing xorgproto-2018.4... pkg-static: xorgproto-2018.4 conflicts with glproto-1.4.17 (installs files into the same place). Problematic file: /usr/local/include/GL/glxint.h *** Error code 70 Stop. make: stopped in /usr/ports/x11/xorgproto
こういう時はまず/usr/ports/UPDATINGを見てみる。特にportsの競合の場合は大抵解決策が書いてある。今回も見事に書いてあった。
20180731: AFFECTS: users of x11/xorg and all ports with USE_XORG=*proto AUTHOR: zeising@FreeBSD.org The xorg *proto packages have all been merged into one package, x11/xorgproto. This might cause issues with upgrading. If you get conflicts between xorgproto and old *proto packages, please remove the old package and install xorgproto again. In order to remove all orphaned ports, including all *proto port, the following can be used after the ports tree has been updated: pkg version -l \? | cut -f 1 -w | grep -v compat | xargs pkg delete -fy
X.orgのproto系パッケージがx11/xorgprotoに統合されたために、glprotoと衝突した事がわかる。最終行のコマンドを実行して解決。失敗したportmasterコマンドを再実行してインストール完了。あ、この時にportmasterfail.txtが役立つのか！
同一フォルダに大量のファイルがあるとSambaが超遅くなる問題、自分なりの知見が得られたのでメモ。結果だけ知りたい人は最後までスクロールしてくだしあ。
まずはおさらい。
ことの発端は、数万個のファイルがあるフォルダをSambaのファイルサーバにコピーすると、速度が10kB/s前後まで低下する現象に見舞われた。速度はコピーが進むごとに低下し、比例してsmbdのCPU占有率が上がるというのが特徴。サーバ上で直接コピーすると何の問題もない。
調査を進めると、ファイル作成時Sambaはファイル名の重複チェックのため、作成先フォルダ内の全ファイル名を検査することが分かった。この時に行われるWindowsのファイル名規則（FS上は大文字/小文字を区別するが、一般的なファイルアクセス上は区別しないナンチャッテcase-preserving。この差はOSが吸収する。）と合わせるための、ファイル名を大文字ないし小文字に変換する処理がボトルネックのようだ。
プロファイルしたわけでもソースコードを見たわけでもないので確証はないが、公式ドキュメントに「ディレクトリに大量のファイルがある特殊なケースでは、case sensitiveをyesにせよ」(抄訳)と書かれており、ファイルコピーの進捗にあわせ指数関数的に速度が落ちる（CPU負荷が上がる）という挙動から、たぶん当たってると思う。
ではcase sensitive = yesにすれば万事解決かといえば、そうじゃない罠。
前述の通りWindowsはFS的にはcase-sensitiveだが、歴史的理由で表面的にはcase-insensitiveとして振る舞う。この仕様に胡坐をかき、ファイルパスを内部的に大文字or小文字に変換して扱うアプリケーションが少なくない。例えば、本来のファイルパスはC:\Data\FILE.datにもかかわらず、アプリケーション内部では
c:\data\file.datとしてアクセスすることが往々にある（自分もそういう処理をつい書いちゃうんだけど(;'∀')）。ローカルのファイルに対してなら、これでも問題はない。
しかし、サーバの共有フォルダに対しては、アプリから渡されたファイルパスをそのまま渡しているようだ。故にサーバ側がその辺を考慮した処理になってないと、ファイルが見つからないという事になる。Sambaのcase sensitiveオプションは、まさにその辺の制御を設定するオプションなのだ。これをyesにするということは、\\Server\Data\FILE.datと\\Server\data\file.datは別のファイルと見なされる、ということだ。アプリからすれば、\\Server\Data\FILE.datが見つからないということになる。これでは使い物にならない。
ではどうするか。ZFSのcasesensitivityプロパティの登場だ。
お察しの通りその名の通りのプロパティで、デフォルト値はcasesensitiveである。これをcaseinsensitiveにしてやればいい。insensitiveという名付けではあるが、挙動としてはpreservingのようだ。ちなみに、mixedというのもあるが、使いどころがよくわからない挙動なので指定しない方が無難（一応、Windowsを想定した挙動らしいんだけど…）。
本プロパティはFS作成時にしか指定できないため、Windows共有用のFSを新規に作り、Sambaで共有フォルダに仕立て上げるのがよいだろう。
Sambaがファイル名をキャッシュせずファイル作成毎に全舐めしてしているのは、恐らく対象フォルダに対する変更をSamba側で検知する仕組みがないからだと思う。Sambaがファイルを作成しようとしたまさにその時、同名のファイルがサーバのローカルで作られたり、別のファイルがリネームされたりする可能性があるため、キャッシュではファイル名のユニーク性を担保できないのだろう。
一方、ファイルシステムレベルなら、そのような変更の検出とアトミック性・ユニーク性が保証された素敵な仕組みがあるハズだから、アプリ側でファイル名の全比較を行うより効率的なんじゃねっていう目論見。
結論としてはSambaとZFSで以下の設定を行うと幸せになれる。ZFSじゃない人はスマン…
zfs create -o casesnsitivity=caseinsensitive ztank/path/to/cifs
case sensitive = yes case preserve = no short preserve case = no
