計算機暗号屋日記 (2005年1月 睦月)

2005年1月30日

• 結局、2nd PC開けてみた。
  • 導入して3週間。 実質動かしているのは2週間弱だけど、結構fan周りに埃がついていた。 まぁこれは部屋の問題か？
  • んで、ふと気がつくと、memory moduleのパチッとはめる奴が一つ緩んでいたのではめる。 でも、これは今回の問題と関係ないなぁ。
  • んで、問題のHDのcableだけどちゃんと全部はまっている。 が、flat cableじゃないのね。 groundとかうまくいっているのかしらん？
  • んで、HDのjumperとか間違ってないか見ると… まぁ大丈夫なんだろうけど「ultra ATA cableなら、cable selectに設定せよ」とあるけど、masterとslaveになっている。 うーん。 まぁいいか。 とりあえずしっかり手でコネクタを押して見た。 これで様子見かな。
  • んで、またddしたらやっぱり例のswap_pager云々いわれるなぁ。 一応問い合わせてみるかなぁ。
• 部屋の床に平積みになっている本を整理したいんだが、移動先がない。 で、よく考えると、部屋備えつけの書棚に、越してきてすぐに入れて、また数年間見ていない文庫本が多数あることに気がついた。 ということで、アクセスが悪い所に移動してもいいはずなので、いれと庫の文庫本用の購入。 今回の目的には縦入れよりも横入れの方がよかったんだけど、丁度いったスーパーには残念ながらおいてなかった。
• bulk HDの山を整理するために私と生活のクリアーボックスを買ってみた。 また、bulk HDを買うと必ず除湿剤も一緒にあるのでドライペットというのも買ってみた。 どんな感じかしばらく様子見かな。
• 引続きHD速度計測:
  • しまった。 妙に時間かかるかと思ったらcount=128を付け忘れていてdiskを溢れさせただけだった。
  • とりあえず、計測再開:

         master            slave
     write    read     write    read     OSver  mode   format
    51.2MB/s 53.8MB/s 52.3MB/s 54.7MB/s  4.11R UDMA100 UFS
    50.5MB/s 52.2MB/s 51.3MB/s 53.3MB/s  4.11R UDMA66  UFS
    31.5MB/s 28.6MB/s 31.1MB/s 29.4MB/s  4.11R UDMA33  UFS
    15.8MB/s 49.7MB/s 15.9MB/s 49.0MB/s  5.3R  UDMA100 UFS
    43.7MB/s 48.4MB/s 16.0MB/s 48.4MB/s  5.3R  UDMA66  UFS
    48.1MB/s 28.1MB/s 15.9MB/s 28.3MB/s  5.3R  UDMA33  UFS
    

  • 「swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 2, size: 4096」って何だろう？ blkno: 2が3回、8が3回出た。 んで、別のttyvからloginしようとしたら… Passwordを聞いてこないじゃん。 なんかヤバイ感じ。 と、思ったけど、単に午前3時のdaily scriptが計測の邪魔をしていたらしい。
  • と、思ったんだけど、全然関係ない時にも同じ場所と思われるblkno: 2で発生した。 なんか、該当する当たりのHDが壊れかけていたりするのかなぁ。 それとも、busが腐っているのかなぁ。
  • 忘れないうちにメモっておこう。

    計測対象HD: ST3160021A

    M/B: S875WP1-E

    このくらい書いておけば再現可能か。
  • なんか、5.3RのUDMA100の書き込みが、15.8MB/s, 15.9MB/sと遅過ぎるのでもう一度計測し直し。 やっぱり、38〜50MB/sぐらいの、もうちょっとマトモな数字になるようだ。 という訳でもないか。 例のswap_pager云々が出ないと遅いな。 うーむ。
  • 「What does the error ``swap_pager: indefinite wait buffer:'' mean?」というのがあった。 disk errorに関する文句は何も出ていないから、cableが緩いとかあるのかな。 やっぱ開けて調べることになるのかなぁ。

2005年1月29日

• 今年の花粉情報提供始まる: KISSEI、 環境省
• 4R, 5R HD速度測定実験:
  • 「repeat 3 dd if=/dev/zero of=16g.bin bs=128m count=128」で測定することにする。 んで、3回の中央値を採用。 せいぜい上と下で3%ぐらいしか違わないので。 16GBにしたのは、実メモリ2GBということから、cacheが効かない様にという配慮。
  • まず、4.11Rをインストールしてmaster HDに配置されている/usrに対して実験。 次にslave HDで実験。 そのあと5.3Rで同じことを実験予定。 読み込みの方はどうするかな。 「repeat 3 dd if=16g.bin of=/dev/null bs=128m」かな。

         master            slave
     write    read     write    read     OSver  mode   format
    51.2MB/s 53.8MB/s 52.3MB/s 54.7MB/s  4.11R UDMA100 UFS
    50.5MB/s 52.2MB/s 50.5MB/s?          4.11R UDMA66  UFS
    

  • あら？ 「atacontrol mode UDMA66 UDMA66」して、 UDMA66に設定してslaveの書き込み実験中に固まっているんですけど。 少なくともkeyboardからの反応無し。 4.11Rは、disk書き込みの実験だけのつもりだったからnetworkとか設定していないので、keyboardとか表示だけ死んだ可能性とか調べにくいのが失敗。 やっぱり、色々想定外のことって起きるなぁ。
  • messagesを確認したけど何も分からず。 とりあえずnetworkは立ち上げてみた。 んで、書き込み中のファイルは0Bだった。 まぁfsck動いたらそんなものかな。
  • ということで、計測再開:

         master            slave
     write    read     write    read     OSver  mode   format
    51.2MB/s 53.8MB/s 52.3MB/s 54.7MB/s  4.11R UDMA100 UFS
    50.5MB/s 52.2MB/s 51.3MB/s 53.3MB/s  4.11R UDMA66  UFS
    31.5MB/s                             4.11R UDMA33  UFS
    

  • しまった。 UDMA66の計測のつもりがUDMA100でやっているし。 rebootしたの忘れていた。 ^^;
  • おろ。 UDMA33で、ad0の読み込み実験したら、なんかまた固まったぞ。 pingにも反応無し。 今度は、コマンド打ってすぐだった。 diskのアクセスランプはさっきと同様消えていた。 うーん。 大丈夫なのかなぁ。 とりあえずresetして、やり直してみるか。
• 4.11Rは関係ないかと思ったが、結局、新しいというか構成の同じPCで、4Rと5RでmasterとslaveのHD速度がずいぶん違う問題のテストが出来るので、CD-Rを作ってしまった。
• memtest86+ v1.3による2nd PCのメモリテスト。 221時間(=9日強)の242 passまでいった。 ということで大丈夫ということにしよう。

2005年1月28日

• NFSNETの次の分解は5_307Pらしい。
• FreeBSD 4.11Rが出たらしい。 といっても、私が関わっているのはかなり5Rへの移行が済んでいるので、あんまり関係ないかも。
• ISEC3月プログラム。
• ↓これ、よく考えると、プログラム委員をして、さらに査読するとdouble countだな。 もうちょっと改善しなければ。

2005年1月24日

• そういえば査読依頼の方はどう勘定したら義務を果たしたと思えるだろうか。 編集委員担当論文数については、投稿数と査読数との関係

  投稿数 × 査読者数 ／ 著者数 ＜ 査読数

  と同じように

  投稿数 × 該投稿論文担当編集委員数 ／ 著者数 ＜ 編集委員担当論文数

  となっていればいいような気がするんだけど。 これはまだ右辺が19なので、まだ引き受けるべきなんだろう。 うーん。

  投稿数 × 査読者数 ／ 著者数 ＜ 査読数 − 査読依頼数

  としたらいいかな？ なんかでも、2つも不等式を見ているの面倒だな。

  投稿数 × 査読者数 ／ 著者数 ＜ 査読数 ＋ 編集委員担当論文数 − 査読依頼数

  ぐらいにすれば、この分野での義務を果たした気になれるか？ とりあえず右辺の各要素の記録はしておこう。

2005年1月23日

• PCの設置状況を変えてから初めてIEEE1394外付HDを繋げてみた。 おや？ 認識しないじゃん。 おーい。 「fwcontrol -r」してもダメ。 うーむ。 この狭い所に色々押し込んだのが問題なんだろうか？ 何回か電源off/onとかHD caseのATA cableさし直しとかして、ようやく認識してくれた。 よかった。
• なんか今日はweb robootがたくさん来るなぁ。
• RC5-72 challenge0.185%突破。 昨日のペースだと全空間探索にあと802年。 3年4倍で解読速度が向上するとすると27年。
• 久しぶりにsshでのlogin攻撃を受けた。 昨年10月ぐらいにいろんなパスワードでroot loginを試みたのとパターンが違うから、またなんか新たのがはやりはじめているのか？
• なんか最近事実上1ch〜3chのvideo録画予約が出来ていないな。 入力信号悪過ぎ。 でも、GV-MVP/IDVの方は、質が悪いとは言え、なんとかなっているんだよなぁ。 何が違うんだろうか。

2005年1月21日

• 12日に書いた話、似た話がすでにあったらしい。 (情報from S氏)
• 2nd PC納入検査で、HT on, USB Legacy onで、memtest86+ v1.3の実験、ECC onにして、pass 43まで順調に進んでいる。 このまましばらく実験継続。

2005年1月20日

• 2nd PC納入検査: memtest86+ v1.3で、BIOSのHT off, USB Legacy offで、9時間弱は通った。 ということで、BIOSのHT on, USB Legacy on, memtest86+のECC onで実験開始。
• http://www.schneier.com/なんてのがあるのか。 実は99年からあるらしい。 全然気がついてなかった。

2005年1月19日

• 引続き2nd PC実験作業:
  • うーん。 2:18:54でpass 4まで行って止まっていた。 Hyperthreadingもoffにしろってことか？
  • offにして実験したけど、1 passもせずに0:25:55で止まっていた。
  • memtest86のECCもoffにして実験したけど0:48:12で止まっていた。
  • 2nd PCの出荷元によると、世の中にはmemtest86+というのがあるらしいので、こちらで実験。 とりあえずHT onにして、USB Legacyも元に戻して、memtest86+のmenuでECCはonにして実験。
  • くー。 25秒で固まった。 んじゃぁ、BIOSとかで一番安全な方に倒すか。
  • やっぱり0:10:29で止まった。 ダメじゃん。 もう一度問い合わせかな。
  • 出荷時テストに使ったのは、memtest86+ v1.3らしいので、これで実験。

2005年1月18日

• 2nd PC実験作業:
  • 問い合わせた結果、BIOSのLegacyUSBをOFFにしなおとダメらしい。 FAQなのかもしれないけど、こんなことに返事を適切に貰えるとは思わなかった。
  • ということで、実験。 F2→BIOS→Advanced→USB Configuration→Legacy USB Support→Disableとした。 とりあえず問題無くmemtest86 3.2が起動。 ECC onにして、しばらく放置。
  • 一週間は実験したかったけど、うーん。 タイミング悪し。
  • 少なくとも41分経過して大丈夫だった。 以前よりは大丈夫ということで。

2005年1月17日

• やっぱ、この2nd PC結構うるさい気がするぞ。 ずいぶん静音が強調されていたんだけどなぁ。 まぁ音は主観の問題が大きいから何ともいえないけど、結構、本体fan自体の音も大きいし、高周波成分が多く混じっている気がする。
• がーん。 久しぶりに食らってしまった。 mplayerがX windowを道連れに… rebootせずに復旧する方法無いのかなぁ。 full screenから「f」でもとのサイズに戻す時、windowの外にmouse cursorがあるのに、そこに配置して「やば」と思った時にはすでに遅し。
• 引続き2nd PC setup:
  • ad1の空読みも問題無し。 ということで、ad0, ad1の0-fill実験開始。 で、終るまで置きているのは辛いので、ad0, ad1同時書き。
  • なんとなく「newfs ad0」とかして、それで書き込んでいたけど、よく考えたら潰していいdiskなので、直接ad0とかに書いていいのだった。 ということで、よりしっかり実験が出来ると思って、寝る前にやり直そうと… 見たら何か固まっているじゃん。 おいおい。 そういえば、同時じゃなくてsequentialに実行も出来たのだった。 ということで、なんかdiskのどちらかが悪い気がするんだが、とりあえず「dd if=zero of=ad0 bs=32m;ls ad*;dd if=zero of=ad1 bs=32m」を仕掛けて寝ることに。 ls入れたのは、ad0が終ったのが分かるように、と思ったけど、よく考えたらddって終ったら出力を出したんだっけ。 ま、いいか。
  • diskの0-fillは問題無く終了。
  • んで、memtest86 v3.2を実行して放置。 ECCはonにしてみる。 おや？ v3.2にはtest selectionでall testってのは無いのかな？
  • がーん。 0:37:19で、pass 1になって、test 26%, pass 13%, #4 moving inversionとかいうので止まっているんですけど…
  • もう一度実験。 げ、今度はECC onとか設定する前に0:01:21で、固まってしまった。 もう一度実験。
  • 今度は途中でECC onにして見ていたら… pass 1も行かずに、0:32:48で固まった。 うーん。 念のため、v3.1aで実験。 ECC onで、all testってことで。
  • ダメだなぁ。 今度は0:07:04で止まっている… とりあえず問い合わせかな。

2005年1月16日

• 2nd PC届いていた。
  • 最悪、立方体に近い馬鹿でかい箱を覚悟していたが、そんなことはなかった。 25.5cm×48cm×53.5cmの箱と、袋がついていた。
  • 袋もそれなりに大きかったので、何かと思ったら、mother boardの箱だった。 中にはcableとか入っていた。
  • 箱を空けようとして、テープをはがしながらふと思った。 今までの経験からすると非常に高い確率で保証期間内に故障して送り返すことになるので、あんまり箱にダメージを与える開け方はよくないかな、と。 このテープを残して、というか切って開けて、この箱を使う時は、テープの上からもう一つテープを貼るのがよいのではないかとの前回の教訓を生かすことにする。
  • 先に、設置予定場所にあるHD caseとbulk HD群を片付けるか。 でも、どこへもっていこう。 地震とかで落ちた時のダメージを考えると、あんまり上の方には置きたくないしなぁ。
  • 箱にくっついていた本体チェックシートによると、memtest86で12時間チェックとかしているみたいだ。 なかなかマトモかも。
  • さて、設置予定場所だが、背中に大量にcableが走っていて、思ったより体積食っているぞ。 さて、どう整理しようか。
  • とりあえず本体設置。 cable接続どうしよう。 いつも思うんだけど、何故cableって背中側が基本なんだろうか。 不便で仕方ない。
  • むむー。 どの辺のどの口があるか、まだ記憶していないから作業しにくいなぁ。 この落ちているdisplay cableとkeyboard+mouse cableは前、Athlon PCに繋げていたのがそのままkeyboard切替え器に繋がっているかな？ ethernetは、外してあるみたいだ。 cableをもってきて… おや？ 本体に口が2つもあるぞ。 どっちが若い番号になるんだろうか？
  • とりあえずこれぐらい繋がっていたらいいかな。 む。 電源cableがコンセントに刺さらんぞ。 隣のAD adapterが邪魔だなぁ。 ADSL modemのだけど… 一旦外して隣に移動。
  • よし、起動だ。 チェックシートによるとHyperthreading offらしいから、まずはBIOS起動だな。
  • おや？ 結局ECC memoryなのか。 まぁいいけど。
  • んで、BIOSをひと通りみたので、5.3Rのdiskを入れて起動。 へぇ。 イマドキのDVD driveって、UDMA66とかで認識するのね。 CD driveとかってPIO modeでしか繋がらないのかと思っていた。 ってよく見ると、1st PCのもUDMA33で繋がっているじゃん。^^;; んで、networkはem0とfxp0になるのか。 同じの2つじゃないんだ。 んで、適当に繋いだのはfxp0だった。 まぁどうせHUBが100baseTだからどっちでもいいんだけど。
  • んで、例によってdiskの空読み実験開始。 fixit diskを使って「cd /dev」 「dd if=ad0 of=null bs=128m」。

    dd: input buffer: Cannot allocate memory

    あれ？ 2GBのメモリをチャンと認識はしているんだけどな。 まぁいいや。 ということでbs=32mにしたら動き出した。
  • んー、memtest86のdiskは3.1aしか無かった。 待っている間に3.2のdiskをヤキヤキしておくか。
  • UDMA100で認識していたような気がするので、ddの空読みは理論値でも27分て所か。 しばらく*待ち*だな。
  • 結局、ほぼ1時間で、160GB HDのad0の空読みが終った。 問題出ず。 現在ad1の空読み中。
• 出かけようと思ったら雨が降っている気がする。 うーむ。
• 今日は2nd PCが届くはず。 置場を空けておかねば。 このbulk HDの山をどうしようか。 なんかイイ入れ物とか無いかな。 とりあえず書き出すものだけ書き出して撤収かな。 あと、Athlon PCを入れていた箱も外の倉庫に移動するかな。
• 昨日はずいぶん天気が荒れていて、色々買いものするつもりだったけど断念してしまった。 今日は雨が上がっているから行き易いかな？

2005年1月12日

• The Misuse of RC4 in Microsoft Word and Excel。 本当かどうか知らないが「さもありなん」という感じだな。

2005年1月11日

• FSE2005 accepted papers。

2005年1月10日

• マトモな画像でのbt878の裏番組録画実験ができた。 パラメータは前と同じ 「-ofps 23.976 -tv width=320:height=240 -lavcopts vbitrate=1536」 という感じで。 んで、3分毎にbitrateの平均(kb/s)を出すとこんな感じ。

  723 520 441 416 416 345 356 338 333 342

  なんか、さっきより悪化しているな。 前よりは負荷が高い状況での実験だったのは事実ではあるが。 とはいえ、低負荷の状態を保証するのもなぁ。 それを気にするというぐらいしか出来んなぁ。 new PCが来るのを待つか。 んで、もう一台GV-MVP/IDVを導入するということでの解決かな。

2005年1月9日

• 複数の作業を同時にすると混乱するけど、待つばっかりも嫌なので、HDのほうも大体大丈夫な感じだし、整理の方、再開するか:
  • どこまでやってたっけ？
  • まずは、250GB HDを、しばらく取っておいてから、そのうち消すもの置場にしたはずなんで、そっちにいくつか移動すればいいはずだな。 ということで、接続して電源on。 ドキドキ。 というか、なんでこんなことぐらいでドキドキしなければいけないのか納得いかないような気もするが…
  • 無事認識。 ということでmountして、移動開始。
  • 27GBほどの移動、無事終了。 umount、HD電源off、BUS reset×3などで認識外し。 保存用である160GB HDに接続をかえて電源on。 無事認識。 んで、mount。 そういえば、まだsoft updateを止めてなかったな。 「tunefs -n disable /dev/da0s1d」
  • 数十GBの読み書き終了。 ということで、HD電源offとか。 続きの作業は2nd PCの方の読み書きチェックとか終らないと… と思ったら終っているようだ。
  • んで、接続をしばらく使っていなかった160GB HDに変えて、HD caseの電源on。 うーん。 色々あるなぁ。 でも、中を見ると基本的に消すqueueの整理に対象ばっかだなぁ。 とすると、イマイチやる気起きないけどどうしようかなぁ。 外付HD間のデータ移動面倒なんだよなぁ。 HD caseが1つしか無いから。 移動を最小化するためによく考えねば。
  • 内蔵HD→IEEE1394 HDの時は別に問題無いんだけど、逆のIEEE1394 HD→内蔵HDのcpって、なんか他のファイルアクセス止めちゃうんだよなぁ。 何が違うんだろうか。
  • やっと整理終了。 これであとは追記していくだけでいいはず。
• なんか、待ち時間ばっかりの作業だなぁ。 という間に5.3Rのdisc1のISO imageのdownloadが終ったのでburncd。 これで、new PCが来たらすぐにsetupできるかな。
• 前から気になっている「mencoder -tv driver=bsdbt848 tv://」で録画時間が数分以上になると段々勝手にbitrateが落ちていくのをなんとかしたいんだけどなぁ:
  • とりあえずdefaultのwidth=640:height=480だと最初から1秒毎に0.1秒ぐらいコマ落ちするので、どうせもともとbt878の質が悪いということで諦めてwidth=320:height=240で実験。
  • 最初からbitrateを多めに取っておけば大丈夫かなぁと実験したけど関係ないみたい。 最初は2Mb/sから始まっても途中から500kb/sぐらいまで落ちたりするからなぁ。 録画予約中、全くbusに(CPUに?)負荷をかけなかったら大丈夫みたいなんだけど、ちょっと非現実的な仮定だしなぁ。
  • んで、逆に「-lavcopts vbitrate=1024」とか小さい所で始めたら… 関係ないようだ。
  • そういえば、以前30f/s→24f/s実験した時、encoding速度が上がったってことがあったということがあったな。 ということは「-ofps 9.99」とかすると負荷が下がってうまくいったりする？
  • お。 20分の実験では最後までbitrateが落ちずに進んでいるぞ。 これは、いいかも。 しかし、9.99f/sだとさすがにカクカク感が否めないな。 19.98f/sだと、どうだろうか。
  • まぁいい感じ。 でも若干、*カク*があるな。 では、23.976f/sだとどうだろうか。
  • いいかな。 まぁでもその時の負荷状況とかにも依るから、今日の夜に裏番組録画実験だな。
  • ということで30分弱の実験をしてみた。 パラメータは 「-ofps 23.976 -tv width=320:height=240 -lavcopts vbitrate=1536」 といったところ。 3分毎にbitrateの平均(kb/s)を出すとこんな感じ。

    2993 1465 1043 864 810 723 742 571 599 581

    うーん。 別に段々動きが無くなっている映像って訳じゃないんだよなぁ。 なんとかならないのかなぁ。 しばらく、裏録画で色々パラメータ変えて実験するしか無いかなぁ。 が、実際画像見てびっくり。 1chだったんで、もしかしたらと思ったけど、丁度noise乗りまくりの時間だったのね。 これは出直しかな。
• GV-MVP/IDV on FreeBSDな方が増えたらしい。
• そういえば、最近、SSHのroot password全数探索攻撃が来てないな。
• 外付HD用のbulk HDの完全性確認作業継続:
  • 160GB HDの空読みOK。 空き領域へのzero fillも成功。 ということで、結局、普段使い続けているHDについては問題が無かったということか。 本当は、全領域への書き込みをしたかったんだけど、それをするためには、そういうプログラム書くか、大量のデータ移動を伴い大変なので、そこまでは諦めるということで。
  • せっかくなので、現在、おやすみ中の、もう一台の160GB HDを取り出して空読み実験開始。 あ、ここにcrashした60GB HDに入っていたデータの一部があるなぁ。 あとで引き上げよう。
  • 空読み実験終了。 zero fill実験開始。
  • これも問題無く終了。 さて、60GB HDの方だけど、どうしようかなぁ。 中身をddで吸いだし済みってことで、newfsかけちゃおうかなぁ。 えい。 かけちゃえ。
  • ということで、さきほど準備した5.3Rのinstallation discで作業開始。 まぁ別に5.2.1RCと変わるとは思えんが。 で、せっかくなので、fdiskから実行したら… しまった。 一度sysinstall起動し直さないとbsdlabelがうまくいかないのだった。 ということで、仕方なく再起動。
  • 今度はちゃんとnewfs出来たみたいだけど、fixitが出来ないんですけど… newfsが出来るようにするためにmount ptを「/」とかしたことが原因のような気がするな。 諦めてもう一度再起動。
  • ありゃーん。 またdisk I/O errorとかいわれてダメじゃん。 このdisk壊れたかなぁ。 もう一度、CD-Rを入れ直してgo。
  • うまくいった。 ということで、読み込み実験は… 昨日やったのでzero fill実験開始。
  • これも問題無く終了。 うーん。 昔、見た気がするbad sectorとかはどうなったんだろうか。 FDみたいに、しばらく放置していた場所の磁気が弱くなって読めなくなっていたんだけど、上書きして大丈夫になったとかあるのかなぁ。
  • とりあえず2nd PCの構成を元に戻して起動。
• RC5-72 challenge0.180%突破。 昨日のペースだと全空間探索にあと850年。 3年4倍で解読速度が向上するとすると27年。

2005年1月8日

• 外付HD用のbulk HDの完全性確認:
  • とりあえず2nd PCを「shutdown -p」して電源off。
  • カバーを開けて掃除。 といっても前開けてから数カ月しか経っていないので、そんなには埃は積もってなかった。 あれ？ 120GB HDがmasterなのにata1のcableのslaveに繋がっているぞ？ まぁあの頃はイマイチmasterとslaveのこと分かっていなかったからあり得ることだが。 ^^;
  • んで、HDをとっかえひっかえし易いようにカバー開けたまま設置。 一番挙動が怪しい60GB HDを接続して起動。
  • 無事、起動して認識。 そっか、そういえば、これのOSは4Rだったか。 ということは、ufs2を利用した書き込み試験は出来ないなぁ。 これを機会にOSのversion upを考えるかなぁ。 とはいえ、もうすぐmain PCの予備機が届くはずなので、そっちが届いてからでいいかな。
  • んで、いつも通りddの空読み。 いや、まてよbs=128mなんてすると内蔵メモリが64MBだからswapの嵐になるな。 ということでbs=32mと指定してやり直し。
  • ATA33での接続だけど、さすがにIEEE1394よりは速いか。 「iostat 1」を見ていると大体22.5MB/sぐらいは出ている。 ということで、46分ぐらいで終るかな。
  • ほぼ予想通りの時間で終った。 幸い(?)にして何もエラーは検出されなかった。 ということで、今後は250GB HDに繋ぎかえて実験。 今度のは回転数が7200r/mとさっきの5400r/mより速いせいか、iostatで見ると23.2MB/sぐらいは出ている。 若干速いようだ。 ということで、丁度3時間ぐらいで終る見込み。
  • さて、でも書き込み試験の方はどうしようかなぁ。 今のmain機の側版を外してad1を入れ換えるという作戦でいこうかなぁ。 まぁでも次の録画予約時間を考えて、深夜には作業したくないことを考えると明日以降の話かな。 やっぱり、予備機を待つのが正しいか。 いや、でもなるべく、早いうちにこれらのHDを使った作業をしたいんだよなぁ。 うーん。
  • 250GB HDの空読み、問題無く終了。 そういえば、install CDでbootすれば5.3Rでの起動は可能だな。 よし、これでやるか… としたらmountとか入っていないのか…
  • んでfixit FDとかあればいいんだろうけど、 FDDがないんで、fixitのCD imageを作る必要があるけどどうすればいいんだろう？ 多分、そのままburncdで焼き付けてもダメなんだろうな。
  • んで、手元にあった5.2.1-RCのinstall CDはRock Ridgeみたいなので、 「mdconfig -a -f fixit.flp」 「mount /dev/md0 /mnt」 「mkisofs -o fixit.iso -r /mnt」 「burncd -f /dev/acd0 data fixit.iso fixate」 としてCD-Rに焼いて見た。 んで、install menuからCDを選んだら… なんか色々警告出されたけど、ちゃんとmountだのddだの使えるようになった。
  • ということで、250GB HDの空き領域36GBに書き込み実験開始。 おや？ bs=32mだと何か強制killされているんですけど… ということでbs=16mに変更して再開。 今度はちゃんと進行しているみたい。 30分もあれば終るかなぁ…
  • 全然終らん。 2時間くらいかかりそうだ。
  • なんとかおわった。 無事エラーも出なかった。 ということで、160GB HDに繋ぎかえて空読み実験開始。 約2時間って所か？
• SCIS2005プログラム正式版が公開されたらしい。
• SCIS2005参加者の服の色のオキテ。 (情報from F氏)

2005年1月7日

• とりあえず出来る範囲でdisk整理を始めようとIEEE1394 HDを繋いでSW on:

  Jan  7 23:23:36 flu kernel: sbp_orb_pointer_callback: xfer->resp = 22
  

  なんか変だ:
  • でもfwcontrolでみてもちゃんと認識しているし。 とりあえずmountしても返事無し。 気持ち悪く感じながらもC-cで止まってよかった。
  • とりあえずda0を認識したままだったのがよくなかったかと「fwcontrol -r」を3回実行したがいつものように

    (da0:sbp0:0:0:0): lost device
    (da0:sbp0:0:0:0): removing device entry
    

    が出ず、数回繰り返したが…
  • やられた。 完全に固まった。 諦めてreset。 うーむ。 HD caseの電源offした場合は、時間をあけず早めにda0を消しておくべきか。
  • んで、無事起動してきて… あれ？ 何かPPP接続がうまくいっていないんですけど… 嫌だなぁ。 が、これは今までもあったことなので、数分待ってからPPP接続し直すとうまくいった。
  • んでmozillaもちゃんと起動しないし… と、思ったけどbackground fsckが全部終った後にもう一度起動したら問題無かった。
• ふと、思ったんだけど、HDがチャンとしているかどうかのチェックでIEEE1394 HD case経由だと、なんかcase自体でエラーや警告を隠しているんじゃないかとの疑いが頭に。 挙動不審な60GB HDが数秒毎に読み書きの繰り返しになったのは勝手にATA66ぐらいからPIO modeに変わったんじゃないかと。 明日にでも1台PCをばらしてそっちに繋いで実験してみようかな。
• IEEE1394 HD整理作業:
  • 外付けHDに退避してあったデータを内蔵HDに戻すの次の録画までに間に合わないかと思ったけど、間に合いそう… と、思ったら2GBぐらい間に合わなかった。 んで、止めたら… あれれ？ 次の録画予約はもう5分遅いことに気がついていなかった。
  • ということで、今週分の録画予約分の整理。 あれれ。 どうも外付HDに退避した時の抜けがもう一つあったようだ。 ま、いいか。 大したことなさそうだし。
  • とりあえずここまでにするかな。 まだToDoはそれなりに残っているけど。 また、crashとか食らわない限り、山は越したように思う。
• もう今日じゃん。 っていつでも有効な言葉か。 ^^;;

2005年1月6日

• IEEE1394 HD整理作業再開:
  • とりあえず250GB HDが安全だと理解したいので「cd /dev;dd if=da0 of=null bs=128m」を実行中。 書き込みについては、昨日のテストでOKそうなので、とりあえずいいことにする。 「iostat 1」を見ていると25.1MB/sぐらい出ているので、3時間弱で終る予定。 どうでもいいけど、この手のテストって最近のHDの大容量化にともなって時間かかるんだよなぁ。 手順は分かっているので、まぁ確実に1 stepずつ進めばいいのだけど、GV-MVP/IDV動かしている時はBUS占拠になって、チャンととれなくなったりするからそういう時は外さないといけないので、なかなか進まないのが難点なのだが。 あと、どうもFreeBSDのIEEE1394 HDを読む関係のdriverか、K3500TEAのIEEE1394→ATA変換器のどちらかの問題だと思うけどFreeBSDが半固まり状態になるので、やっぱり寝ている間に… はあんまりやりたくないしで。 まぁとにかくこんなにdiskの読み書きを大量にすることになるなんて使い始めは想像できなかったから、USB1.1で妥協していたらとんでもないことになっていたな。 その点はよかった。
  • とりあえず250GB空読み無事終了。 ということで、昨日の読みとりエラーで失ったroot directoryにおいておいたcrashした60GB HDのimageを読みだし開始。 なんか気になるなぁ。 6秒読み出して、9秒止まるとかを繰り返しているぞ。 このペースだと読み出しに2時間弱かなぁ。 次の録画予約に間に合わない気がする。 うーん。 この60GB抱えこんだまま、しばらく頑張る必要がありそうだなぁ。 さて。
  • よく見ると、IEEE1394HDとATA HDの読み書きは丁度交互に起きているみたい。 んで、それにあわせて普通のATA diskのI/Oも何だかなぁな状態に。 ということでmplayerで試聴していても、10秒毎ぐらいに止まるので「mplayer -cache 65536」したら… 問題なく見えた。 普通のlocal HDでキャッシュを使うことになるとは思わなかった。 ^^;;
  • 思ったより読むの速そうだけど18:00に間に合うかどうかはかなりきわどいなぁ。 どのタイミングで停止をかけるか悩ましい所。 とりあえず「xclock -digital -up 1」を見ながら観察だな。 なんだか5%ぐらい間に合わない感じ。 ちょっと悔しいかも。 諦めてsuspendかけた。 次の2分のすき間では… しくじったら悲しいので、27分のすき間に再開だな。
  • 27分のすき間で7分ぐらい使って読みだし完了。 書き出すにはちょっと時間足りないので、次に時間がたくさん空く22時以降だな。 んで、万が一でうまくいくことに期待してfsckしてみたけど… やっぱりダメだった。
  • 次のあく時間までの時間潰しだと思ってmplayerで録画していたものを見ていたら久しぶりにX道連れにされた。 でもこれは見ているものがだいぶ壊れていたみたいなのが原因っぽいけど。 それにXをkillしたら復活したからまぁ大したことはないか。 それよりdiskのあきの見積りがちょっと甘かったようでなんかだいぶ危険領域にはいってきているかも…
  • なんとか耐え切ったみたい。 が、次の録画時間までの3時間で60GBを移動できるかなぁ。 いま、だいぶ内蔵diskを苛めているので、1.2MB/sぐらいしか出ていないということは… 全然ダメじゃん。 14時間近くかかることになる。 いま、diskを苛めているprocessを「kill -STOP」するか。
  • 一つ止めて1.35MB/s。 二つ止めて2.1MB/s。 三つ止めて4MB/s。 四つ止めて18MB/s。 五つ止めて19MB/s。 五つ目は再開するか。 これだと、一時間ぐらいで終るはずだから何とかなるだろう。
  • ad0なら邪魔にならないだろと別の作業を始めたら、突然静かになったので、やっちまったか？と慌てたが数秒後、例のごとく

    Jan  6 22:31:15 flu kernel: sbp0:0:0 request timeout(cmd orb:0x354a4154) ... agent reset
    Jan  6 22:35:03 flu kernel: sbp0:0:0 request timeout(cmd orb:0x354a428c) ... target reset
    Jan  6 22:35:03 flu kernel: sbp0:0:0 request timeout(mgm orb:0x354a43c4) ... reset start
    

    となった。 ad0の作業は関係なかったらしい。 んで、今までと同様HD caseの電源off/onを2回ほどしていくつかプロセスを止めるとかしたらなんとか復活してきた。 んで、驚いたことにさらに数十秒したら60GB fileのcpが再開している。 が、さすがに信じられないので、止めてumountして、fsckかけたらやっぱりおかしな所があった。 んで、念のためというか、soft updateを「tunefs -n disable」して停止して、最初からcpしなおし。 すでに10GBほど出来ていたので、appendでもよかったのかもしれないけどちょっと怪しいので止めた。
  • ようやく60GB HD imageのcpが終った。 ということで、外づけHDに退避していた録画予約分を内蔵HDに戻してみる。 うーん。 なんか10分ぐらい次の録画予約まで時間が足りない気がする。 ちょっとずつ進んでいるとはいえなかなかdisk整理も進まんなぁ。 このままだと、1394HD→内蔵HDのprocessは中断して朝まで放置かなぁ。 経験的にあんまりこのHD caseの電源入れっぱなしはしておきたくないんだよなぁ。 まぁ仕方ないか。

2005年1月5日

• IEEE1394 HD整理作業:
  • とりあえずもともと調子が悪かった60GB HDは諦めて、将来修復の可能性を考えて、中身を250GB HDにddで読み出して移動。
  • 250GB HDをしばらく取っておいてから消す用のdiskにすることにして、他のdiskの散らかっていたそういう中身を内蔵HDに移動。
  • 160GB HDの方で、そのうち消す内容は内蔵HDに移動したので、空き場所に不良があるかどうかを確認するために「dd if=/dev/zero of=big.bin bs=128m」でデカイファイルを作ってみる。
  • がーん。 「(da0:sbp0:0:0:0): MEDIUM ERROR asc:c,0」やっぱ出たか。 これって、LBAのどこなんだろうか？ 「(da0:sbp0:0:0:0): WRITE(10). CDB: 2a 0 5 88 b0 1f 0 0 80 0」から判明するんだろうか？
  • もう一度、disk fullになるまで書き出す。 なんか、大丈夫だったみたい。 うーむ。 あれ？ 「tunefs -m 0」していたつもりだったけど、出来てないじゃん。 んで、でかい場所を占拠するファイルを消してしまったので、やり直し… 2時間ぐらい無駄したか？
  • 1時間ぐらいで書き込み実験終った。 次に、250GBの方に内蔵HDに退避したデータを移動だ。 いや、その前に書き込み実験かな。
  • あ、また

    Jan  5 17:32:06 flu kernel: sbp0:0:0 request timeout(cmd orb:0x4ed6f634) ... agent reset
    Jan  5 17:33:06 flu kernel: sbp0:0:0 request timeout(cmd orb:0x4ed6f76c) ... target reset
    Jan  5 17:33:11 flu kernel: sbp0:0:0 request timeout(mgm orb:0x4ed6f8a4) ... reset start
    Jan  5 17:33:15 flu kernel: sbp0:0:0 sbp_reset_start failed: resp=16
    Jan  5 17:33:15 flu kernel: firewire0: split transaction timeout dst=0xffc0 tl=0x5 state=8
    Jan  5 17:33:15 flu kernel: sbp0:0:0 sbp_reset_start failed: resp=60
    

    を食らってしまった。 また、fsckで簡単に直らないdiskを作ってしまったかなぁ。 が、しばらくBUSを苛められないので、作業中断ということで。
  • やっぱりfsckすると、superblockが無いとかいっているし… ただ、今度はfsckしたら復活した。 念のため実行の2度目のfsckでは何もいわれなかった。 よかった。 んで、見た所、root directoryにあったものは全滅なのね。 今までもそうだったから、どうも今回もそうだということが分かった。 今後IEEE1394 HDで、root直下にものを置くのは止めるか。
• どうも午前3時をまたぐ予約が増えたので、daily scriptの実行時間変更をしてみる。 午前5時位なら大丈夫かなぁ。
• IACR ePrintのCGI scriptのdirectoryが変わっていた。
• なんか、ファイル操作しているうちにあるディレクトリ一式が無くなっていた。 どうも、操作ミスをしたらしい。 まぁいいか。 その分見る時間が節約できたということで。

2005年1月4日

• なんか今日(22:35)は事実上受信不能なほどNHKが見えないぞ。 NHKに問い合わせてみようかしらん？？？
• とあるInternetラジオの類をあとでまとめて聞こうかと思っていたらいつの間にやら最近4話分ぐらいしか残っていなかった。 よく見ると「バックナンバーはサーバ容量の関係上予告無しに削除される場合があります」とか書いてあった。 でも、URLに話数が書いてあってその数字を指定すれば聞けたりするのでは？ と思ったがg25lbxrdy4gdb.asfとかいうファイル名で、何かMAC値みたいなのがついていた。 g25の部分がいつも決まっていて、25の所が毎回incrementされているのは分かったんだけど、さすがにこれだと色々試す気がしないなぁ。 そういうこと考える人対策なんだろうけど。

2005年1月1日

• IEEE1394 HD case色々変な問題解決作業:
  • とりあえず250GB HDを接続してfsck。 何も問題でず。 あれ？ ここまではすでにやっておいたっけ？
  • んで、内蔵HDであるad1の中身の大半をこの250GBにcp。 といってもtarを使っているけど。
  • ほぼ2時間で95GB強を移動できた。 また、固まったらどうしようかと思ってしまった。
  • で、250GB HDから壊れかけている(?)60GBに繋ぎかえて、中身をそのまま「dd if=da0s1d of=/ad1/60G.ufs2 bs=128m」で吸いだし。
  • あかん。 なんか、また固まっている気がちょっとする。 時間かかりそうだけど、とりあえずbs=16mにしてやり直すか。 約1秒毎ぐらいにHDのアクセスランプが点滅している。 ということは、別にbs=128mでも固まってなかったか？ んーと、えーと、つまり16MB/1.6秒ぐらいの速度でしか読めてない？ ということは…2時間弱か。 別にそれならいいか。 1日とか超えるのかと思った。 ^^;;
  • 約10MB/sぐらいで、1.7時間で読み出せた。 んで「mdconfig -a -f 60G.ufs2」して「fsck_ufs /dev/md0」。 結構聞いてくるので、どうせ分からないだろうということで、-y optionを追加。 1分もしないうちに終った。
  • んで、念のためにもう一度fsck。 あれ？ また質問あるんですか？ もう一回やったけど、やっぱり聞かれる。 なんか、直せない場所ってあるのかなぁ。 うーむ。 よくメッセージを見ると

    NO lost+found DIRECTORY
    CREATE? yes
    SORRY. CANNOT CREATE lost+found DIRECTORY
    

    とか出ているし。 ナゼじゃ。 どないせいっちゅうんじゃ。 read onlyでmountしても何も見えないし。 「df -h」すると

    Filesystem     Size    Used   Avail Capacity  Mounted on
    /dev/md0        55G     36G     15G    71%    /mnt
    

    とは出るんだけど。 うーむ。 「-b 160」とかしても状況は同じだし。
  • Google様に尋ねても、ここまでcriticalな場所を壊しているのはあんまり無いようで、回復法が見つけられなかった。 それほど必要なファイルがあるわけではないので、あんまり時間をかけるのも問題なので、この辺で作業を一旦中断ということにしよう。
• 今年最初に受けとった非spam Emailは出すのが自粛されているものだった。 :-(
• HD case接続60GB不良問題:
  • ad1からの90GBのデータコピー中

    Jan  1 00:17:27 flu kernel: sbp0:0:0 request timeout(cmd orb:0x1626501c) ... agent reset
    Jan  1 00:28:09 flu kernel: sbp0:0:0 request timeout(cmd orb:0x16265154) ... target reset
    Jan  1 00:28:09 flu kernel: sbp0:0:0 request timeout(mgm orb:0x1626528c) ... reset start
    

    とか出て固まってしまった。 いや、なんとなくは動くんだけど、起動中のprocessをC-zしてもshellに帰らないし、多くのプロセスはC-cで止まらないし新しいコマンドは起動できないし。 disk書き込みがあるプログラムはそこで止まっていた。 読み込みは新たな読み込みじゃなくてすでにfile openしているものは大丈夫なんだけど。 んで、HDのアクセスランプは時々点滅はしているんだよなぁ。 でも、らちあかないので、HD caseの電源off/onしたら、復旧した。 でも、さっきと症状がにていて新しいdiskのはずなのにで気持ち悪いから念のためrebootしてみた。
  • 再起動してHD caseの電源入れっぱなしだったのにsbpがちゃんと動いていなかったけどBUS resetかけたらちゃんと認識した。
  • んで、念のためfsckしてみると…

    ** /dev/da0s1d
    Cannot find file system superblock
    
    LOOK FOR ALTERNATE SUPERBLOCKS? [yn]
    

    やっぱり。 何だかなぁ。
  • がっくりしながらさっきと同じ手順でfsckしてみる。 「-b 160 y」 optionつきで、結構いろいろ修復しているみたい。 んで、その後、もう一度-b option無しで… 今度は何もいわれなかった。
  • やっぱりlost+foundあったけど、まぁもともと大したものはいっていなかったから、まぁいいか。
  • んで90GBのcp再開は… 日が明けてからにしよう。
  • やっぱ、ここまで連続して食らうってのはHDケース(K3500TEA/BK)そのものの問題だったりするのかと気になってしまうなぁ。 とはいえ、もともとあるATA cableと電源cableをいじっているからその方の問題といえなくはないかもしれないけど。
  • 一応HD case開けて接続cableの確認をしたけど緩んでいるとかの問題は発見できなかった。 しばらく電源落して休ませて様子見るか。 ここのところずっと連続運転だったし。
• 正月になった瞬間にバンバン。 どっかで花火あげたりとか、バクチクとかしていたのかな。
• mplayer録画視聴中、時計が20秒戻ったら固まった。
• 予想通りというか、やっぱり今年最初に届いたメールはspamだった。
• いつものnotification schedule (1月まで):
  1/10 FSE'05, 1/24 SHARCS, 1/31 WCC'05, 1/31 Eurocrypt'05

今月の日記

日本語ホーム頁に戻る

本ページの主張等は著者の所属組織に全く関係なく、個人としてのものです。