iTunesにID3v2タグを破壊される

去年の春から本格的に Mac ユーザとなった私ですが、新型 MacBook への乗り換えにともない MP3 も新しいマシンに移しました。

もともと Windows の iTunes で管理していたファイルを MacBook に移した段階で ID3 タグが一部化けたりしていて、ちょっとだけ困っていたのですが、 MacBook から新型 MacBook にファイルを移して iTunes に再度インポートしたところ、これまで大丈夫だったファイルまで多数文字化けしてしまいました。

面倒だったのでこれまで放置していたのですが、忙しい中の現実逃避がてら復旧作業にやっととりかかった、、、のですが、、、、

Perl モジュールの MP3::Tag をインストールしていじりはじめたところ、思ったよりも状況は深刻なことがわかりました。当初の想定では Windows 時代に作成した MP3 の ID3 タグが UTF-16LE ベースで記録していないのでバケているのだろう、だからインポート前に UTF-16LE にエンコードをかえてやればいいと思っていたのですが... 実際には、iTunes がバケた ID3 タグをファイルに rewrite してしまっていて、文字化けがどういう経緯でどうなったのか判断が不能な状態になっていました....

まあ手作業でタグをつけ直せる範囲なので(ライブラリ全体で3500曲ぐらい)、気がむいたときに気になるところから直していくことにします。なお、だいたい影響を受けているデータは2001年〜2003年頃にリッピングし、ちまちま手でタグをうっていた頃のファイルなどがメインでした。 MacBook 上の iTunes でリッピングしたファイルもいくらかおかしくなっていましたが.....

しかし、勝手に ID3 タグ書き換えられるのは正直困りますね。いや、最近はそんなことされても（心の奥底で否定しつつ）文句言わずに使ってあげるアポー信者として堕落した日々を過ごしているわけですが:)

時代は 802.11n なので...

先日、無線LANのアクセスポイントのファームウェアをアップデートしたわけですが、それ以後、実は新しい問題が発生してしまいました。

なぜか新 MacBook がレジューム復旧後にアクセスポイントに再接続できないのです。

アクセスポイント側を再起動すると解決することから、アクセスポイント側のソフトウェア的な問題だと思われます。とはいえ 2003 年頃の製品だけにアップデートもう期待できないので、あきらめて新しいものに交換することにしました。

悩んだ末、最終的に Aterm WR4500N を選定。 8,000 円をきる価格で入手できる 802.11n & b/g 対応アクセスポイントです。最初は WR8500N も検討したのですが

• ギガビットイーサポート ... でもそんなにたいしたスループットが期待できないからよくね？（クライアント的に）


• IEEE802.11a対応 ... X31 の頃は g 対応の無線モジュールが乗ってなかったから a つかってたけど、今は a 付き端末はあんまり使わないから、もう g でよくね?


• 300Mbps 対応 ... でも MacBook どうやら 150Mbps モジュールらしいよ?

などなど、ここでがんばって倍近い投資をしたところでなんのご利益も得られず、そもそもアクセスポイントも昔は2万以上出して買ってたわけですが、今時はアクセスポイントという製品群自体がずいぶん安くなったし、本当に高いスペックの製品がほしくなったらその時のハイスペック機に買い直せばいいやという結論にいたり WR4500N に落ち着きました。

今ってルータモードのほかにアクセスポイントモードってのがあるんですね。そのほかにも、最近の AP は設定項目などもすっきりしたように思います。6年ぶりに無線LAN親機の設定をして感動しました。

時代は 802.11n だけど....

ご無沙汰してます。ファームウェアアップデートには無頓着なブログ主であります。

新型 MacBook を購入しウハウハなワタクシですが、 MacBook-MacBook 間で大きなデータの転送をかけると、無線LANルータの WR7600H が死ぬので、久々にファームウェアのアップデートをかけてみました。

この無線LANルータはもともと 2003 年の ThinkPad X31 リリース直後に IEEE802.11a の無線LAN環境を構築するために購入したものです（当時、私の実家にはオレ専用の 802.11a と家族用の 802.11b の２つのAPがありました）。

アップデート前のファームウェアバージョンは 7.8 ぐらい。どうやら2003年上旬リリースのファームウェアのままこれまで動かしていたようです。一気に2006年リリースの最終版ファームウェアと思われる 8.6b へアップグレード。データ転送中にAPが死ぬことはなくなりました。

しかし今時のマシンだと IEEE802.11n とかいうヨクワカラナイ規格で、理論値150Mbpsとか電波到達距離200mとか意味がわからないスペックになってますね。今時は無線LANメインの生活だし、そろそろAP買い換えてもいいかな〜。

使用していないハードディスクを積極的にスピンダウンするには

24時間稼働させるサーバでは、ハードディスクは原則24時間稼働させなければいけません。しかし、ハードディスクは内部にモータやヘッドなどのメカを持っており、動かしておくということは電力の消費、発熱、騒音を発するということになります。

LinuxのATAドライバでは、 hdparm コマンドを利用すると、ディスクアクセスが少ないときに積極的にスピンダウンさせることができます。

/sbin/hdparm -S 60 /dev/sdb

制御対象のディスクは/dev/sdb, -S オプションのパラメータとして、スピンダウンまでのアイドル時間（5秒単位）を指定します。60を指定した場合、60秒*5=300秒、つまり５分間アイドルの状態になったらディスクをスピンダウンさせます。

実際には、ファイルやディレクトリの読み書き、アクセス時間(atime)の更新などさまざまな操作がI/O発生の要因になります。特にライト要求は、Linuxでは原則5秒ごとにコミットされるため、I/Oが発生してから5秒以内にスピンアップしてしまいます。スピンアップしてしまう要因をきちんと取り除かなければ、スピンダウンとスピンアップを繰り返しディスクを痛めることにもなり得ますので注意が必要です。また、経験上ハードディスクは回しっぱなしの状態が一番安定すると言えます。スピンダウンを積極的に行うこと自体がライフタイムに影響すると考えられます。このため、メリットとデメリットは意識した上で検討しなければなりません。


積極的なスピンダウンを行うためには、以下のような点を検討するとよいでしょう。

• ファイルシステムのオートマウントを有効化し、普段はアンマウント状態としておく


• アクセス時間(atime)の更新を抑制するために noatime オプションをつけてファイルシステムをマウントする


• ディスクの利用目的を明確化し、I/Oをコントロールする
  例１）バックアップ用ディスクは毎晩4:00にマウントし、バックアップ終了後アンマウントする
  例２）MP3プールをシステムディスクと分離しておき、オートマウントする構成にしておく
  
  例３）参照メインであれば、ライト操作を防止するため、普段は可能であればroマウントにしておく
  などなど...

Firefox 3 で、検索バーの結果は新しいタブに表示したい

Sleipnir をしばらく使っていた身としては、 Firefox 3 に乗り換えると気になるのが『検索バーでの検索結果が、今見ているタブに開かれてしまう』ことです。Slepinirでは新しいタブとして検索結果を開いてくれるのですが....

この挙動を変えるには、 about:config を開き、 browser.search.openintab を true に設定するとよいようです。

ただし、 Tab Mix Plus を有効化している場合は、アドオンの「タブを開く」タブページの中に、検索バーを新しいタブで開くためのチェックボックスがあります。


その他、デフォルトの検索バーの機能を置き換えるタイプのプラグインを導入している場合は、プラグイン側に設定がないか探してみるといいかもしれません。

邪魔なソフトウェアRAIDのシグネチャを消去する

ML110 G5 の Serial ATA ソフトウェア RAID など、 Linux dmraid で認識できる RAID を設定すると、たとえ BIOS レベルで RAID を削除しても dmraid がシグネチャを検出してしまい、 OS インストール時に支障が出ることがあります。

いちばんてっとりばやいのはディスクを /dev/zero で埋めてシグネチャを消してしまうことですが、これには時間がかかります。 シグネチャがディスクの終端にあることがわかっていれば、以下の方法でほぼピンポイントで dd をかければ解決です。

まず、ディスクの正確なサイズを調べておきます。

# fdisk /dev/sda

このディスクのシリンダ数は 19457 に設定されています。
間違いではないのですが、1024 を超えているため、以下の場合
に問題を生じうる事を確認しましょう:
1) ブート時に実行するソフトウェア (例. バージョンが古い LILO)
2) 別の OS のブートやパーティション作成ソフト
   (例. DOS FDISK, OS/2 FDISK)

コマンド (m でヘルプ): p

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes

...

ディスクのセクタサイズは 512 バイトですので、160041885696÷512＝31251808セクタ存在することがわかります。このディスクの終わりの部分だけを削除するには、以下のとおりコマンドを入力すると

dd if=/dev/zero of=/dev/sda bs=512 seek=31258100
dd if=/dev/zero of=/dev/sdb bs=512 seek=31258100

とすれば、3125100～31258107セクタの8セクタが/dev/zeroで塗りつぶされ、dmraidが勘違いするシグネチャを葬り去ることができます。

この操作は Anaconda をインストーラとして利用する Red Hat 系のディストリビューションであれば、インストール作業中の仮想コンソールから行えます。ただし、 dmraid の認識を解除するためには、作業後に一度インストーラをリブートする必要があります。

とりあえずLinuxをクラッシュさせる方法

Linuxで構築したシステムの動作検証などを行っている場合にシステムをクラッシュさせる方法としては、電源をブッチ切りするという単純な手もありますが、電源オフは稼働中のハードディスクが突然スピンダウンし障害の原因となります。代替となる方法としては、ほかにシステムをリセットするなどの手もありますが、最近のハードウェアでは必ずしもリセットボタンが付いていないため確実な手ではありません。

上記の代替として Linux では SysRq キーにより OS をクラッシュさせたりコアダンプを取得するための機能がありますので、これを使ってコマンドだけでクラッシュさせることができます。

# echo o > /proc/sysrq-trigger; halt -f
※echo する文字は オー（小文字)

この方法であればカーネルが即時クラッシュし停止するため（しくみについてはLinux日記2004: LKCD 診断（Mon Sep 27 2004）などを参照）、シングル構成のサーバだけでなく、SCSIなどで共有バスをもつようなシステムでも、予期せぬシステムダウンを再現できるなど有用です。