2013年8月23日

ファイルシステムを跨いでのファイルの移動にはmvを使ってはいけない

mv(1)は賢い。同じファイルシステム内のファイルの移動ならrename(2)を使ってディレクトリエントリだけを変更し、ファイルシステムを跨いだ移動ならまずcp(1)と同じ動作でファイルをコピーしてからrm(1)と同じ動作で元のファイルを削除する。便利だ。

しかし便利さに甘えてはいけない。

失敗例は、btrfsの一つのサブボリュームから別のサブボリュームにファイルを移動させようとしたとき。mvで移動を開始したがどうも遅い。簡単な計測をしてみると5MB/s程度の速度しか出ていない。SOHO向けのNASで、だ。

straceで調べてみると、ファイルをコピーする前に必ずrenameを実行して本来の移動だけですまないかどうか試して、ダメならコピーを実行する、と言うことを全てのファイルの移動に毎回行っている。一回にかかる時間は僅かかも知れないが、移動したいファイルは50万個ぐらいあるから無視できない。おまけに、コピーの実行には32KBという小さなバッファで毎回read(2)write(2)を呼んでいる。遅いわけだ。多分cpとかtar(1)で実際にファイルをコピーして元のファイルを削除した方が速かったと思う。

今回はbtrfsのサブボリューム間の移動だった。btrfsのサブボリュームはストレージプールは共有するが個別のファイルシステムとして動作する。だから、コピーによる移動は同じストレージプールにコピーして削除と言うバカ臭いことになる。

おまけにmvのコピーによるファイルの移動は、個々のファイルのアトリビュートは全ファイルをコピーし終わるまで確定しないようだ。

今回はストレージの空き容量容量が十分あったので全ファイルを一旦コピーしてからコピー元の全ファイルを削除と言う方法も取れたはずだが、空き容量に余裕がないときはファイルをスキャンしながら一つづつコピーしては削除と言う動作をするスクリプトでも書くか。

2013年8月13日

VMWare PlayerでCDからアプリケーションをインストールする

9年間使ってきたDellのデスクトップが操作できなくなった。このデスクトップは、我が家の家計簿や写真の加工、CADでの簡単な設計など私の仕事のかなりの部分をこなしている。数年前からは、仕事部屋に置かれた物理画面・キーボードに向かうことはなくなり、専ら居間のラップトップからターミナルサービスを通して使っている。国外旅行中もVPNで操作するなど、未だに現役のワークホースだった。

正確には、ネットワークが使えなくなった。このデスクトップにはネットーワークカード(NIC)が2台装着してあり、両方共動作しないので、ハードウェアの不具合ではなくWindows XPのネットワークスタックのどこかが吹っ飛んだらしい。HDDを含めて、購入後9年間ほぼ24/7で稼働してきたハードウェアはまったく故障なしに動作している。大したもんだ。

さて、このPCがないと日常生活が困る。特にQuickenを使った金銭の出し入れの記帳ができないのは致命的だから早急に何とかしなければならない。

しかしながら、もうこのPCはハードウェアがいつ壊れてもおかしくないし、Windows XPも来年でサポート終了ということなので、2年ほど前から考えてきたハードウェアとソフトウェアの双方のアップグレードを実行することにした。

旧マシン
  • Pentium 4 (2 threads) 3.0GHz
  • 4GB DDR
  • SATA 1.5Gb/s 180GB
  • Windows XP Pro 32bit
新マシン
  • Core i5 (4 cores) 3.2GHz
  • 8GB DDR3
  • SATA 6Gb/s 1TBx2 (RAID1)
  • Windows 7 Pro 64bit

OSは「仕事に使えるOS」であるWindows 7は当然としても、この際だから64bit版を選んだ。32bitから64bitへ移行するので、今まで使ってきたWindows XP 32bit版で動いてきたアプリケーションの一部が動作しないことが予想され、そして予想通りいくつかのアプリケーションはインストールできなかった。また、ネットワーク経由でいろいろなことをするので、必然的にProバージョンを選んだ(実は4年ほど前に構築した配偶者のPCは深く考えることなしにVista Home Premiumを選び、結果的に大失敗だったという苦い経験がある)。

「予想していた」ということは「対策を立てていた」ということで、VMWare Playerをつかって64bitのWindows 7上で32bitのWindows XPを走らせてみると見事成功!ここに32bitでしか動かないアプリケーションをインストールすれば、少々使いにくさはあるが新マシンで旧来のアプリケーションが使えるようになるはず。

VMWare Playerには、CD/DVDのようなリムーバブルの物理ドライブやISOメディアイメージファイルを仮想ゲストマシンのリムーバブルドライブ(E:やF:のドライブ)としてマップする機能があるので、これを使えばCDなどから仮想ゲストマシンにアプリケーションがインストールできる。

と思ったが、できない。一時ファイルを作れないというエラーが発生してインストーラが終了してしまう。


 この「C:\Documents and Settings\hiro\LocalSettings\Temp」というフォルダは隠しフォルダながら存在しており、手でファイルを作成できる。隠し属性を「見える」に変更しても変わらない。私はWindowsのACLとかにはまったく疎いのでどうしたらよいか分からない。

しばらく悩んだが、 解決方法は意外と単純だった。

インストール用のCDの内容をそっくり(ISOイメージではなくファイルレベルで)ローカルディスクにコピーして、そこでインストーラを走らせると難なくインストールできた。

複数のPCに同じアプリケーションをインストールするためにネットワークドライブにISOイメージをファイルに展開してもよいが、その時はネットワークドライブのファイルシステムがケースインセンシティブ(大文字小文字を区別しない)であることを確認すべき。アプリケーションのインストーラはケースの違うファイル名のファイルをコピーしようとすることはよくある(実ファイルは「abc.xyz」なのに「ABC.XYZ」をコピーしようとする)。ISOファイルシステムは規格上ケースインセンシティブなので問題はないが、これを別ファイルシステムに展開するとケースの判断はそのファイルシステムに依存するから。

また一つ障害をクリア!

Windows 7のスタートメニューをカスタマイズする

Windows XP、Vistaまではスタートメニューを右クリックするとWindows Explorerが現在のユーザのローカルスタートメニューのフォルダを開き、ここにサブフォルダやショートカットを好きなように作ってスタートメニューをカスタマイズできたが、Windows 7からはこれができなくなった。何でも「一部のユーザ」に多大な混乱を招いたからと言う理由らしいが、こういう「一部の」馬鹿ユーザのヘマのとばっちりを受けるのは、すべては自己責任と自覚している賢明ユーザだ。

Windows 7ではユーザに直接スタートメニューを編集させない代わりに「ピン」と言う機能を提供し、プログラムファイルのアイコンを右クリックして「このブログラムをスタートメニューに表示したい」と言うことができることになっているが、必ずしもすべてのファイルが「ピン」できるのではなさそうだし、メニューの階層のどこに表示されるようになるのかなど、何が起こるのかがさっぱり予測がつかない。

この「何が起こるのか予測できない」はWindowsに限ったことではなく、近頃のデスクトップのOSの馬鹿げた傾向のように思える。どうもOSの作者たちはユーザが何をしたいのかはユーザ自身よりも自分たちの方がよく知っており、それを先回りして実現することが「使い易さ」だという幻想を抱いているらしい。だから「コンテクスト何とか」という、ユーザにとっては不安定で何が起こるのか予測できないUIができ上がるのだ。

考え違いも甚だしい。PCを仕事で使っているユーザは自分が何をしたいのか100%知っており、100%自分でコントロールしたいのだ。

話を戻して、「ピン」は本当に使いにくい。Vistaまではどんなファイルでもタスクバーにドラッグすれば「クイックローンチャ」が作成でき、しかもそこから起動されるタスクのタブとは別だったから、例えばブラウザを別ウィンドウで立ち上げなんてことがすぐできたが、「7」のタスクバーのピン機能はアプリケーションに限られ、しかもタスクタブと重畳されるのでとても使いにくい。Windows NT → Windows XPまでは世代ごとに使い易くなったのに、Vista以降はどんどん使いにくくなってきている。いったい何を考えているのか?

前置きが長くなった。

Windows 7の「All Programs」は、「C:\ProgramData\Microsoft\Windows\Start Menu\Programs」 というフォルダそのものである。ここに手作業でフォルダやショートカットを作ったら、ちゃんとスタートメニューの「All Programs」に反映された。パスからして、全ユーザに共通のスタートメニューを扱うようだ。


ついでに、ユーザ固有のクィックメニュー(「start」をクリックすると最初に現れるプログラムリスト)の「ピン留め」されたプログラムは、「C:\Users\xxx\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\StartMenu」フォルダの中のショートカット。「Roaming」だの「Internet Explorer」だの意味不明のパスエレメントがあるが、気にしない。

当然のことながら、フォルダの中身をいじってメニューをカスタマイズするときはくれぐれも慎重に。私のやらかした失敗は、「Administrative Tools」というフォルダ(中身は実行プログラムファイルへのショートカット) を捨てたら、スタートメニューの右側の「Administrative Tools」の中身も消えてしまったというアセリもの。実はスタートメニュー右側の「Administrative Tools」は実質的には「C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools」フォルダへのショートカットに過ぎないようだ。捨てたフォルダとその中身は幸いゴミ箱の中にまだそっくりそのまま残っていたので、復活して事なきを得た。

2013年8月4日

マザーボードの交換

ファイアウォールに使っているサーバが死にかけた。

突然フリーズするようになり、電源再投入すると再起動してしばらく順調に稼働するものの、数時間後にはまたフリーズする。/var/log/messageを見ても何ら情報はなく、ただただフリーズしているので、4年前に中古で買ったマザーボードの寿命と考え、新品と交換することにした。それまではwebpowerというネットワーク電源スイッチでpingで監視して自動電源再投入でしのぐ。

新しいマザーボードは近所のFry'sで一番安かったASUS製。
  • CPU: Celeron Dual Core 2.7GHz
  • Memory: DDR3 2GB x2 (=4GB)
  • Slots: PCIe x1, PCIX x1, 32bit PCI x2
  • PS/2: Mouse, Keyboard (separate)
  • VGA
  • 6Gb SATA x1, 3Gb SATA x5
古いマザーボードはPentium 4 (2.8GHz シングルスレッド)+ 2GBだったから、かなりのスペック向上である。メモリは本当は2GBで十分なのだが、今どき1GBのDDR3は売っていないので2GBのチップを使い、スピードを多少稼ぐためデュアルチャンネルメモリを選択で x2になった。32bit PCIは、手持ちのCaller ID用のモデムカードと二番目のNIC(ファイアウォールなのでLANとWANの両方が必要なのだ!)に必要。HDMIだとかSPI/Fだとかのマルチメディアポートもついているが、サーバには全く関係ない。PS/2のマウスとキーボードが付いているのは、10年前から使っているPS/2用KVMスイッチが使えるので助かる。HDDは当然稼働中のものを使う。

マザーボードの交換は神経を使う。稼働中のインスタレーションとの互換性が心配なのは以下の点。
  • SATAコントローラ
  • ビデオチップ
  • NIC(イーサネット)

いきなり稼働中のマザーボードを交換するようなせっかちはせずに、まずは裸の状態でテストして問題点を解決してから交換、と言う手順で行う。テストには別のマザーボード用に作ってあった(稼働することが証明されている)RAID1のインスタレーション(交換先と同じFedora 13)を使う。

ブートしない!

最初の躓きは全くブートしないこと。BIOSにも到達せず、何も動かない。「さてはCPUの装着時にピンを曲げたか?」と何度も点検するが異常なし。最終的には(当然のことながら)自分のチョンボと判明。電源スイッチ代わりにATX電源コネクタの緑と黒をショートしていたのが誤りで、フロントパネル用コネクタのピンを使うことで解決。

 電源コネクタの方法は他のマザーボードでは上手く行っていたのに、このマザーボードでは電源は入りCPUファンなども動き始めるのにそれ以上進まなかった。違いと言えば、他のマザーボードでは緑と黒のショートはモメンタリで電源投入後はショートを外しても投入されたままだったのにこのマザーボードではショートを外すと電源が切れてしまったこと。まぁインチキはいけませんね。

ルートデバイスが見つからない!

BIOSが走り、HDDを繋ぐとLinuxがブートし始める!SATAの問題はなさそう(SATAでトラブったことはないが…)。

ところがブートの段階で「ルートデバイスが見つからない!」というエラーで固まってしまう。ブートの進行状況のバーが伸び行く時にAlt+DでブートRCファイルの進行状況メッセージが表示されるはずなのだがそれができない。「さてはビデオの互換性の問題か?」とオンボードのVGAの代わりにPCIにVGAカードを挿してみるが同じこと。

仕方がないので、もう一度BIOSの設定をくまなくチェックする。試しにSATAの設定をデフォルトのIDEからAHDIに変えたらあっさり動いた。二つ目クリア!

NICが動かない

デスクトップが立ち上がり、ターミナルウィンドウを開いてifconfigを実行してみるが、ループデバイス(127.0.0.1)しか動いていない。SATAとビデオの問題とは違い、こちらは予想していたとおり。

まず、lspciを実行してNICデバイスがカーネルに認識されていることを確認。これはOK。

次に、/etc/udev/rules.d/70-persistent-net-rulesの日付をチェックすると更新されており、このファイルを内容を見ると、eth2eth3という新しいデバイスが追加されている(このマザーボードには、オンボードとPCI32スロットの二つのNICがついている)。これらが新しいマザーボードで使えるNICなので、これらのエントリを基に新しいマザーボード用のネットワークスクリプトファイルを作る。

RedHat/Fedora/CentOS系のディストロでは、ネットワークデバイスは/etc/sysconfig/network-scripts/ifcfg-***(「***」はネットワークデバイス名、「eth0」「eth1」など)というファイルに記述されているので、先ほどの/etc/udev/rules.d/70-persistent-net-rulesの情報とlspciの出力(NICのチップなどのコメントのみ)でifcfg-eth2ifcfg-eth3のファイルを作成し、「ifup eth2」を実行してみるとネットワークがつながった。

もう一度整理すると
  • /etc/udev/rules.d/70-persistent-net-rules
  • /etc/sysconfig/network-scripts/ifcfg-***
の二つのファイルの内容が一致するように
  • デバイス名(eth0eth1、…)
  • MACアドレス
を新しいハードウェアに合わせて修正してやる。

eth0eth1を修正したら、ブート時からこれらのインタフェースが使えるようになった。

h@spice:~$ cat /etc/udev/rules.d/70-persistent-net-rules
(一部省略)
# PCI device 0x1011:0x0019 (tulip)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:c0:f0:4c:e6:78", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
 
# PCI device 0x10ec:0x8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="60:a4:4c:b5:26:48", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"


h@spice:~$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 09)
DEVICE=eth0
BOOTPROTO=none
HWADDR=60:a4:4c:b5:26:48
TYPE=Ethernet

(一部省略)

h@spice:~$  cat /etc/sysconfig/network-scripts/ifcfg-eth1
# Digital Equipment Corporation DECchip 21142/43 (rev 41)
DEVICE=eth1
HWADDR=00:c0:f0:4c:e6:78

TYPE=Ethernet
(一部省略)

h@spice:~$


明示的に「NAME=」が示されていないときは、eth0から順に名づけられるようだ。

さぁ、これで主要な問題は解決済だ。起動して24時間を過ぎて、今のところ新たな問題は見つかっていない。上手く行ったようだ。