この症状がひどくなって空き領域がなくなったときは、一度umountしてmountすると回復します。unlinkされたファイルの情報はumount -fされた場合に備えてファイルシステムに記録されていて、mountしたときに残ったファイルの領域がすべて解放されるからです。問題はなぜオープンしているプロセスがいなくなっても、unlinkされたファイルの領域が解放されずに残るかです。
調べたところ、この現象はZFSのこのバグに該当する可能性があることがわかりました。大きなファイル消したときに領域が解放されない場合があるようです。このバグはSolaris 10 9/10 (u9)で直っています。ftp.jaist.ac.jpはu9へのアップグレードをさぼっていてu8のままでした。すでにu10が出ているので、このバグを修正するためにu10にアップグレードすることにしました。
Live Upgradeを使えば最後に再起動するとき以外はサービスを止めずにアップグレードできます。あまり迷惑をかけずにアップグレードできると思ったのですが、意外とはまりました。luupgradeの終了後に、アップグレードしたu10のBEをluactivateすると失敗した場合の手順がこんな風に出ます。これが不要であることを祈りつつコピペしておきました。
In case of a failure while booting to the target BE, the following process
needs to be followed to fallback to the currently working boot environment:
1. Enter the PROM monitor (ok prompt).
2. Boot the machine to Single User mode using a different boot device
(like the Solaris Install CD or Network). Examples:
At the PROM monitor (ok prompt):
For boot to Solaris CD: boot cdrom -s
For boot to network: boot net -s
3. Mount the Current boot environment root slice to some directory (like
/mnt). You can use the following commands in sequence to mount the BE:
zpool import zp-root
zfs inherit -r mountpoint zp-root/ROOT/s10s_u8
zfs set mountpoint=<mountpointName> zp-root/ROOT/s10s_u8
zfs mount zp-root/ROOT/s10s_u8
4. Run <luactivate> utility with out any arguments from the Parent boot
environment root slice, as shown below:
<mountpointName>/sbin/luactivate
5. luactivate, activates the previous working boot environment and
indicates the result.
6. Exit Single User mode and reboot the machine.
u10のBEから起動したら、原因は不明ですがmptドライバが読めず起動しませんでした。そこでこの手順に従ってu8のBEから起動を試みたのですが、4番目の手順でluactivateがlulib_get_zfs_devsが見つからないとエラーになりました。ググッてみたけどこんなケースはどこにもなく、時間を無駄に消費しました。1. Enter the PROM monitor (ok prompt).
2. Boot the machine to Single User mode using a different boot device
(like the Solaris Install CD or Network). Examples:
At the PROM monitor (ok prompt):
For boot to Solaris CD: boot cdrom -s
For boot to network: boot net -s
3. Mount the Current boot environment root slice to some directory (like
/mnt). You can use the following commands in sequence to mount the BE:
zpool import zp-root
zfs inherit -r mountpoint zp-root/ROOT/s10s_u8
zfs set mountpoint=<mountpointName> zp-root/ROOT/s10s_u8
zfs mount zp-root/ROOT/s10s_u8
4. Run <luactivate> utility with out any arguments from the Parent boot
environment root slice, as shown below:
<mountpointName>/sbin/luactivate
5. luactivate, activates the previous working boot environment and
indicates the result.
6. Exit Single User mode and reboot the machine.
あきらめてダメ元で再起動したところ、今度はbootデバイスの指定がおかしくなっていて起動しません。boot -Lでブートデバイスを調べて、boot [ブートデバイス] -Z [u8のBEのZFS]でブートしたところ-Zが無視されました。これではブートしないu10のBEで起動するかと思いきや、意外にもu8のBEから起動しました。これでほっと一息です。先の4番目の手順はエラーメッセージは失敗と出ていても、u8のBEのactivateには成功していたようです。
再起動に失敗してから復旧するまで、なんと1時間半近く掛かりました。昨日の12時半頃から14時45分ごろまでftp.jaistが止まっていた理由はこれです。
今度はやり直したluupgradeがunable to mount <>と言って失敗するので、いろいろ試行錯誤していて、その途中で何度か再起動しました。15時頃から18時頃まで何度かサービスを停止していた理由がこれです。結局、最初のluupgradeでu10のBEが正しくumountされなかったのが原因で、luumountでumountしてマウントポイントの/aを削除してからやり直したらうまくいきました。luupgradeが終了してu10のBEから起動したところ、今度はうまくいきました。
なんでLive Upgradeごときでこんなにはまるのかと本当に憂鬱でしたよ。ftp.jaist.ac.jpを利用している皆様にはご迷惑をおかけして申し訳ありません。
0 件のコメント:
コメントを投稿