Time Machineのバックアップ先は1つしか指定出来ないと思っていたが、実はMountain Lionから複数のストレージを指定出来るようになっていたらしい。実際に10.8.5で試してみたら出来た。

指定したバックアップ先はタイムマシーンのスケジュールに沿って、順繰り使われる模様。つまり、バックアップ先にA, B, Cの3つを指定したとすると、最初にAにバックアップされ、1時間後にB、更にその1時間後にCにバックアップされる。そしてAに戻るという具合。

物理的に違うストレージを指定して、複数のTime Machineバックアップで対障害性の向上を狙うってのが普通の使い方なんだと思う。しかし1台のストレージでも、パーティション分割で敢えて2つのバックアップとすることで、対論理障害性の向上が期待出来る（まぁ過去のバックアップの保持期間は半分になっちゃうけど）。

これってNASをバックアップ先にしてる場合に威力を発揮しそうな予感。ネットワーク越しだとスパースバンドルの中にバックアップディスクが作られる訳だけど、このイメージが良く壊れるのよねー。バックアップデータとはいえ、壊れると結構ショックなもんですよ。そして、大抵バックアップが壊れてる時に限って、オリジナルのデータが壊れるのよね……。

という訳で、早速NASのTime Machineボリュームを2つに変更した。TimeMachineSchedulerでバックアップ間隔を弄ってるけど、特に問題なく動いてる模様。

• 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