ソースの表示以前のリビジョンバックリンク全て展開する/折り畳む文書の先頭へ Share via Share via... Twitter LinkedIn Facebook Pinterest Telegram WhatsApp Yammer Reddit Teams最近の変更Send via e-Mail印刷パーマリンク × « MacPortsでSubversion 1.7を入れる リモートデスクトップの反応が鈍く描画がカクつく問題を直す » DiskWarriorはもうオワコンかもしれない (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だと、分割数が数十万とかになっちゃって削除するのも一苦労なんだけど…。 Comments Name E-Mail Website 人間の証明として、ボックス内の全ての文字を入力してください。 この項目は空のままにして下さい:Preview Comment blog/2014/2014-02-13.txt 最終更新: 2015-01-18 00:21by Decomo