• OS X Mavericks 10.9.2
• PC版Radeon HD 7000系以上
• モニタをDisplay Portで繋いでいる

以上3条件が揃うと、OS Xが無限再起動ループに陥る。旧型RadeonもしくはDPを使わなければ大丈夫っぽい。

正規のSAPPHIRE HD 7950 MAC EditionでEFIを使ってるなら大丈夫らしい？

• Anyone with Radeon 7950 NOT having problems with 10.9.2?
• 10.9.2 update borked Radeon 7950 GPU (Display Port - DVI is OK): Apple Support Communities
• 10.9.2 Reboot loop no Displayport working: Apple Support Communities
• HT6114 Reboot loop after 10.9.2 upgrade: Apple Support Communities

会社のMac(Mountain Lion)から隣に鎮座してるWindows 7にMicrosoft Remote Desktopで繋ぐと、操作に対する反応がワンテンポ遅れ、画面の描画も超遅い現象にずっと悩まされていた。アナログ56k時代の巨大画像読み込み（ツッ・・ツッ・・ツッっていうアレ）を彷彿とさせる遅さ。接続条件は遥かに悪いハズの、インターネット越しの自宅鯖の仮想マシン上のWin 7に繋いだ時の方が快適という酷さ＆謎っぷり。

で、やっとこの問題を解決出来た。

デバイスマネージャのネットワークアダプタの詳細設定で一括送信を無効にすると直る。NICの種類によってプロパティ名が違うのが厄介と言えば厄介。たとえば、Realtekなら「一括送信オフロード」だし、Intelなら「大量送信オフロード」って具合。とにかく、巨大データを一気に送る風な名前のプロパティだ。

ふと思ったんだけど、このプロパティってネトゲの通信に影響及ぼしたりしないのかなぁ。こいつに引っかかると、かなりのラグが発生するため、リアルタイム性を要求されるゲーム(FPSとか)では、かなり不利になりそうなもんだけど…。“大量送信”という名前から察するに、データ量が少なければ問題ないのかしらん。

(2015-01-18追記:64ビット対応を果たしたDiskWarrior 5が出たので、再び神ツールの座に舞い戻ってきたかもしれない)

久々にTime Machineのsparsebundleが壊れた。

fsck_hfsで修復出来なかったのでDiskWarrior 4.4を引っ張り出してみるも「There is not enough memory. Restart from the disk warrior disc and try rebuilding again. If you report this error. Please mention the error code (2154)」と言われて修復不能。32GB積んでるマシンなので、実際メモリ不足って事はないと思うんだけどなぁ。

修復処理を始めてすぐにエラーを吐くので、恐らく修復対象ボリュームのファイル数から必要なメモリ数を見積もり、処理出来るか判断してるのだと思う。DWは32ビットアプリのようなので、使えるメモリの上限は4GB。この制限は仮想メモリを使っても突破出来ない（物理アドレス拡張を使えばこの限りではないが、DWが対応してるとも思えないし、そもそもOS XでPAEアプリを作れるかも不明）。要は、扱えるファイル数に上限があるって話ですな。Time Machineの性質上、バックアップ先のファイル数は大きくなりがちで、2154エラーで検索するとTime Machineの修復で発生している事例が多いのも頷ける。

では、DWが扱えるファイル数の上限はいくつだろうか？

DWのロジックが分からないので完全な推測になってしまうが、ファイルシステムの構造(B-Tree)を弄っているのは間違いないだろう。Technical Note TN1150: HFS Plus Volume Formatによると、1ノード(BTNodeDescriptor)≒1ファイルあたり14バイトとなっている。アライメントも考慮してキリよく16バイトとし、メモリ4GBフルに使ったとすると2.6億ファイルとなる。ちなみに、自分の手元のマシンは約52万ファイルを有しているので、500台分のファイルを扱える計算だ。

この数値だけなら十分大きいように見えるが、実際は4GBフルに使える訳じゃないし、1ファイルあたりの消費量ももっと大きいだろう。多めに見積もっても、せいぜい1億ファイルに届かない位なんじゃなかろうか。自分の感覚で言わせて貰うと、今の時代、少なくは無いが安心出来るほど多くもないって所かな。

まぁ、普通のボリュームに対してなら、まだまだ必要十分なスペックだろうけど。積極的にメンテされてる雰囲気がない点も気になるところ。

DiskWarriorとは全く関係ないが、sparsebundleの分割サイズ、もう少し大きくならんかねぇ。今どき8MBだと、分割数が数十万とかになっちゃって削除するのも一苦労なんだけど…。

Xcode 4のSubversionが1.7のため、MacPortsで1.8が入ると色々と面倒なので、敢えて1.7にダウングレードしてインストールする。

unicodeパッチを標準で取り込んでくれたら、MacPortsから入れる必要もなくなるんだがねぇ。

svn co http://svn.macports.org/repository/macports/trunk/dports/devel/subversion --revision 108493
cd subversion
sudo port install +unicode_path

Xcode 3を入れてる環境で

Error: The installed version of Xcode (3.2.6) is too old to use on the installed OS version. Version 4.6.2 or later is recommended on Mac OS X 10.8.

と言われた場合は、

sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer

として開発環境をXcode 4に切り替えればおｋ。

• Philipps Blog » Downgrading Subversion from 1.8 to 1.7 in MacPorts
• macports - "The installed version of Xcode (3.1.4) is too old" error in port after installing Xcode 4.3 - Stack Overflow

RAW+JPEGで撮影された写真をLightroomの自動スタックでまとめてたら、スタックされない写真があった。調べてみるとPENTAX QのRAW+で生成されたRAWとJPEGだった。

自動スタック機能は撮影時刻から同一シーンかどうかを判断している。当該写真のExifを見ると、RAWとJPEGで撮影時刻が違ってやんの。RAWの方がJPEGより数秒後に撮られた事になっている。多分それぞれのファイルの生成時刻が記録されてるんだろうけど、同一ショットのRAWとJPEGを記録するモードなんだから、同一時刻になって然るべきなんじゃないかなぁ…。遅延時間が一定ならまだしもファイルによって違うから、自動スタックの条件変更でも対処出来ないから困る。

とりあえずリコーに「一致させて！」と要望を出してみた。

すると、ものの2時間程で返事が来た。内容はテンプレだったけど、土日はメールの対応くらい休んでもええんやで。急を要する内容じゃないからメールで問い合わせしてるんであってｗ まぁ、素晴らしい対応で感動した。次のファーム更新で直してくれたら更に感動するけど。