最近の変更サイトマップ

FreeBSDのMySQLのWITH_CHARSET, WITH_XCHARSETオプションは既に無意味

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を付けるのはもう止めよう

参考サイト

EmacsのM-x compileで自動的にMakefileを探し出すようにする

Emacs上でソースコードのコンパイルを行うにはM-x compileコマンドを使う。するとmakeが走り、結果がCompilatinバッファに表示され、M-x next-errorなどでエラー行に一発ジャンプ出来て超便利ッ……という所までは良く語られる。が、しかーし、肝心のMakefileの指定方法に触れている解説が少ない。

実際のところ、M-x compileのmakeの引数指定のところで書いてやればいいのだが、カレントパスや取り掛かっているプロジェクトごとにアレコレ考えてMakefileを指定するのは現実的ではない。それする位なら、Compilationの利点を捨て、ターミナルのコマンドヒストリーでコンパイルした方がよっぽどマシである。たいてい、Makefileはソースフォルダのトップなりに置くので、編集中のファイルから上に辿り、見つかったMakefileでmakeしてくれれば済む話。

で、ようやくそれを実現する方法を見つけた。Recursively go up to find Makefile and compileに載ってるelispを使う。万が一消えた時用に転載。

(defun desperately-compile ()
  "Traveling up the path, find a Makefile and `compile'."
  (interactive)
  (when (locate-dominating-file default-directory "Makefile")
  (with-temp-buffer
    (cd (locate-dominating-file default-directory "Makefile"))
    (compile "make -k"))))
 
; C-x mでMakefileを探してコンパイル
(global-set-key (kbd "C-x m") 'desperately-compile)

上記サイトの回答に書いてあることだが、指定ファイルが見つかるまでディレクトリを遡って検索する打って付けのlocate-dominating-fileなる関数があるそうで。今回の用途だけではなく、様々な場面で役に立ちそう。

SambaとZFSで大量のファイルを扱う時はcase-sensitiveの組み合わせを最適化する

同一フォルダに大量のファイルがあると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
    • ファイル共有用にcasesensitivity=caseinsensitiveなFSを作る
      zfs create -o casesnsitivity=caseinsensitive ztank/path/to/cifs

  • Samba
    • ファイル名の扱いをcase-sensitiveにする

      case sensitive = yes
      case preserve = no
      short preserve case = no

EmacsのCompletionsバッファを新規ウィンドウではなく既存ウィンドウに表示させる

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

自分のEmacsの使い方は垂直分割した2つのウィンドウ表示が基本で、Completionsバッファは非アクティブな方のウィンドウに出て欲しい。その方が補完候補の一覧性が圧倒的だし、ウィンドウがパカパカしないのがいい。スクショを張(ry こっちがいい(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表示時に勝手にリサイズされる問題があったりする…。自分は水平分割使わないので放置してます、すいません。えらいひと直して教えてください。

参考サイト

1) Emacs用語としてのフレーム
2) Emacs用語としてのウィンドウ

トロピコ5のトロフィー「ワーストホテル」「冷徹な刺客」の取得方法

トロピコ5のDLC「スパイ大作戦」に含まれるトロフィー、「ワーストホテル」と「冷徹な刺客」の取得に苦労したのでメモ。

ワーストホテル

取得条件:地下牢と刑務所に20人を収監した

  1. サンドボックスで新規プレイ。資金無制限、現代、初期人口50人で。
  2. 警察署を3つ即座に建設し、外国人作業者を全員雇用。
  3. 刑務所を2つ即座に建設し、外国人作業者を全員雇用。
  4. 住人リストで片っ端から住人を逮捕する。
  5. しばらくするとトロフィーゲット

条件の20人は延べ人数ではなく、収監中の人数である。

「逮捕」を指示すると、警察官が対象者を探し刑務所/地下牢獄に連行して初めて収監扱いになる。したがって、街の規模が大きくなると捜索に時間がかかり、その間に囚人が出所してしまうため、いつまで経っても収監人数が増えない。

冷徹な刺客

取得条件:無人機で問題のある住民を20人殺害した

  1. 無人機基地を作って普通にプレイする
  2. 気長に待つ

問題のある住人を量産しようとハチャメチャな政治をしても、人口が増えない→問題のある住人が増えない→無人機基地の作業員すらまかなえない、という状況に陥り全然SATUGAIしてくれない。なので普通にプレイした方がよさげ。サンドボックスで政治的難易度を最高、無人機基地の予算と作業員を最大にしておけば気持ち早いかも?(根拠無し)。

自分の場合、人口増えないループからの脱出込みで、ゲーム内26年経過で取得できた。

start.txt · 最終更新: 2016-05-07 17:46 by decomo
CC Attribution-Noncommercial-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0