計算機暗号屋日記 (2007年11月霜月)

2007年11月29日

床上室温がこの秋初めて20度を切って19度だった。机上は相変わらず20度以上で、23度だが。

2007年11月28日

11/16に書いた中央大学ミニワークショップ「2007代数曲線暗号を巡って」のweb pageが出来ていた。
mksnap_ffsで出来たsnapshot fileのtime stampは作成時じゃなくてfile systemをいじると時々刻々変わるみたいだ。ファイル名に日付を入れておいてよかった。

2007年11月27日

NISTがIBE関係のworkshopをするらしい。突然何故なんだろう。
IPA暗号フォーラム2006の今年版があるらしい。
12/4 notification予定のCT-RSA08のauthor notificationが既に行なわれたらしい。

2007年11月26日

11/22にBフレッツマンションタイプの50M→100Mの切替があるらしい。って、もう終っているじゃん。なんだそりゃ。 modemの電源を入れ直せとあるが、なんか入れ直さなくても使えているからよいのかな。入れ直すとそれとも速くなったりするのだろうか。

2007年11月25日

2nd PCから外づけHDへデータを書き出していたら…
- がーん。久々に
  sbp0:0:0 request timeout(cmd orb:0x47242d84) ... agent reset
  いかんな。とりあえずshutdownして出来る限りumountしてshutdown -pだな。しばらく冷やして様子を見よう。
- shutdown -pしてから30分以上しても落ちなかったので電源off。
- 45分ほど冷やしたので立ち上げてsingle user modeで「fsck -y」。あれ？ cleanのもやっちゃうのか。 multi-user modeで立ち上げてbackground fsckに回してもよかったな。と、思ったら無事umount出来たはずのfile systemに対して
```
** Phase 5 - Check Cyl groups
SUMMARY INFORMATION BAD
SALVAGE? yes

ALLOCATED FRAGS 57708568-57708575 MARKED FREE
BLK(S) MISSING IN BIT MAPS
SALVAGE? yes

ALLOCATED FRAGS 66146880-66146887 MARKED FREE
```
  うーむ。
- まぁいずれにしても問題なかったので改めてfirewireのHD caseの電源を入れて「fsck -y /dev/da0s1d」。
  sbp0:0:0 request timeout(cmd orb:0x43b9cc4c) ... agent reset
  うーむ。またか。一応HD case側はcableが抜けていないかとか確認したのだけど。とりあえず1st PC→2nd PCのファイルの転送が終ったらresetかな。
- shutdownしてumount -aしてreboot。 Uptime云々が出た後、先に進まないのでreset。 reset直前にPC本体側のfirewire cableの緩みがないことを確認。また、HD caseの方のPATA cableをHDから抜いて差し直して見た。起動ではreboot前に「All buffers synced.」までいったので、background fsckは走らなかった。
- 今度はHD caseの電源を入れても、ちょっと違和感を感じる音はしなかったので少し安心。なんかsbp0云々が出た後固まった時は、若干反応が悪いとか普段と違う音がしたとかあったような覚えがあるんだよな。結構その辺の人間の感覚って重要、と思っていたら「sbp0:0:0 request timeout(cmd orb:0x49de8c4c) ... agent reset」。さてどうしようか。もう一度、実験するか？
- とりあえず固まるとかなかったのでHD caseの電源offをした後にHD case側のfirewire cableの差し口を換えて電源on。無事deviceを認識した30秒後ぐらいにHDのseek音としては結構でかい音。よく見ると/devにda0s1dが二つ出来ているのは怪しいぞ。
- HD caseの電源offして、置いてある向きを90度変えて、もう一度電源on。やっぱり30秒後くらいにちょっと大きめのカリカリ音が。まぁでも、と思って「fsck -y /dev/da0s1d」したら… 「Can't open /dev/da0s1d: Device not configured」。ありゃりゃ。ということでreboot。今度は起動中からHD caseの電源を入れておこう。
- やっぱダメだ。とうとう何か壊れたかな。とりあえずreboot。
- 問題切り分けのため別のHDをHD caseに装着。メーカーは違うがたまたまpartition構成が同じだったのでfile system dirtyって訳じゃないけど「fsck -y /dev/da0s1d」してみる。無事通ってしまった。
- 今度こそと思ってもう一度、問題のHDに接続し直して「fsck -y /dev/da0s1d」に挑戦。やっぱダメか。 HDが壊れたかな。しかしタイミングよく壊れるものだな。中身を読めるだけは読み出したいが、出来ればPATAで直接して見てみたいな。どうしようか。
- とりあえずfirewire経由ではあるけどmount -rで読める分だけでも読み出そうとしたけど、lsしただけで固まった。
- 1st PCから鳴っていたカラカラ音が聞こえていたら、その原因追跡と同時に直接PATA接続もしてもいいんだけど今は静かなんだよな。さて。
ありゃ。 2nd PCで
```
ad6: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=380575807
ad6: TIMEOUT - WRITE_DMA48 retrying (0 retries left) LBA=380575807
ad6: FAILURE - WRITE_DMA48 timed out LBA=380575807
_vfs_done():ad6s1d[WRITE(offset=194854780928, length=131072)]error = 5
```
master SATAだけが壊れているのかと思ったが、slaveも問題か。またPATAに入れ換えるか。 PATAの予備は250GBだけか。ここででかいPATAを買ってくるのも何か敗北している気がするしなぁ。それをするぐらいならPCの買い換えだよな。 SATA boardを差すというのもあるけど。そっか。 2nd PCならPCIの空きもあったかな。もうちょっと様子を見てから考えよう。

2007年11月24日

せっかく出かけない週末なので引越し荷物整理を計画。
- ベッド下の本の山をどうしようかと思ったけど、まずは服の整理かと思った。んで、とりあえず収納家具を置く予定の場所の縦横高さを計ってOlympicへ。で、それなりにいい感じのものはあったが、ふと我に返ると、そんなにたくさんの服はもっていないような気が… まずは、段ボールにはいっている服を全部取り出して量を確認してからにしようかと思った。
- 引越ししてかなりすぐに買った6段収納棚。実はA4を立てられないことが発覚。これは失敗。何か寝かせて引出して使える収納を求めて100円ショップにいったけどイマイチ気に入るのがなかった。明日にでも文房具屋で見てみよう。
- そろそろ風呂桶にお湯を入れて浸かりたくなった。まぁ体感で温度を見てもいいのかもしれないけど100円ショップで温度計を買ってきてみた。
- 収納具と温度計を求めて行った100円ショップで温度計付時計があった。 525円だったが、枕元に欲しいと思っていた機能をほぼ揃えているので買ってきてみた。これを机上に置いて今机上にあるのを枕元に移動しよう。
新エアコンになったので、学習リモコンKURO-RSが使えるかと期待して実験したけど駄目だった。どうも、KURO-RSで扱える240バイトを越えてコマンドが送られているような気がする。
ここ一週間ほどPCのfanの軸がずれているような音が周期的にする。音の出ている場所からして1st PC or 2nd PC。 2nd PCをshutdown -pしても音が出ていたので、1st PCのようだ。 1st PCなら2nd PCよりは取り出しやすい位置にあるので、録画予約のタイミングをよく見て開けてどのfanがおかしいかの特定は… 明日には出来るかな。
19日以降、一度も熱帯夜にならないので冬支度。
- コートを出した。
- 掛け布団も出した。んで、ついでにシーツとかの洗濯をして乾燥器にかけたら… しわしわ。まぁ気にはしないが何か次回には吊って干せるような仕組みを検討しておいた方が気持ちよく使えそうだ。
- 掛け布団はやっぱり幅があるせいか、ベッドの横に増設した棚においてあったものをふっとばして落してしまった。ちょっと使い方を考える必要がありそうだ。
↓引続きsnapshot実験:
- FreeBSD-users-jp MLに聞いてみようかと思ったけどその前にやっぱりファイルが消えるのは変だと思ってもう一度実験。
- snapshotをすぐ作れる/tmpでの実験。ディレクトリは… 元のを消してもsnapshotに残っているじゃん。ファイルは…残っているじゃん。でかいファイルじゃないと駄目なのかな。昨日消したのよりでかいのでは… 残っているじゃん。
- でかいファイルについてはdfで見ると、消した直後では空きが消した分だけ増えているが、syncしたらたくさん使っていることになった。正しい挙動だ。
- おかしいなぁ。これだと期待している挙動になっているよなぁ。もう一度、消したらsnapshotのファイルも消えたfile systemで実験。
- 理由判明。消したファイルは違うfile systemにのっていた。orz 単にsymbolic linkに気がついていなかった。
- 今度は300GB以上使っているが、ファイル数が1000もないところに対してmksnap_ffsしてみた。 4分強かかかった。前の実験では90万弱のファイルで70GB弱のファイルシステムに対してやっぱり5分ぐらいかかっていたので、ファイル数は実行時間にあんまり関係ないようだ。
- ということで主目的である1st PCに対して実験。 mksnap_ffsすると、disk I/Oが結構あるので、fwcontrol -R中の実行ではどうなるか確認。やっぱり「fwohci0: IR DMA overrun (0x40008011)」が出まくった。
- 普段録画に使っているNCHUNKを増やして作り直したfwcontrolだとどうだろう。これでも駄目だった。 mksnap_ffsは相当HDを占有するみたいだ。
- とすると今度は自動的にsnapshotを作る手段だがどうしよう。とりあえずports/sysutils/freebsd-snapshotとか、ports/sysutils/snapとかあるようだが、単にcrontabに書くのと比べてどれくらいいいのかなぁ。
- それ以前にどういうスケジュールでとっておこうか。結構snapshotを作る負荷が高いので、1日1回ぐらいが妥当だろうな。下手にencodingもとのTV録画の一時ファイルが残っていたりしてあんまり世代数が残っているとすぐdiskが溢れそうだし。何世代とっておこうか。 .snapディレクトリはユーザーが勝手に使っても大丈夫なのかな。 dumpのsourceを見ると.snap/dump_snapshotという名前じゃなければぶつからないみたいだが。
- sourceをfgrep -rしたところfsck_ffsが.snap/fsck_snapshotというのを使うようだ。
- /etcとかが含まれるシステムファイルはいろいろいじったと自覚がある時に手動で取っておくかな。 /homeの類は1世代あれば十分かな。「あ、間違って消した」は時々あるけど、「3カ月前に消したファイルが欲しい」とかはまずないもんな。そうでなくてもhomeがほぼ毎週、手動だけどbackup取っているし。ということで「cd /home/.snap;mv old{,-};mksnap_ffs /home old;rm -f old-」ぐらいで十分か？
- とりあえずシステムファイルとかを手動でsnapshotを.snapに作っておこう。そっか。 operator groupに入っていたらrootになる必要はないのだな。
- でかいfile systemに対して同時にmksnap_ffsをかけてみた。 1つ実行する場合の実行時間の2割増しぐらいですんだので、全体の実行時間という意味では、逐次実行よりは早く終ったけど、途中、かなりいろんなものが止まったので、やめた方がよさそうだ。消す方については同時実行でも逐次実行でも実行時間にあんまりさはないようだ。
- とりあえずcronで毎日homeとかのsnapshotを取ることにしてみた。

2007年11月23日

また何故かmvとrm間違ってファイルを消してしまった。 mvの直前にrmしてしまったせいで打ってしまったんだろうか。
- ということで前から気になっていたsnapshotに挑戦してみよう。
- 何か破壊的なことが起きても嫌なので、2nd PCで実験。まずは「mksnap_ffs /tmp /tmp/s」。 1.4MBしか使っていないせいか一瞬で終了。 ls -lでは2GBというのはpartition sizeかな。 duでは1.3MBということで、dfの数字とほぼ同じか？しかし、dfでの使用量は全然変わらなかった。
- 「mdconfig -a -t vnode -f /tmp/s」して「mount -r /dev/md0 /mnt」。ちゃんと全部見えた。
- 「umount /mnt」して「mdconfig -d -u 0」。のちsnapinfoしたらちゃんと/tmp/sが出てきた。
- 「rm /tmp/s」したらちゃんとsnapinfoで出てこなくなった。
- 「/mksnap_ffs /tmp /tmp/00」から19までsnapshotを連続して作っていったらmanualにある通り20個目は作れず「mksnap_ffs: Cannot create /tmp/20: No space left on device」といわれた。
- 次はちょっと大きめのpartitionに挑戦。 66GB使われていて131GB空いているところでmksnap_ffs。 UDMA100で接続してあるHD。 3分17秒で終了。 ls -lでは220GBのファイル。 duでは130MB。
- 出来たsnapshotのfileをrmするのにも時間がかかった。こっちは時間がかかると考えていなかったので、もう一度snapshotを作って時間を計ってみた。今度は作るのに5分13秒、消すのに1分16秒。出来たsnapshotのtimestampはmksnap_ffsを実行開始した時間ではなく、終った時間だった。
- snapshotを作ってから、もとのfile systemにあるfileを消したら… あれ？ snapshotの方も消えてしまうのか？これだと、今回の目的に合わないぞ。私の理解と違うのか???
今日の夕食は甚五郎。ちょっと高いかと思ったら値段相応の量だった。麺は美味しかったけど汁はちょっと趣味と違うな。禁煙っぽかったのは嬉しい。
↓30分ほどしか集中力が続かなかったので続きは明日。
今月査読多過ぎ。いや、断っているのもあるんだけど。ちょっと国際会議とか固まり過ぎだよなぁ。少しでもやる気が出る時に論文を読まねば… あれ？何故両面印刷の最終ページだけ上下さかさまなのだ???
RC5-72 challenge0.455%突破。一昨日のペースだと全空間探索にあと1272年。 3年4倍で解読速度が向上するとすると28年。

2007年11月19日