「これからはRELEASEだけで生きていこう!!」と誓ったのもつかの間、7-STABLEで ZFS version 13 になったのに釣られて STABLE にしちゃいました(笑)。でもって zpool upgrade -a。プールをimportした状態でアップグレードできるので、なんともあっけなく作業は終了しました。
toriyu# zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 83.8G 374G 25K /tank
tank/iscsi 33.3G 374G 20.7G /tank/iscsi
tank/root 353M 374G 270M legacy
tank/swap 624K 375G 624K -
tank/usr 10.3G 374G 5.15G /usr
tank/usr.home 3.73G 374G 3.19G /usr/home
tank/usr.ports 1.56G 374G 263M /usr/ports
tank/usr.src 474M 374G 296M /usr/src
tank/var 9.92G 374G 9.70G /var
tank/var.smb 23.1G 374G 20.3G /var/smb
さて、これはupgradeには関係ないのですが、7.2-RELESEから7-STABLEにしたことで、zfs list からスナップショットが消えました。一瞬焦ったのですが、実は消えたのじゃなくて表示されなくなっただけ。zfs list -t all などで従来どおり表示されます。何も指定しなかった場合には '-t filesystem,volume' 相当の動作になるようです。普通に考えてスナップショットを常時表示する必要はないですからこちらのほうがありがたい動作ですね。
そして次はアップグレードの恩恵をば・・・ということで下記のコマンドを入力してみました。
# zfs send -RI 過去のスナップショット tank@スナップショット | ssh toriyu10 "zfs receive -Fd tank"
バックアップマシン(toriyu10)にZFSプールツリーの差分を全部送りつけて、送った先でまんまと再構築する・・・ことを期待していたのですが、そううまくはいきませんでした(笑)。どうなったかというと、過去にバックアップしたファイルシステムが消えてしまって、'recv-891-2' 等という名前で置き換えられたファイルシステムがいくつか発生しました。転送元にあったスナップショットが再現されていたので、これは転送された中身なのでしょう。再帰的にzfs sendするとスナップショットがあったりなかったりした場合にどうなるのかな? というのが疑問だったのですが、これまた厄介な動作をしてくれるのですな・・・。まっさらなプールに転送するなら良いのですが、差分バックアップに使うなら従来どおりチマチマとシェルスクリプトを用いて転送するのが安全っぽいです。
なお、これもupgradeは関係ないかもしれませんが、バックアップ先の512MBしかメモリが無いマシンではzfs receiveで受けてる最中に必ずコケるようになってしまいました。これまで /boot/loader.conf に
vfs.kmem_size="256M"
とだけ書いたシステムで長いこと毎日バックアップできていたのですが・・・。でも aoyama さんに習って
vfs.zfs.arc_max="40M"
vfs.zfs.vdev.cache.size="5M"
vm.kmem_size_max="384M"
vm.kmem_size="384M"
としてみると、ちゃんと動くようになりました。ぱちぱちぱち。てゆーかよく今まで動いてたものだ(^_^)。
今後は make world 時にはもとより、緊急時にUSB-HDDなどからブートする場合でも7.2-RELEASEのCDでインストールしただけのシステムではプールがimportできないでしょうから、ちゃんと覚えておかなくてはなりません。最近はDVDから起動してFixitというが楽ちんメンテナンス方法が取れるようになったのですが、その方法は7.3-RELEASEが出るまでお預けです。
いろいろ遊んでみて仮想化はうちには向いてないということがわかりましたので、500GBのHDDは素直に自宅サーバにくっつけてあげることにしました。もはやESXiの導入は無いので、RAIDカードは新調せずに ZFS mirror です。
# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
tank 465G 59.3G 406G 12% ONLINE -
いやはや、今まで160GBだったのでなんとも広々です。実はお絵かき機をiSCSIブートしようと試みたのですが、残念ながらVistaのiSCSIブートはうまくいきませんでした。単純にパーティションを持っていっても起動途中でブルースクリーンになるのですが、修復セットアップをしようにもDVDのインストーラがiSCSIドライブを見つけてくれませんでした(T^T)。
ちなみに、うちのサーバは起動用USBメモリ(UFS)に /boot を入れた ZFSルートとなっているのですが、160GB→500GBに入れ替えてみて気がついたことなど。
- HDDを入れ替えることを考えると、やっぱり /dev/ad0s1d とかで指定するよりも /dev/ad0 のほうが扱いやすい
- ZFS mirror な構成からミラードライブを一つ引っこ抜いて起動しても、zpool status の結果がエラーになっているだけで、FreeBSDの動作には支障が無い
- それどころか、ad0に刺さってるドライブをad4とかにつなぎ変えて起動しても問題なく動く
- だからPCを置き換える場合はUSBメモリとHDDを移植してBIOSの起動順さえ合っていれば正常に動く
- 160GB→500GBに交換する際は 500GBをattach後 160GBをdetach したが、detach後も全体容量は変わらなかった。が、再起動すると500GBになっていた。
- zpool detachに成功したドライブの中身は復活できないみたいだけれど、zpool destroy したドライブやZFSミラーの状態で取り外したドライブなんかは zpool import でごにょごにょやればなんとか復活させられる。
というところ。ML110G5のSATAインタフェイスはホットプラグに対応していないのでどうしてもシステム停止が伴うのですが、停止時間は物理的につなぎかえるための時間だけなので極めて短くて済み、zpool replace
はサービス提供中でもまったく問題ありません。対してUFSでのハードディスク増量では安全を期す場合、dump/restoreの間中停止しておかなければなりませんから停止時間は1～2時間では済まないこともあります。実績とか少ないメモリで動くとか、UFSにもメリットは存在するのですが、ZFSは一度使ってみるとやめられませんな。
最近 では ZFS Boot にも対応しているようですし(MBRはどうなるのだろう?)、あとはDVDのインストーラが対応してくれればZFSの敷居はぐんと低くなりそうですね。
昨日のESXiの実験ではVMWareが悪いのか試験機が悪いのかイマイチ判断がつきません。なので実際にVMWareを動かす事になる Proliant ML110G5
を使って実験しました。でも結果はやはりNG。ddでの転送試験はやはり15MB/sぐらいしかでません。ただ、同じ事を繰り返すと何故か50MB/sぐらいに上がったりします。なにか条件があるのかもしれませんが、istgtでiSCSIで実際に使ってみると2分ぐらいで終るはずのファイルコピーに4分50秒かかりました。また、Windows Storage Serverを入れてiSCSI Software
Targetを使うと同じ作業に10分44秒を要しました。VMWareは仮想PCをホイホイ作れるところは良いと思うのですが、我が家で使う場合は普通にFreeBSDを走らせた方が扱いやすくパフォーマンスも段違いのようです。
てことで、気を取り直してiSCSIのベンチマーク試験です。今は自宅サーバの機能を一時的に安物ベアボーンPCに移しているので ML110G5が自由に使えます。同容量のHDDも2台ありますから、Windowsから見た時のストレージとしてiSCSIはどうなのか、iSCSIを保存するファイルシステムは何が良いのか、というところを測定してみました。
測定項目は下記の通り。
- iSCSIでWindowsにマウントして hdbench を実行。Read Write Copyを記録
- WindowsのローカルDドライブから上記ディスクに4GBのファイルをコピー
- そのファイルを同じディレクトリ上で別名コピー
で、比較の為に下記のようなものをiSCSIの保存先にしてみました。
- ZFS 1ドライブ
- 普通にzpool create tank /dev/ad0s1eで作成
- UFS
- 普通にnewfs /dev/ad0s1e としてマウントしたもの
- UFS別ドライブ
- /dev/ad0s1eと/dev/ad1s1eに2つのUFSを作り、LUN0とLUN1でWindowsから2つのドライブとしてマウントしたもの。ここだけ同一場所コピーではなく2つのドライブ間コピーになってます。
- /dev/ad0s1e
- ディスクイメージではなく、直接デバイス名を指定した場合
- ZFS ストライピング
- zpool create tank ad0s1e ad1s1e で作成
- ZFS ミラー
- zpool create tank mirror ad0s1e ad1s1e で作成
- gstripe
- gstripe label -s 131072 gs0 /dev/ad0s1e /dev/ad1s1e みたいな感じで
- ローカルディスク C:
- 参考までにお絵書き機のCドライブ。2.5インチ7200rpm 100GB
- ローカルディスク C:
- 同じくDドライブ。2.5インチ5400rpm 500GB
上記ではZFSよりUFSが悪い結果になっていますが、実はZFSで計測漏れがありまして翌日に測定すると前回より結果が20秒ほど早くなってました。一回目の測定ではZFSとUFSでそう大差なかったですし、それくらいの誤差が含まれているものとして表をご覧ください。
さて、グラフにすれば一目瞭然なのですが、そう大差ありません。不覚にも測定後に気付いたのですが、「測定に使ったドライブ(3.5インチ7200rpm
500GB)は単体で100MB/s前後の読み書き速度である」「ネットワークの帯域は1Gbpsなので100MB/sぐらいである」「同一場所コピーでは同一ネットワークで読み込みと書き込みが流れるので保存先の速度に関わらずネットワーク帯域の半分の速度しか出ない」という理由により、如何に速いファイルシステムを用いようとも結果はたいして変わらないのです(笑)。
とはいえ、幾つか興味深い結果も得られました。
- 経験的にWindowsでの同一場所コピーは読み込み/書き込みを別々に行って時間を合計したものよりも多くの時間がかかる。それを回避するためにお絵書き機では2ドライブ構成にしているが、ZFSやZFSミラーではUFS別ドライブに匹敵する結果が出ている。→物理ドライブを分ける必要が無い
- gstripeは意外と遅かった(笑)
- いずれにしてもローカルの2.5インチドライブに比べれば速い。WindowsをiSCSIブートにしちゃえばかなり快適になるのだろうなー。
うはー、なんか面白いことになりましたね。この勢いで自宅サーバを増設してiSCSIブートしたいところなのですが、残念ながらそうするにはハードディスクが760GBぐらい必要です。おうちにあるのは 160GBx2 と 500GBx2 なので、ミラーを作るにはこれで足りません。1TBx2を買ってくるか500GBx2を買ってきてRAID10みたいなのにするか、はたまた500GBを1個買ってきて
raidz にするか。raidzは試したことがないけど速度はどうなのだろう?
当初は自宅サーバ仮想化計画だったのに、いつの間にかZFSプール増強計画になっています(笑)。
仮想マシンの評価用としてしょぼいベアボーンPCに VMWare ESXi を入れていろいろ実験しています。FreeBSDをインストールすることも動作そのものも特に問題は無いのですが、動作速度はものすごく遅いのです!!
通常、FreeBSDをDVDからインストールする場合は見ている間に終了しますが、ESXi上では待ってても終わらないので他の作業ができてしまいます。いろいろ計ってみたところ下記のような壊滅的な結果になりました。
| 作業内容 | 実機 | VMWare ESXi |
|---|
| とあるportsのmake | 20秒程度 | 1分以上 |
| istgtによるiSCSI Target | 50MB/sぐらい
(たぶんPCI-NICが
ボトルネックに) | 15MB/sぐらい |
dd による /dev/zero から
ファイルへの書き込み | 90MB/sぐらい | 17MB/sぐらい |
うむむむ、明らかにディスクアクセスが遅いですな。世間の評判ではESXiのディスクアクセスは実機とそう大差ないレベルだそうなので、うちのテスト環境が特異なのでしょう。CPUがVTの無い Celeron 420 だからか、メインメモリが1GBしかないからなのか、それともハードディスクコントローラーが非対応のチップだからなのか。私の使い方ではうちのサーバーは50～100MB/sぐらいのHDD転送速度が必要ですので、これではNGです。実際に稼動させるとすれば ML110G5+Core2Duo+メモリ8GB+ハードウェアRAID1になる予定なのですが、一度これに近い環境でのテストが必要のようですね。
8.0-RELEASEを待たねばなるまい・・・と思っていた ZFS version 13 ですが、予想より早く7-STABLEにも降りてきたようです。あまり詳しいことは知りませんが、Solaris ZFS 管理ガイドを見ると zfs send に -I
とか -R オプションが書かれています。これがあると ZFS ツリーを丸ごとバックアップするときにちまちまスナップショット毎に差分送受信する必要が無く、コマンド一行で済んでしまいそうなので超々便利そうです。
ただ、一度upgradeするとdowngradeの方法が無いのは稼動中の自宅サーバにとって辛いです(^_^)。さらに /usr/src/UPDATING によると
ZFS send / recv between pool version 6 and pool version 13 is not supported.
らしいので、自宅サーバとバックアップ用(zfs receiveに使ってる)を同時期に upgrade する必要があります。どっちかを先行upgradeしてみて様子をみたいところですけど、一緒に大冒険しないといけないのがなんとも。
ところで、近い将来の仮想化に向けてファイルシステムの引越し方法を検討しています。普通に zfs send すれば良いのですが、ZFS version 6 ではちまちま転送しなくちゃいけないわけで、しかもサーバを動かしながらなので転送元が更新されたらまた差分転送しなくちゃいけないので ちょっと面倒です。なんか良い方法は無いかな～と考えているとひとつ名案が思い浮かびました。
- 転送先の新規デバイス(パーティション)を istgt で公開
- 転送元で iscontrol を使ってデバイスに割り当てる
- zpool attach にてミラーに追加する
- 構築されるまでひたすら待つ
- detachする
- iSCSIの接続を解除して、転送先で ZFS を import する
実際にやってみたのですが、一度 detach したデバイスってzpool として見つけてくれないようで(T^T)。転送先で zpool import -d デバイス でうまくいくと思ったのですが、だめでした。再度 iSCSI を使って転送元で別名のファイルシステムとしてインポートしようとしてもだめでした。detachが成功した時点で使えなくなるのかな? ということはやっぱり zfs
send するのが正解? てことは先に zpool upgrade しちゃうのが簡単??
いろいろ悩ましいです。
先週 車を点検に出してきました。早いもので丸4年です。バッテリーは2年毎にホームセンターで買ってきて交換、ワイパーは車屋さんのやつはビリビリ鳴るので自分で良いのを買ってきて使ってますが、それ以外は車屋さんにおまかせメニューです。
ということで今回のレシピ
- ブレーキ球交換(切れてた)
- エンジンオイル交換
- オイルフィルター交換
- スパークプラグ清掃
- シリンダーヘッドカバーガスケット交換
- エアクリーナー交換
- リアホイールセンターナット交換
- リアホイールセンターキャップ交換
以上、¥8,280也。スパークプラグのパッキンみたいなのがダメになっててオイル漏れが起きてたらしく、これを交換(費用の大半はこの部品代と工賃)。あとぜんぜん知りませんでしたがブレーキランプが切れてたらしいです。両方切れてたらさすがにわかるだろうけど、片方だからか駐車場でも気がつきませんでした。リアホイールなんとかっていうのは聞いた説明では出てこなかったしお金も払ってないのだけれど、これはいったい何だろう?
そんなこんなで現在走行距離は5万6千kmです。通勤で使わなくなってからはずいぶん走行距離の増え方も減りまして、以前は2～3ヶ月に5,000km走ってオイル交換していましたが、今は6ヶ月の定期点検で4,000kmしか走らずオイル交換となっています。このままのペースで行くと10年で10万kmぐらいでしょうか。割と早く廃車になるのかなーと思ってましたが、結構長く乗れそうですね。
おうちのPCの静音化や省電力化について、どういった構成にすればパフォーマンスが上がるかとかコストが安くて済むかとかいろいろ考えています。現状の構成を変更することは特に難しくないのですが、手間隙かけて変更した挙句「省電力にならない」「管理が困難になる」ではやらないほうがマシというのが難しいところです。
さて、省電力といえばAtomのシングルコアなのですが、省電力性という一点ではサーバ用に適しているものの、そうでない面も多いのです。
- チップセットにもよるが、搭載可能メモリは1～2GB。最大でも4GB止まり
- 多くの製品はチップセットに小さいファンが付いている。これが結構うるさいらしい
- ノート用のN270搭載製品では更なる省電力とファンレスによる静音性が期待できるが、intel 64 が無いらしい。→32bitOSしか動かせない
- intel VT はAtomには無い
- VMWare ESXi は intel VT が無くても動かせるのだけれど、これに非対応の場合は64bit OSを動かせないらしい
現状のように Windows Home Server を動かすだけには N270 は最適なCPUだと思うのですが、おうちで無駄に電気を食い続けているものは 主にFreeBSD機なわけで、ZFSとかPHPの整数型の問題等の理由で64bit版が望ましいわけです。となるとサーバーはAtom機ではなくて相変わらず Proliant ML110G5 で動かすことになり、現状の
ML110G5+ネットブック構成から省電力に抑えるのは困難っぽいのです。
ところで、まだ仮想PCについては本格的にテストしたことが無いのですが、手元にテスト用の環境もありません。LGA775のベアボーンPCは余っているので安い Core2Duo を買ってくれば良いかな? と思ったのですが、お店で売ってる一番安い Core2Duo の E7400(¥12,500ぐらい) は intel
VTに対応していません(T^T)。これではCeleronと同じではないか・・・。では対応しているのはというと、E8400まで飛んで ¥18,000ぐらい。うむむ、高いなー。ベアボーンPCより高いよ(^_^)。なんか他に選択肢は無いのかな～? と探していますと、最新の Pentium Dual Coreは intel VT にも対応しているらしい。Pentium DC E6300
¥9,000ぐらい。これくらいならお遊びに良いかもね。と思いつつスペックを見てびっくり。
| 名称 |
動作クロック |
FSB |
Cache |
| Pentium DC E6300 |
2.8GHz |
1,066MHz |
L2 2MB |
これに対して現在サーバーに差さってる Core2Duo はこんな感じです。
| 名称 |
動作クロック |
FSB |
Cache |
| Core2Duo E6300 |
1.86GHz |
1,066MHz |
L2 2MB |
偶然にも同じモデルナンバーなのですが、スペック上ではCore2Duoより劣ると思っていた PentiumDC がいつの間にかすべての面でCore2Duoと同等か上回っていました(^_^)。いやはや・・・。プロセス世代が変わってるので動作クロックはあがっても消費電力は上がっていない可能性もありますし、これはPentiumDCを買ってきてサーバーに刺さってるのと入れ替えるといろいろ幸せになれるのかもしれません。
余談ですが、先日の Microsoftの iSCSI Target は Windows のイニシエータ からは使えますが、それ以外はダメらしい。少なくともMacOSからは使えませんでした。ぬぬぬ、昔のNECのSCSI製品みたいなことを(笑)。iSCSIターゲット専用箱を作るのならやっぱり FreeBSD+ZFS+istgt がいちばんかな。
iSCSI Target の決定版は istgt だと思うのですが、我が家のMacOSでは istgt を使うと時々ハングアップしてしまいます。試験的に iscsi-target に戻していますが、1ヶ月以上使ってもなぜか一度もハングアップしないのでそのまま iscsi-target を使い続けています(^_^)。
ところで、連休中に出現した Windows Storage Server 2008 にはさりげなく iSCSI Software Target なるものがあります。Initiator は VistaにもWindowsServer2008にも備わっていますが Target
が無いのは不思議だなーと思っていたのです。さて、Microsoft様のTargetは如何なるものかちょっと試しに使ってみました。
istgtに比べると自由度が無い・・・というかある意味Windows的なのかもしれませんが、仮想ディスク用のディスクイメージをあらかじめ作っておいて、それをiSCSIターゲットに割り当てます。このターゲットは特に何も設定していない場合はどこからもアクセスできないようになっているらしく、イニシエータを明示的に設定してやる必要があります。が、ちょっと試した限りでは IQN
を設定しても使えなくて、IPアドレスを打ってやるとなぜか見えるようになりました。何か見落としていることがあるのかもしれません。
そんなこんなで ギガビットイーサ経由でVistaから hdbench してみた結果です。
Writeがちょっと落ち込んでるでしょうか。このHDDは3.5インチ 7200rpm 500GBの SATA なのですが、Vistaに接続してある同型のディスクをローカルで測定したところこんな感じ。
ローカルでもWriteは悪いですし、イーサネットが安物マザーオンボードなのを考えれば許容範囲というところでしょうか。
次に、CドライブとiSCSIのドライブ(どちらも同一品番のドライブを使用)間で2.4GBのMPEGデータを移動した時の時間を測定してみました。
c:->iSCSI: 26.2(s) 93.1MB/s
iSCSI->c:: 25.6(s) 95.3MB/s
(参考) c: -> D:(2.5インチドライブ) 66.2(s) 36.8MB/s
多くのベンチマーク試験は実使用と異なる意味の無い数値を示すのですが、上記試験は我が家においては極めて重要な意味を持ちます。DVDレコーダで録画したファイルを切り貼りしてオーサリングする際に2つのドライブ間で編集したり移動したりするので、上記ベンチマーク試験の結果如何で作業終了までの時間がだいたい決まるのです。
それによると、「iSCSIで接続したドライブのパフォーマンスはローカルで接続した場合とさほど変わらない」と言えそうです。少なくとも現在ローカルでDドライブに接続している2.5インチドライブとは比較にならないほど高速です(T^T)。うちのストレージはまだ流動的なのですが、場合によってはWindows Storage
Serverを一つ用意してぜんぶそこに押し付けるってのもアリかもしれませんね。
しかし、バックアップにはWindows Home Serverが必要で iSCSI には Windows Storage Server が必要で・・・って、一つにならないものかいな?(^_^)
うちの会社のFreeBSDは互換性の検証が面倒なので、ずいぶん古いバイナリがいくつか転がっています。Sambaも FreeBSD 4.8 の時代にコンパイルしたsamba2なので(^_^)、今後 freebsd-update を使うとなるとハマるだろうなーとおもって更新してみました。
ついでに漢字コードをSJISからUTF-8にしたのでターミナルからはずいぶん扱いやすくなったのですが、メールの通知を smbclient -M でWindowsのメッセンジャーサービスに送っている部分が動かなくなりました。samba2 の smbclient と比べると -t オプションが機能しなくなっているものの、事前のテストでは UTF-8
で送ってやればよかったのだけれど・・・。と思いつついろいろ試してみると、どうも nkf で UTF-8 にすると動かなくなるようです。
% echo "Hello" | hd
00000000 48 65 6c 6c 6f 0a |Hello.|
00000006
% echo "Hello" | nkf -w8 |hd
00000000 ef bb bf 48 65 6c 6c 6f 0a |...Hello.|
00000009
あり? テストしたときは UTF-8 なコマンド行から直接 echo で送っていたのですが、procmailからsmbclientに渡すのにはnkfが必要なので、ここで先頭になんかへんなのがくっついたようです。ちなみに、nkf のマニュアルを読み返してみるとこうありました。
-w -w8[0] -w16[BL][0]
Unicode を出力する。
-w -w80
UTF8 コードを出力する。 (BOM 無し)
-w8 UTF8 コードを出力する。
はへ? BOM ってナニ? 爆弾?? と思って調べてみると、Byte Order Markというもので、本来はUTF16などでコードのバイト並び順を特定するものなのだそうですが、関係ないはずのUTF8でも文字コードがUTF-8であることを特定するのに有効なのだそうな。ただ、当然のことながら先頭に付いてるのだから、実装の仕方によって(というかUTF8に対応してるかどうかによって) BOM
が付いてると問題がある場合・付いてないと判定を誤る場合があるらしい。でもって Windows XP のメッセンジャーサービスはBOMがあると動かないと(T^T)。
てことで、nkf のオプションを -w8 から -w に書き換えると動いてくれました。てゆーか、UTF-8の出力は -w8 しか無いと思っていたのですが、-w と -w8 を BOMの有無で使い分けなくちゃいけなかったのですな。ぜんぜん知りませんでした。
% cat /etc/rc | nkf -w8|file -
/dev/stdin: Unicode text, UTF-8
SJISやEUCでは漢字コードを除去したテキストファイルに差異はなかったのですが、UTF-8の場合 そうとは限らないのですな。ちょっと曲者かもです。
が出ているはずなのですが、うちのMacBookPro(10.5.6)でソフトウェアアップデートを実行するとこんなんになります。
うむむ、もう初代MacBookProは古いから対象外なんですか〜?(T^T)
[つっこみ]
| 05/16 | ( Y.Kumagai ) |
| どちらにしても、Deltaアップデートすると不具合を起こしやすいので都合が良いかと(^^) そんなCombo派の私の場合、ドック上でうるさく跳ねるアイコンを突いて「ダウンロード済み」だと惜しい気分になります(苦笑) |
| 05/16 | ( たかたに ) |
| むむむ、DeltaとかComboとかあるのですか。これまで手作業でやったことないのでぜんぜんしりませんでした。てゆーか、うちでは未だにうるさく跳ね回らないのですけど、放っといて良いのか手動アップデートすべきなのか・・・。 |
FreeBSD6の時代にさかのぼりますが、freebsd-update というバイナリレベルで更新できる命令が標準で搭載されました。FreeBSDではセキュリティ更新においても make world するのが一般的であり、他の方法に比べると時間はかかるものの、容易でかつ信頼できる手段です。
freebsd-update が登場した当初は「使用できる条件はCDなどからバイナリインストールした場合に限る」となっていたような気がするのですが、現在はそこまで条件が厳しくなくて「make world している場合でもRELEASE版の場合はOK」みたいです。ただし、GENERICカーネル以外を使っていたり /etc/make.conf
に何か書かれていることが前提のシステムだと更新できても期待通りに動かない可能性があります。おうちのサーバは sendmail がらみで色々書いてるのでダメですが、会社のルーターに使ってるFreeBSDはほとんどすっぴん状態なので make world よりは時間もCPUパワーも使わないバイナリ更新はなかなか興味深いところです。
ということで、使い方。実はfreebsd-updateの正しい手順というのはマニュアルやハンドブックには書かれていません。が、概ね下記のようになるでしょう。
- # freebsd-update fetch (または freebsd-update cron)
- # freebsd-update install
FreeBSDの場合、セキュリティ更新の度に 'FreeBSD 7.1-RELEASE-p数字' みたいに数字のところが増えていきますが、この更新だけなら上記で特に問い合わせも無く完了します。過去の例からすると /etc 以下は変更されないので安全に更新できて、念のために最後に再起動すれば作業終了です。
さらに freebsd-update ではメジャーバージョン間のアップグレードにも対応していて、たとえば7.2に上げるには announce によると
- # freebsd-update upgrade -r 7.2-RELEASE
- # freebsd-update install
- # shutdown -r now
- # freebsd-update install
- # shutdown -r now
という手順になるのだそうです。手順自体は簡素なのですが、実際にやってみると結構時間はかかります。実行中にいろいろ質問してくるので、make world のように寝てる間に作業させるわけにもいきません。とりわけ気をつけなければならない事としては、FreeBSD6.x から 7.x に上げる場合は二回目の freebsd-update install
で古いライブラリが削除されるので、portsで入れたプログラムが動かなくなるのだそうです。VPNで接続した先のマシンをアップグレードする場合は気をつけないとVPNソフトが動かないために再起動した時点で終ってるというまぬけな事態になりかねません(笑)。
その他、気づいたこと
- /etc/freebsd-udpate.confによると、更新される対象は src, world kernel みたい
- 同設定で AllowDelete yes を no にしておけばライブラリが削除されないのかもしれない
- /etc の更新は触ってないファイルは上書きされ、そうでないものはマージされるみたい。mergemasterより簡単みたいなのだけれどいまいち動作がよくわからない
- /src も更新されるのだから、自動マージが気に入らなければ最後に mergemaster すればよいかも
実績面では make world に及びませんが、試しに使った限りでは(特にしょぼいPCで) make world よりも早く終りますから ちょっとした更新には良いんじゃないかなーと思いました。
