MacOSXでフラグメンテーションのチェックをするには？
またはフラグメンテーションの対処はした方が良い？

ShowVolumeFragmentation

ファイルの書き込み、上書きを続けていると内蔵ディスクにフラグメンテーション（ファイルの断片化）が起きてくる。
そのフラグメンテーションが起きるメカニズムはここに詳しく書いたが、問題はこのフラグメンテーションがどれくらいシステムの動作に影響をもたらすかということだ。

このアプリの作者さんもその辺りを考察していて
「ディスクに２０％以上空きスペースがある場合は気にすることは無い」
と書いておられる。
「ただし空きスペースが１０％を切った場合はちょっと気にした方が良い」
というのが、この作者さんの見解だ。

実際Mac miniのパンサーで実行してみたところ、なんと最上位のEIJIROファイルからは５００以上の断片化を検出した。
ここでOS9時代だったら青くなってシマンテックのノートンスピードディスクなんかかけていただろう。
しかしOSXを使っている現在はそんなことをする必要もないし、そんなものを使うと結局今よりも悪い状態になって、システム再インストールなんていう重篤な状態になってしまうということを今では体験的に思い知っている。

つまりこのアプリでフラグメンテーションを検出しても結局何もしない方が良いということだ。
OSXはファイルの上書きでフラグメンテーションの解消をトライするようにセッティングされているそうだし、フラグメンテーションが残った状態でも動作に問題を起こさない。

実際私の知っている人でOSXでわざとフラグメンテーションを生成して、そのあとスピードディスクでデフラグをやって両方の状態でベンチマークをとった人がいたが、結論からいうと体感できるほどのスピードの差はなかったということだ。またフラグメンテーションが原因でシステムが不安定になるということも確認できないという。
つまりデフラグはリスクばかりが高くてその効果がほとんどわからないということだ。

それではなぜ皆デフラグということを言うのかというと、それはWindowsでの常識が影響しているのだ。
Windowsでは確かにフラグメンテーションがシステムの動作速度や安定性に影響を及ぼすということは考えられる。
私の会社の同僚には毎日Windowsを起動する時にディスクスキャンをかけてデフラグをやっているという人もいた。
こんなのは私から見れば自殺行為で、いつ起動できなくなっても不思議ではないという気がする。
それでWindowsでのそういう常識に慣れた人、あるいはOS9以前もフラグメンテーションの影響を受けやすかったので、そういう常識が染み付いた人がシステムが不調になると
「デフラグをしなきゃいけないんじゃないか？」
というようなことを言うわけだ。
しかし上記のように実際にデフラグの実験をした人によれば、少なくともOSXに関してはデフラグの効果はほとんど認められず、デフラグのリスクは他の環境と同じく非常に高いという結論になる。

だから繰り返して強調するが、こういうアプリを使って大量のフラグメンテーションを検出してもくれぐれも慌ててノートンのスピードディスクなんかかけてはいけない。
そんなことをすると、もともと問題が無いところに問題を作り出すようなものだ。

なおこのアプリの動作にはhfsdebugが必要だ。
この実行型ファイルをダウンロードしてShowVolumeFragと同じフォルダに入れることで初めてこのアプリは動作する。

ShowVolumeFragmentationはボリュームの断片化を検出するアプリ
大量のフラグメンテーションを発見したところで結局何もしないのだが....

iDefrag Demo

Macのボリュームのフラグメンテーション（断片化）を診断したり解消するアプリ。

最近はiPhone、iPad効果なのか、Windowsから大量にMacにユーザが流れ込んできて、最近Macを使い始めた、あるいはこれから使い始めるという人が随分増えた。
そうするとMacとWindowsのカルチャーの違いから多くの誤解が生じる。

例えば最近Twitterなどで
「Macのデフラグのやり方が分からない」
「Macにはディスクデフラグソフトが付属していない」
「Macの断片化がひどく、こういうところがやはりWindowsに比べて遅れている」
等の書き込みが散見されるようになってきた。

Windowsマシンを動かす上でデフラグは必須のメンテナンスだ。
だから長年Windowsを使ってきたユーザには「システムが遅くなったらデフラグ」というのは体に染み付いている。
しかしその常識をそのままMacに持ち込むから、上記のような不満になってくる。

結論から先に書くとMacの場合、使い方に心得があれば基本的にデフラグなどは必要ない。
長年使ってきてデフラグの必要性など感じたことは一度もない。

それでもどうしてもデフラグをやらないと精神衛生上耐えられないという方のために、こういうアプリがある。
このアプリはレジストする前のデモ版でも起動ボリュームなどの断片化の全域診断は可能なので、これを使って自分のディスクの断片化の状況を確認してみるのもいい。

使い方に心得が有ればと書いたが、その心得はそんなに難しいことではない。
注意しなければいけないのは、ディスクの空き容量が１〜２GBしかないような余裕がない状態で使うなという一点だけだ。
どれくらい空き容量があれば充分かは、CPU速度、メモリ容量などいろんな条件によって変わってくるが、基本的には１０GB程度以上起動ボリュームに空き容量があれば、あるいは２０％以上空き容量があれば断片化は気にすることはないと思う。

空き容量は大きければ大きいほど断片化を予防できるので、無理なパーティション切りをして起動ボリュームを小さくするよりも、パーティション切りしないでワンボリュームで使うのが良いと思う。

それで断片化が進行しない理由は、Mac／UNIXが採用するファイルシステムは自動的にフラグメンテーションを解消する仕組みになっていると理解しておいてもらっていい。

iDefragはレジストすると起動ボリュームのデフラグ（断片化解消）をシステムディスクからの起動をしないで進めることができるとリードミーにも書いてある。
iDefrag２からは、そういう専用ブータブルディスクを作成してそこから起動して起動ボリューム全域のデフラグをする仕組みに変わったようだ。

またデフラグの作業中SMARTモニタリングでディスクの温度も監視して、温度が上昇した場合はデフラグの作業を一時停止させるとか、デフラグの書き換えのプロセスの度に、データの書き込みが正常に行われたか確認するとかの安全策も用意されている。
デフラグをあまり頻繁にやらない方が良いというのは、データの破損以外に夏の気温が高い時にディスクアクセスが激しいデフラグ作業を頻繁にやると、ハードディスクの温度が上昇して逆に故障の原因になりやすいということも関係する。

ハードディスクは５０度以上に温度が上がりっ放しになって数十分も下がらないなんてことを頻繁に繰り返していると、故障の確率が急増することが確認されている。
デフラグを気にしてかえってディスクの寿命を縮めるような愚かなことを繰り返さないことをお勧めする。
どうしてもデフラグをやらないと精神の安寧が得られないという人はこういうアプリを積極的に使ってみるのも手だ。

ただし繰り返し強調するが、Macの場合はデフラグの必要はないということは断言しておく。
このことは以下のキャプチャーでも説明する。

iDefragを起動するとこういう画面に
まずどのボリュームを診断したいのかを左のペインで選択せよと出てくる

システム領域も含めてフラグメンテーションの診断をするので当然管理者権限が必要になる
この表示で南京錠のアイコンをクリックする

パスワードはルートのパスワードでないといけない

こうして診断がスタートする

診断が進行していくとアロケーションの色分けが広がっていく
緑は一応問題ない領域ということらしい

さてこれがグラフィックの診断結果
この通り真っ赤になる
これだけ見ると断片化が深刻なレベルで広がっているように見える
「これはまずい！いますぐにでもレジストしてデフラグをやらなければ！！」
と思ってしまうような色あいだ

しかしこちらの「Statistics」のタブでまずその数に注目して欲しい
総ファイル数に対して断片化しているファイルは６４００ほど、
1.1%のファイルが断片化しているということになる

さらに「Files」のタブをよく見ると６４００もの断片化したファイルのうち
１／３の２１００はClamXavのスキャンログ、１５００はEchofonのTweetデータベースログ、
７００はサムネイル、５００は暗号化ドキュメントのスパースバンドルと
上位５／６は別に断片化していても大勢に影響のないファイルばかりだ
システムなどの速度に影響しそうなファイルの断片化は合計でも１００前後しかない
これは長年Macを使ってきた私の実感とも一致するが１００程度の断片化は別に深刻でもないし
このためにいろいろリスクのあるデフラグをかけるメリットはほぼない

それでもどうしても断片化があると精神衛生上良くないという方のために
このiDefragをレジストするという手はある
デフラグには別パーティションまたはシステムディスクからの起動を要求されるが
iDefrag２からは専用ブータブルDVDを作成して
そこから起動して全域デフラグということも可能になった

またデフラグ作業中の書き込みをその都度チェックするモード、ハードディスクの温度を
監視して過熱を防止するモードなど様々な安全策も用意されている
ただ何度も強調するがMacの場合デフラグは必要ないので
時々このデモ版でチェックするだけで充分だと私は思っている

この通り自動的に断片化を解消する仕組みがあるにもかかわらず、断片化を起こしているファイルというのは、頻繁な回数追記上書きされるような種類のファイルに限られている。
このうち大部分を占めるウイルス対策ソフトのスキャンログやTwitterクライアントのデータベースファイルは、別に異常が無ければ削除してしまってもかまわない。
それだけのことで大半の断片化は一瞬で解決する。

過去に相当負荷のかかった業務用のMacのメンテナンスも経験してきたが、断片化が深刻なレベルにまで進行したという経験は一度もない。
せいぜい１００から２００、多くて３００。
３０〜６０万ものファイルが格納される起動ボリュームの中で、この断片化のレベルは取るに足りないということになる。
システムの動作が遅くなっているのを見て、せっせとデフラグして一向に症状は改善していないのに
「もっとデフラグせねば」
なんて言ってる「デフラグ信者」もたまに見かけるが、Macの場合システムやブラウザなどの動作がもたつくのは大概はもっと別のことが原因になっている。
その原因を切り分けるのが先決で、盲目的にデフラグをやっても一向に症状は解決しない。

ただし上記のことは
「起動ボリュームに充分な空き容量がある場合」
に限られる。
初心者の中にはディスクを効率的に使いたいと考えるのかどうか分からないが、空き容量１GB切るようなレベルで使っている人をたまに見かける。
この場合は断片化はどんどん進行していると考えて間違いない。
ハードディスクなんてもうコモディティ化して安いんだから大容量のものを大盤振る舞いしたほうが、いろいろシアワセになれると思う。

モニターが表示できなくなった時の脱出法について

Mac mini用に買ってきたSHARPの液晶モニターはMac非対応のためか、型が古いせいなのかシステムのディスプレイ設定のリフレッシュタイムを変更すると画面に表示ができなくなる。

70/sや75/sには対応しているが85/sに設定を変更すると液晶画面が真っ黒になってしまい、そうなるとGUIの操作は一切できなくなるので終了や再起動もできなくなる。
そういう時には実は慌ててばたばた騒がないで１５秒じっと待っているか、escapeキーを叩くと自動的にディスプレイの設定がもとに戻るようにシステムは設計されているのだが、私が慌て者だったために、そこでいろいろ触ってしまって却ってこの真っ黒画面から脱出できなくなった。

そういう時にはシステムディスクか外付けのHDの予備システムから起動して、
"/Library/Preferences/com.apple.windowserver.plist"
を削除すればログイン画面までは表示できるようになる。

ログイン後に再び同じ症状が起きるようであれば
"~/Library/Preferences/"
"~/Library/Preferences/ByHost/"
の中の日付けが新しいものを外してみて再起動すれば、いくつかシステム環境設定を再設定することになるが立ち直ることができる。

"~/Library/Preferences/"
の中身については５つくらいには絞り込んだのだが、どれがディスプレイの設定に関与しているのか特定することができなかった。
なんせ画面真っ黒から再起動するには電源ボタン長押しの強制再起動しか方法が無いので、あまり繰り返し何度もやるとハードディスクを傷めてしまうのでひとつに絞り込むまでやる根気が無かった。

つい最近そうやって何度も強制再起動してハードディスクも壊れちゃったという実例を目の当たりにしているので、強制再起動はやはり極力避けたいのだ。
どなたか検証した方がおられたら情報を下さい。

Spotlightがちゃんと動いていない。(mds、lsregisterが動いていない)

どうやらメタデータファイルを更新しなくなったようだ。
例えばスクリーンキャプチャを撮るとデスクトップjpegができる。
これをFinderのプレビュー画面で見ると前だったらすぐに画像のスクリーンサイズを表示していたのだが、いつからか表示しなくなった。

撮り立てのスクリーンキャプチャでも画像サイズを表示していたFinderのプレビュー画面だが
いつからかこのような表示になってサイズを表示しなくなった

先日システム環境設定のプライベートで対処したと書いたがこれでは解決しなかった。
これはいつかも来た道だということで、こちらのTipsにしたがって
sudo mdutil -E /
のコマンドを実行した。
しかし結果はやはり同じことで、それ以前にあったファイルのメタデータは生成されるが新たに生成したファイルのメタデータを更新しない。

これは問題だ。
タイガーの場合はやはりSpotlightに依存しているのでこれがないと検索にいちいちアプリを起動しなくてはいけなくなる。
最初は使い勝手に不満を感じていたSpotlightだが、使い込んでみると結構この高速性には馴染んでしまったのでこれが使えないのは不便だ。

メタデータを初期化する魔法の呪文を実行してみた
一回トチッているがちゃんとメタデータの初期化には成功した
ところが結果は一緒で前からあるファイルのメタデータはちゃんとできたが
新たに作ったファイルのデータを更新しない

Spotless

これは要するに一時的にSpotlightを止めたり再始動したりできるシェアウエアだ。

Spotlightは高速な検索機能で便利なのだが、そのベースになっているメタデータ生成のmds、LAServerは新たなボリュームがマウントされるたびに勝手にメタデータを生成し始めてその度に数十分から数時間CPUをフルアップさせるというとんでもない欠点がある。
この問題をなんとかして欲しいとずっと思っているのだが、レパードでもそれが改善されるのか見えないのが現状だ。

それでそういう操作をする時には一時的にmdsが新規のインデックスを更新するのを止めておけばいちいちイライラしなくていいわけだ。
このアプリはなかなか良いアイデアだと思うし、そういう意味では今後に期待なのだが現状ではちょっとバグだらけで、私の環境ではまともに動かなかった。

どういうことかというとインデックスの生成を止めることは確かにできるのだが、そのまま止まりっぱなしで、再始動しても表示上は動いているような表示になるが実際にはmdsは二度と動かなくなる。
それでこのアプリはアンインストールしてしまったのだが、先日のメタデータ再生成でこの問題はクリアできなかった。
それ以来この問題を引きずっているのだ。
誰かこのアプリはちゃんと使えているという方はいらっしゃるだろうか？

SpotlessはボリュームごとにSpotlightのメタデータの更新を
停止するかインデックスを削除するかリフレッシュするかなどを操作できる
ちゃんと動けばなかなか便利そうなアプリだ

それでこういう問題のTipsが見当たらないか探していたらこちらのサイトを見つけた。
OS X ハッキング!第180回「Spotlightトラブル対策室」というこのページはちゃんとSpotlightが動かない場合のTipsが書かれている。

まず最初は
mds-crash-state
のケースで、これはmdsがクラッシュした時に生成されて、これがある限りメタデータ生成は阻害されるという。
これを削除するために
sudo rm /mds-crash-state
というコマンドか紹介されている。基本的にはルートボリュームの階層に生成されるはずだから 最初に
cd /
を実行していればそれでいいと思う。
ただ私は念のためにというか手っ取り早く
sudo find / -name "mds-crash-state" -delete
とやってしまった。

しかしこれでもう一度
sudo mdutil -E /
を実行したがやはり症状は改善しなかった。
このテストはいちいちメタデータを再生成しないといけないので有効かどうか結果が出るのに数時間かかるのが難点だ。

そこで例のOS X ハッキング!第180回「Spotlightトラブル対策室」さんのページをさらによく読んでみると上記の方法でも上手く動かない場合のTipsとしていくつかの方法があげられている。

まず
mdimport -L
というコマンドでSpotlightメタデータインポータに不具合を含むサードパーティ製のものが含まれていないか確認するという方法。
これを実行するとターミナルに現在有効になっているmdimporterのリストを表示してくれる。

mdimport -Lコマンドを実行すると現在有効なSpotlightメタデータインポータのリストを表示してくれる
このリストを見て原因になってそうな最近インストールされたものを探すのだが
残念ながらこれは該当するものがなかったようだ

このリストをチェックして不具合の原因になってそうなものをアンインストールするというTipsなのだが、見たが残念ながら原因になってそうなこの数日インストールされたものは見当たらなかった。
ということはやはり思い当たることが、的中してしまっているのか例のSpotlessの不具合が原因と考えた方がいいかもしれない。

それで後は最後の手段の「lsregisterで確認する」というこのサイトにあった最後の手段だ。

そのlsregisterのパスに移動するコマンドだがこのサイトには
cd /System/Library/Frameworks/ApplicationServices.framework/ Frameworks/LaunchServices.framework/Support
と書かれているがなぜか私の環境では「こういうディレクトリは無い」と反応されるだけでうまくいかなかった。
それでShow Hide Invisible filesという不可視ファイル、不可視領域も全てFinderで見ることができるようになるユーティリティを使った。

これで
lsregister
というコマンドのパスを探したところ別の場所にあったので以下の移動コマンドを実行した。
cd /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/
（このコマンドをコピペする時には要注意。改行コマンドが含まれているので一旦テキストエディタにコピペして改行を無くしてからTerminalに置いた方が良い）

ここに移動して以下のコマンドを実行するとmdimporterの登録データベースを再構築できる。
これまで積み上げてきたサードパーティ製プラグイン付属のmdimporterの設定は失われるかもしれないがとりあえず、初期状態には戻せるらしい。
./lsregister -kill -r -domain system -domain local -domain user

これでもう一度
sudo mdutil -E /
を実行して今結果を待っているところだ。
果たしてこれで初期状態に戻すことができるのかどうか、明日には結果が出ていると思うが。
といってもこれでダメだったらもうシステムの再インストール以外に対処法を知らないのだが・・・

＜後刻注＞
先ほど結果が出たようだが、やっぱりダメだった。新規ファイルをSpotlightメタデータに読み込むことができない。
これってアプリのテストでシステムを壊しちゃったという状態じゃないだろうか？
もうちょっと検証してみるが、今日はもう疲れた。
明日もうちょっと冷静になって考えてみる。

＜さらに後刻注＞
あれっ？治っているようだぞ！
今新規ファイルを生成したら数分時間はかかったが、ちゃんと画像サイズも表示した。
ということはこのやり方で正しかったということだろうか？
mdsのフルアップは３時間程度で止まったが、その後もまだSpotlightメタデータ生成は続いていて１２時間でやっと完成に近づいているということなのだろうか？

それにまだ新規ファイルが表示されるまで数分時間がかかる。
そういえばタイガーを最初に使い始めた時にこのタイムラグを見て「使い物にならネェな」と思ったものだがいつの間にか即時でインデックス更新されるようになっていた。
これも暫く我慢していたらそうなるのだろうか？
Spotlightに関してはまだわからないことだらけだ。

＜さらにさらに後刻注＞
どうやら治ったように見えたが治っていない。
スクリーンキャプチャをとってそのjpegを何時間置いていても、mdsはメタデータをインポートしない。ただToyViewerでリサイズするとすぐに「元ファイル」のサイズは認識する。
しかし別ディレクトリに作った新規ファイルはやはり読み込まない。
つまりメタデータインポータが全面的に動作不審になっているということだ。
これはしかし再起動をすることで問題が解決するかもしれない。
現在連続起動は８２日目に入ってきて、それが原因なのかはわからないが本格的な不具合がやっと出てき始めたということなのかもしれない。

＜結果、まとめ＞
結局このmds、lsregisterがちゃんと動いていないという不具合は、連続起動記録へのチャレンジを中断して、通常のメンテナンス手順を実行したら嘘のように治ってしまった。
正しい使い方をしていればこんな問題は起きないということだが、もし起きてしまった場合はこういう対処法もあるというTipsだ。
実際、通常のメンテナンス手順プラス半年に一回くらいの割合で
sudo mdutil -E /
のコマンドを実行すれば問題はまず起きないと思う。
ただ、mdsがなぜか最新の変更を読み込んでいないという場合には、上記の手順は使えると思う。

「全ては無駄だった・・・」なんて大仰な慨嘆調の文章を書いてしまったが、「そういう仕様です」ということ？〜Spotlight再構築ですぐにインデックスを作り始めないのは「そういう仕様」らしい

ここ数日、ちょっともろもろ動作が重くなって来ているように感じたので、ルーティンのメンテナンス。 その時にMainMenuで
「Spotlightのインデックスを再構築」
を実行、Spotlightもリフレッシュすることにした。
そうするとまたここの
「全ては無駄であった。あらゆる犠牲もあらゆる労苦も無駄だった。」~A.ヒトラー『我が闘争』より・・・じゃないがSpotlightクラッシュと格闘した二日間だった
で取り上げた同じ症状が再現。
mds、mdimporter、LAServerなどが動いていないようなので、一通りのメンテナンス手順と、このリンク先の対策をやってみた。
しかしやはり動いていない。

その対策を散々やっても、結局このリンク先と全く同じ症状を再現した。
どうにもならなかったので、しばらく放置して再起動。
するとあっさりSpotlightの検索窓が開くようになり、mdsなどのプロセスも快調にメタデータを読みにいっているようだ。

要するにこの問題の解決法は、CUIコマンドなどを使ってバタバタと怪しいファイルを初期化するようなことをしないで、一度深呼吸して再起動する・・・それだけで良いようだ。
不思議だ。
以前はmdutilコマンドでSpotlightを初期化するだけですぐに読み込みが始まってmds等がフルアップしていたが、今の仕様は一度再起動しないといけないようだ。

そういうことなら仕方がないが、そういうふうに変わったというお断りを一言欲しいなぁ。
おかげでシステムが壊れたのかと思って、その検証にのべで数日費やしてしまったではないか！
しかも大袈裟な慨嘆口調の文章を書いてしまったオレってバカみたい・・・
　　_, ._
（　ﾟ Дﾟ）

mds-crash-stateの削除など対策を講じるもmdsなどの
Spotlightインデックス生成のプロセスはうんともすんとも反応せず
またSpotlightが壊れてしまったのか・・・・

と思いきや、一度深呼吸して再起動をするとあっさり復活してしまった
メニューバー右端のSpotlightアイコンもあっさり開いて検索窓を表示
この「一息深呼吸」が対策のコツなのかも・・・