Swapファイルの大きさが劇的に小さくなっていたが、いつの間にか元通りに戻っている。

それで調べた結果OSXでのSwapはこういう原則で運用されていることがわかった。

これまで特にタイガーになってからはSwapfileの大きさは最初の１個は64MBだったが
１個目　64MB
２個目　64MB
３個目　128MB
４個目　256MB
５個目　512MB
６個目　1GB
７個目　1GB
というように等比級数的に容量が増えていくということをあちこちに書いた。特に６個目以降は1GBずつ増えるのが、初めてタイガーを触った時にはびっくりしたのだが、なぜか先日Swapが９個に増えても256MBずつしか容量が増えないという現象が起きていた。

これが不思議だと書いたところSwap容量の規定は
１）メモリの最大容量
２）ハードディスクのSwapVolume残り最大容量の４分の１
３）1GB
のいずれかの小さい方を上限とするというルールで運用されている

という情報をいただいた。
だからメモリにアロケーションができているか、ハードディスクの残り容量が4GBを切ったからそうなったのではないかという書き込みをBBSにいただいた。
ところが私の場合はこの原則に当てはまらなくてメモリは1GB認識しているし、テストも問題なかったので認識できないアロケーションも無いようだし、ハードディスクの残り容量は11GB以上あった。
こういう原則でSwapが運用されているというのは指摘されるまで私も知らなかったのだが、そうであるにしても私の場合は当てはまらない。

ところが先日こういう記事を見つけてしまった。
これは「OSXではデフラグが必要ない」という趣旨の記事で、なぜデフラグが必要ないかと言うとフラグメンテーションができないように予防措置がとられているということを書いているのだが、そのうち以下の記述に注目した。

『ハードディスクの容量は、一般に数年前よりも遥かに大容量になっています。利用可能な空き容量が大きくなったので、ファイルシステムは「隅から隅まで」すべてを使用する必要はありません。Mac OS 拡張フォーマット (HFS Plus) 方式では、空いたばかりの小さな領域をすぐに利用することを避けて、削除されたファイルの領域を再利用することはできる限り避けます。』

OSXのHFS＋というフォーマットはこういう原則で運用されているというのだ。
実は先日Swapの容量が変化した時、その直前にビデオの整理をしてビデオファイルをディスクに読み込んで一時的に起動ボリュームがほぼいっぱいになるまで書き込みをした。
もちろんそれは一時的にそこに置いただけなのですぐに削除したのだが、OSは『削除されたファイルの領域を再利用することはできる限り避け』るという原則に基づいて、ハードディスクの残り容量が僅少であると判断したようだ。
だから実際には１１GB以上の空き容量があるにもかかわらず、Swapの最大容量を256MBに制限してきたということらしい。

私は空き容量の領域に何かファイルが上書きされて、空きスペースがアロケーション化したのかと心配したのだが、それ以降の上書きしたファイルは全部消していたのにそういうことが起こるのかと、半信半疑だった。
これは結局アロケーションとかではなく、そういうHFS＋の原則によるものらしい。

だから心配することはないし、、実際時間が経って私のOSのSwap容量は元に戻ってしまった。それにOSXのSwapはこういう柔軟な運用のされ方をしているのだということを知ってちょっと惚れ直したような感じだ。
こういうのは「アンコントローラブルだ」として、UNIXファンダメンタリストからは批判を受けてしまう部分かもしれないが、Macの場合大部分のユーザはUNIXのオーソリティにはならないわけだから、そういう人たちにも難しい教育をして設定をしてもらうということ無しに大抵の場合に対応できる自動機能が組み込まれているというのは良いかもしれない。

ちょっと不満なのは『Swapについてもこういう丁寧な説明をアップル自身がしてくれよ』というところか。
Swap容量をどうやって決めれば良いのか、起動ボリュームにはどれくらいの空き容量が必要かということは、初心者ユーザにとっても無関係なことではないからだ。

Swapfileの容量が最大256MBになってしまったということを先日書いたが
いつのまにか元に戻って1GBのどでかいSwapができるようになった
今日も元気にでっかいSwapを作り続けている（？）

いつからかわからないけどSpotlightがメニューバーから使えなくなっている。

Spotlightのベースになっているmdimporterなどがクラッシュして検索が最新の状態を反映していないとかそういうトラブルは今までにも経験していたが、今回はそういうことではなく、メニューバーにあるSpotlightのアイコンをクリックしても検索窓が開かなくなってしまった。

mdsが暴走しているわけでは無い。
"/private/etc/hostconfig"
を開いてみてもちゃんとSPOTLIGHT=-YES-になっている。
Finderの検索窓からはちゃんと検索はできている。
要するにメニューバーのアイコンに表示されているSpotlightだけが不具合なのだ。
こういうケースが他にあるかググって見たが同じようなトラブル事例は見当たらない。
どうやらかなり珍しいトラブルに巻き込まれているようだ。

先日いつからかわからないがiCalのカレンダー、アドレス帳がiPodにシンクできなくなっているということを書いたが、どうも最近システムをアーカイブ化インストールしてから微妙に調子が悪いようだ。
インストールしたての頃はサクサク動くのでこのままずっと使えるかもと期待したが、やっぱりこのアーカイブ化インストールって緊急避難なのかもしれない。
ちょっと憂鬱だけど近日中に新規インストールということも考えた方が良いかもしれない。

もっともSpotlightなんてメニューバーの検索はまず使うことがなくて、使っているのはFinderの検索窓だけだからこれが動かなくても全く困らないのだが。
しかしメニューバーは混み合っているので、このメニューバーアイコンだけでも消せないものかなぁ。

と思ったらMac LightというメニューバーからSpotlightアイコンを消すというユーティリティを今試してみたところ、このアプリ自体はちゃんと機能しなかったのだがなんとSpotlightのメニューバーアイコンからの検索窓プルダウンがちゃんと開くようになった。

このアプリは使えなかったので削除したが、Spotlightが動くんだから無理矢理アイコンを消すこともないだろうということで、納得することにした。
しかしシステム環境設定ペインのSpotlightのページから設定がきれいに消えてしまった。
一体どうなっているんだろう？

ものすごく不調というわけでもないが、何となく腑に落ちない動作が多いのは気持ちが悪い。

＜追記＞
この問題は実は自然に解決した。
詳細はこちら、 Spotlight再構築ですぐにインデックスを作り始めないのは「そういう仕様」らしいで詳述したがmdimporterがリセット後すぐに動かなくなったのも、リセットしてしばらくはメニューバーアイコンからSpotlight検索ウインドウが開かないのも、そういう仕様ということらしい。

こういう問題が起こっているそうだ。

一言で言えばAppleがDashboard Widgetの正当性を確保するために『ユーザーのデスクトップウィジェットを特定・認証するAppleの機能』が追加されたという問題だ。

これが新たな個人ユーザ情報の収集に悪用されないかとかいう懸念が出ている。
またAppleに悪意がなかったとしてもWindowsのWGA問題のようにそれが悪意ある第３者によって悪用される可能性も無いと言い切れるのかという問題も残りそうだ。
しかし何よりも最近のニュースの中でこれが一番腹立たしいのは、Appleがそれをやっちゃいかんだろうということだからだ。

私がなぜMicrosoftが嫌いかというとその理由は両手の指でも足りないくらい挙げられるのだが、Windowsのアクティベーションとか、超ローカルルールの通信認証規格によって個人のプライバシーが踏みにじられまくっているというWindowsの規格を数の暴力を背景に押しつけまくっているという構図こそその最大の理由なのだ。
だから私個人の家にはほぼWindowsを入れないし、入れるならネットワークには絶対に繋がないというつもりでいる。

ところが頼みの綱のAppleまでがMicrosoftと同じようなことをやっているんじゃ話にならない。
最近のAppleはiTunes、iPod以来息を吹き返してきているのはご同慶の至りなのだがそれで良い気になって第２のMicrosoftを目指しているんなら勘違いも甚だしい。
これはなんとしても改善してもらいたい問題だと思う。

この頭に来るトンチンカンなMacOSの仕様を無効にする方法はいくつかあるようだが、一番簡単な方法を紹介しておく。

この『ユーザーのデスクトップウィジェットを特定・認証するAppleの機能』というおせっかいかつ不快な機能は

"/System/Library/CoreServices/Dock.app/Contents/Resources/fetchadvisory"

このDockのリソースの中のUNIX実行ファイルによって実行されている。
この.plistファイルが

"/System/Library/LaunchDaemons/com.apple.dashboard.advisory.fetch.plist"

ここにあるのだが、このfetchadvisaryがこのdaemonの正体でこの.plistファイルをテキストエディタなどで開くと ２８８００秒ごとにこのfetchを起動するように設定されているのがわかる。
なので一番簡単な方法は、キャプチャーのようにこの.plistファイルに最後の２行の

こうすることでこの設定項目は無効になる。
（fetchadvisory本体を削除することが可能かどうかも調べてみたがよくわからない。なんせDockの中にあるリソースなので、どんなトラップがあるかわからない。可能なような気がするがその検証はもう少し時間をかけたい）

問題のfetchアドバイザリのdaemonの設定ファイルを開くとこんな文面が見える
無効にするのは最後の２行を書き足すだけで良い
（昨夜上げたキャプチャーは追加の位置を間違えていた、こちらが正解）

ちょっと思いつきなのだが、この28800というstringのあとに0を5個ぐらい書き足しておくという手もある。
人生３万日ということを思えば、ここに0を５つも書き足しておけばあなたがこの問題に煩わされるのはあなたがこの世からいなくなったあとの話だ。私がこの世から去ったあとに私のiBookがどんなに不振な挙動をしても、私にとってはどうでも良い。これが最もシンプルかつ有効な対処法のような気がしてきた。

これにTerminalで

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.dashboard.advisory.fetch.plist

というコマンドを実行させて、読み込みをさせないという設定をあわせてやれば確実だ。

(追記：このコマンドは上のdisableの追記とどちらかをやれば良い。ということはこの下の続きの記事にちゃんと書いているのだが、最後まで記事を読まないどっかの馬鹿が勝手に勘違いして、それで関係ないトラブルをこれのせいにして、あげくの果てにそのレスで尻馬に乗った別の馬鹿が「アドバイザリで騒ぐ連中は根拠を明らかにせよ、Appleは信頼できるお巡りさんだから守ってくれるんだ」なんて腑抜けみたいなことを書いているサイトを見つけてしまった。根拠はここに書いた。字が読めないなら質問するな！)

Terminalでこういうコマンドを実行する
これはシステムが定期的に行っている作業を止めさせるというコマンドライン

これをスクリプトシェルで実行するアプリも発見したのだが、なぜか動作が意味不明でちゃんと効いているのかどうかわからない。
アプリに頼るよりも自分でコマンドを打った方がこの場合は確実だろう。

昨晩のこのシェルコマンドをさらに検証したところ、この

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.dashboard.advisory.fetch.plist

というコマンド自身が

"/System/Library/LaunchDaemons/com.apple.dashboard.advisory.fetch.plist"

に

例のコマンドを実行するだけでこの文字列は.plistに追記される
しかも一番頭に追記されていたので私が気づいていなかっただけだった
またも凡ミス失礼しました

起動ボリューム以外のボリュームの中身の索引が不完全だということが判った。

速い話がファイル置き場のボリュームのファイル名をそのままコピーして、Spotlightの検索窓にペーストしても
「何も見つかりません」
というだけだ。
メタデータどころかファイル名そのものズバリで検索しても見つからないというのは、やはり異常な動作だということだ。
そこで再度メタデータ索引を再生成させることにした。

上記のシステム環境設定ペインのSpotlightでプラバシー設定で全ボリュームを指定して解除するだけでなく、Terminalを使って索引ファイルそのものを完全に削除することにした。
「挙動が不振な時には徹底的にクリアする」
これも長年Macとつきあってきた経験則だ。

そのTerminalコマンドだが、・・・忘れちゃいました。（ヲイ！）
ていうか、そのメタデータ索引ファイルの場所も忘れてしまっている。
しかしこういう時のための共闘サイトである。
当サイトトップページの『OSX急進派』のアイコンのリンク先、Hiroさんのサイトには充実したUNIXコマンドのカンニング集・・・もといTIPS集がある。
Terminalコマンドがわからない時にはとりあえずここを覗けば良い。

覗いてみれば早速見つかったのが
mdutilというコマンドだ。
メタデータをいろいろいじるコマンドはこれと引数の組み合わせでできるようだ。
しかもメタデータ索引をリセットするというそのものずばりのコマンド文字列もちゃんとここに書いてあった。

mdutil -E /var/vm/private/var/vm

早速これをTerminalで実行してみた。
Hiroさんは「ルートにならないと実行できない」と書いておられたが、そうはいってもsudoでできるんじゃないかと思ってトライしてみたが、
「ルートでないと実行できないよ」
というアラートがきっちり出てしまった。

どうやらこのメタデータ関連の扱いは結構システムの重要部と位置づけられているみたいで、sudoなんていう仮設ルートは受け付けてくれないらしい。

それでまず
sudo passwd root
を実行してrootを有効にしてこのコマンドを実行してみた。

Spotlightの索引データを削除するコマンドを実行してみた
しかしそんなファイルは現存しないというアラートが

その結果がこのアラートなのだが、結論からいうと例の
「システム環境設定ペインでプライバシーで全ボリュームを指定して解除する」
という手順でもやはり索引データはきれいに削除できるようだ。

それでもう一度およそ１時間かかって索引データを再生成したのだが、今度はうまくいった。
先ほど検索にかからなかったファイル名が今度はちゃんと検索にかかるようになった。
結局結論的にいえるのは、Spotlightのメタデータ索引の生成は結構失敗することがあるということだ。

そして失敗したらGUIでもTerminalでも良いのだが、結局はリセットして一からやり直す以外に方法はないということだ。うまくいく時といかない時の違いもよくわからない。
つまり時の運ということだ。
う〜ん、ええかいな？
これでトラブルシューティングになっているのかな？

＜後日譚＞

先日Spotlightの挙動不審を解消するためにTerminalをつかってメタデータ索引ファイルのリセットを行うという記事を書いたところ、BBSで「Rauf」様からいくつか間違いの指摘をいただいた。
それで昨晩早速検証をしたので、その結果を書く。

まずSpotlightの索引データの本体の位置だが、
「ボリューム直下の『.Spotlight-V100』ではないか」
とのことだが、これは確認した。
Coelaで見てみると確かに『.Spotlight-V100』という不可視フォルダがあって、しかもこれはシステム所有になっていて、一切アクセス不可というアクセス権で守られている。
これがビンゴと見た。
逆にHiroさんの記述にあった
/var/vm/private/var/vm
という場所はディレクトリそのものが存在しないことも確認した。
これはどういうことかわからないが、OSXの仕様が変更されたということじゃないかと想像する。
OSXはこういう重要ファイルのディレクトリの変更なんてしょっちゅうやっているからだ。

BBSの指摘に従ってCoelaで確認すると確かに
『.Spotlight-V100』という不可視フォルダが存在する

それでこれをリセットするコマンドだが
sudo mdutil -E /
で良いのではないかというご指摘だったが、確かにその通りだった。
これは起動ボリュームの索引データをリセットするコマンドで、それ以外のボリュームをリセットしたい場合は
sudo mdutil -E /Volumes/（リセットしたいボリュームの名前）
を実行すれば良い。
これも動作を確認した。

またこれを実行する場合、いちいちsuコマンドでルートにならなくてもsudoの仮設ルート権限で実行可能だということも確認した。

起動ボリュームとパーティションを切ったボリュームの
それぞれをリセットするコマンドを実行した
この通りルートにログインしなくてもsudoで実行可能だった

そしてコマンド実行の直後Spotlightがおなじみの索引作りのフルアップをはじめた

またシステムログにもコマンドが実行された記録がちゃんと残った

そして一夜明けた結果をいえば、Spotlightはちゃんと動いている。あちこちのボリュームやディレクトリのファイル名を抜き出して検索をかけているが昨日のように、検索できないという症状は起きていない。

それでこれもメンテナンス項目に入れる必要性をちょっと感じた。
そんなに頻繁にやる必要はないだろう。半年に一度とかそんな頻度で十分だと思うが、このコマンドを実行してメタデータ索引ファイルもリセットするべきだと思った。

情報をいただいた「Rauf」さん、ありがとうございます。

＜さらに後日譚＞

先日の訂正記事についてさらに「Rauf」様から間違いの指摘並びに、補足があったのでこちらにも書いておく。

まず最初の勘違いだがHiroさんの記述にあったmdutilのコマンドは

mdutil -E /var/vm/private/var/vm

ではなく

mdutil -E /var/vm

だった。

/private/var/vm

はシステムからの応答で、原文では改行して表示されていたのだが、私がこれはhtmlの改行表示だろうと勝手に解釈して

mdutil -E /var/vm/private/var/vm

としてしまった。
だからそんなディレクトリなど存在しなかったのだ。
Hiroさんは/var/vmに別パーティションのSwapボリュームを設定していたので、そのボリュームのmdsの作成ファイルをリセットする文字列を掲げていたのではないかという指摘もその通りでした。
「ちゃんと説明を読めよ」
と、ちょっと反省してしまった。

だから結論からいうとどのボリュームであろうとそのボリュームの第一階層にmdsの索引ファイルは作成されるわけだから、結局パスはそのボリュームのパスを指定すれば良いというシンプルな結論になる。
つまり起動ボリュームの索引ファイルをリセットしたい場合はやはり

sudo mdutil -E /

ということになるし

パーティションを切ったボリュームの場合は

sudo mdutil -E /Volumes/*

ということになる。

これが最終的な結論だ。
また参考資料として教えていただいたリンク、
　　Spotlightまわりのコマンド
　　　http://journal.mycom.co.jp/column/osx/133/
　　　http://journal.mycom.co.jp/column/osx/134/
　　メンテについて
　　　http://green.ap.teacup.com/hiromu/111.html

は大変参考になった。
Spotlightの挙動不審にはやはりこのコマンドを実行して索引ファイルのリセットが有効ということだし、メンテナンスの手順として取り入れ得るのも合理的だという気がする。

またmdsの初期設定ファイルというに近い
"~/Library/Preferences/com.apple.JapaneseAnalysis/AppleContextualKKC.index/AdaptiveMap"
"~/Library/Preferences/com.apple.JapaneseAnalysis/AppleContextualKKC.index/InputHistory.plist"
を削除するというのも有効だという情報もはじめて知った。
これは次回は参考にさせていただこうと思う。

「Rauf」さん重ね重ねありがとうございました。