計算機暗号屋日記 (2018年6月 水無月)

2018年6月30日

• いつのまにやらネットが切れている。 CG-WLR300NMの管理画面にもつながらない。 ということで、電源off/onで復活。 前回の再起動は6/11。

2018年6月24日

• 引続き外付けHD整理:
  • なんか同じものがあちこちのHDに分散しているようで混乱したが、とりあえず現状把握。
  • もともと750GB HDにあったもののうち、89GBを250GB HDに移動。 今日のうちにとりあえず1/4縮小済のものを外付HDに追い出して、一時的に内蔵HDに来ているものも外付HDに追い出したいところ。
  • 89GBの書き出しは無事終了。 で、750GBのディスクあるものの書き出しが全部終ったかと思ったらあと20GB残っていたのでそれも書き出し。
  • こちらは無事14分弱で終了。 次は行方不明になっていたと思ったけど見つかった1 titleを移動。
  • とりあえず1/4縮小済のものの整理を終えた。 次は、1st PCに退避してあるものを放置していると苦しいので、一旦500GB SATA HDに書き出すことにする。
  • とりあえず全部書き出せた。 400GBほど書いたか。 あと、750GBにちょっと他に移動していないものがあるので、それを1st PCに読みだし。
  • 32GBほどなので、すぐ読めた。 これを500GB HDの方に書き出し… と思ったら1 title入らないな。 ちょっと工夫が必要か。
  • 現状、外付HDに入っているデータは全て1/4縮小対象とすることにした。 もちろん、イイ奴はそのままで残しておくが。 ということで、一度書き出したが、また、1st PCへ1/4縮小対象となったものを読みだし。 46GBほど。
  • んで、確認したらなぜだか殆んどのものが既に1/4縮小済だ？？？ なんか記録が変だな。 まぁいいや。 縮小されていないものを縮小しよう。

2018年6月20日

• 引続き外付けHD整理:
  • とりあず書き出し終了。
  • 400GB SATAの1/4縮小のはどうするかなぁ。 基本的に小さなところから埋めていってはいるけど、このまま行くと埋まりそうだからそのままでいいか。
  • 500GB SATAの方は… これもいじらなくてよいかなぁ。 微妙なところではあるが。
  • んで、次の250GB PATA HDのzero fillと空読みを仕掛けて寝よう。
  • エラーなく無事終っていた。
  • もう一台の250GB PATA HDについても同じことをしよう、と思ったがPATA cableがささらない。 よく見るとpinが曲がっている… 頑張れば使えるようになるだろうけど、そこまでするほどのものではないと思うので、廃棄処分することにしてみた。

2018年6月19日

• 引続き外付けHD整理:
  • 1st PCに750 GB中にあった残り全ての1/4縮小済のを移動して、このpartitionの空き218GB。 2日、放置するとディスクが溢れるな。
  • んで、早速、外付の250GB PATA HDに書き出し。 うーん。 このペースだと日が変わりそうだなぁ。 しかたないか。

2018年6月18日

• 引続き外付けHD整理:
  • 750GBから残りの1/4縮小済のを1st PCへ移動。 250GBぐらいかと思ったら300GB以上あった。
  • とりあえずは何とかなるけど、1st PCの空き容量が500GB弱。 いろいろと綱渡りだな。 どうしようもなくなったら時間が無駄にはなるが一旦、750GBから持ってきたのを消すというのもあるけど…

2018年6月17日

• 引続き外付けHD整理:
  • 0-fillと空読みの双方で問題がなかった。 ということで、いつものように「fdisk -i」で、最後の書き込み以外はそのまま、「bsdlabel -w」「bsdlabel -e」して、d partitionだけ有効にした。
  • 一方750GB HDの方の1/4縮小分はSATA diskの中にあって、もったいないので、これを250GB PATAに移動すべく、内蔵HDに移動。 全部で600GB弱あって、内蔵HDの空き容量が500GB弱。 仕方ないので、とりあえず250GBぐらいのみをまずは内蔵HDへ移動。
  • 無事、読み出せたので、今度は正確に調べて226GBが有効ディスクということで、それだけ書き出し。
  • こちらも無事書き出せた。 書き出した分は内蔵HDから消去して次に備える。
  • んで、もう一つ発掘された250GB HDについて、こちらも念のためzero fillと空読み実験。
  • bs=32mの読み込みで、iseek=2038でエラー。 もう一度、そこに上書きしたら読み込みエラーは起きなくなったので、大丈夫ということにしよう。

2018年6月16日

• 引続き外付けHD整理:
  • 250GB PATA HDがいくつか発掘された。 そのまま使ってもいいのかもしれないが、念のため0-fillと、空読みを実験。

2018年6月12日

• 昨日のWi-Fiがブチブチきれる現象について。
  • なんか継続しているみたいだ。 不安定。
  • HD recoderまでの経路に無線LAN区間があり、疎通しているかどうか記録続けている。 これを見ると、不通率は:

    35.7% … 6/12(22時頃まで), 12.6% … 6/11, 3.7% … 6/10, 0.1% … 6/9, 0.1% … 6/8

  • 確かに、6/10頃から何か起きているっぽい。 スマホのWi-Fi設定画面をつけたまま部屋の中を歩き回ったところ、なんか見えるAPが増えたな。 隣かどこかかに新たにAPが設置されてchがぶつかっているのかもしれない。
  • Note PCで「ifconfig wlan0 list scan」して回ってみる。 うわ。 普段、私がいる部屋では4つぐらいしかスマホでAPを認識しなかったので意識していなかったが、40以上広う場所がある…
  • さすがにこれだと「sort -n +2」を眺めるぐらいでは訳がわからないので、

    ifconfig wlan0 list scan | perl -e 'while(<>){@_=split;if(\!defined($m{$_[2]})||$_[4]>$m{$_[2]}){$m{$_[2]}=$_[4]." ".$_[0];}}foreach $i(keys %m){print $i," ",$m{$i},"\n";}'|sort -n
    

    といったことをして、歩き回って調査。
  • これまではch 1で平和だったのだが、ch 2にそれなりに電波の強い奴がいることが判明。 どうもch 7辺りが一番すいているようなので、そっちに変更。
  • とりあえず数分見て接続が安定しているように見える。
  • なんか最近トラブルが多いような気がする。orz
• 引続き外付けHD整理:
  • 不良セクタ探索をしていたHD。 7時間ほど経過したところで確認したところ、最初に発見した不良セクタから連続して3700個以上も不良になっていた。 こりゃ、駄目だということで、やっぱり当初予定通り破棄することにした。

2018年6月11日

• なんかWi-Fiがブチブチ切れるので腐ったのでCG-WLR300NMを管理画面から再起動。 復活したようだ。 前回の再起動は6/10。

2018年6月10日

• 加湿器のいわゆるカルキ取りについて、いつもマニュアルを参照するのが面倒なので、数字だけ転記: 水150g、クエン酸8g
• なんかDNSが腐ったのでCG-WLR300NMを再起動しようとしたら管理画面にもつながらないので電源off/on。 復活したようだ。 前回の再起動は5/15。
• 引続き外付けHD整理:
  • 書き出しも無事終了。 あと、既に1/4縮小済のものもおよそ70GBほど書く余地があったので、書き出してこのHDの作業終了。
  • 次は昔2009年頃まで利用していたmain CPUとしてPentium 4を使っていた時代の1st PCの2nd HDが出てきたのでこちらの中身をまず確認。 いくつかの録画データが残っていたが、ほとんどが保存済か、一旦見て捨てているものだった。 といっても若干引き上げられるものがあったが。
  • んで、newfsして、fsckして、1/4縮小済のものを書き出し開始。 zero-fillとかの書き読み試験はいらないと判断。 227GBほどあったので、3時間弱で終る見込み。
  • まだ書き出し中ではあるが、なんか1 title無くなっているのはなぜだろうか？ あとで調査。
  • さて、溜りまくっている録画データを書き出すのはいいけど、それ以前にちょっと1/4縮小作業を始めた方がいいかな。 とりあえず既に外に書き出しているものを全て1/4縮小とするか。 しかし、それをしていて、内蔵HDが溢れる前に終るだろうか。
  • 多くのものは外付HDにあるが、一部内蔵HDにあるので、それの1/4縮小作業を始めてみた。
  • 調べてみたら放送終了で、そのうち外に書き出そうとしているものは1.8TBほどあることが判明した。 先は長そうだ。
  • 無事、227GBの書き出し終了。 んで、もとの750GB SATAの方に、なくなったかも知れないtitleを確認したら… ちゃんとあった。 次の書き出し用に内蔵HDに退避。
  • んで、次の1/4縮小用にfullsizeのものを内蔵HDに複写。 103GBほどなので50分ほどで終る見込み。
  • もうちょっと、fullsizeのものが別の外付HDにあるが、内蔵HDの空き容量が気になってきたので、後回しにすることにした。
  • 250GBで読み込み不良があるディスクの不良セクタ登録でどこまで使えるかの実験。 まずは、とりあえずnewfsして、fsckで結構もうダメか。 なんか、いろいろいじった後だったかな？
  • とりあえず頭を潰して「fdisk -i」「bsdlabel -w」「bsdlabel -e」して最初からやり直してみる。
  • さっきよりはerrorは少ないけど、既にfsckで引っかかるなぁ。 もう一度fsckしたら通ったのでいいことにする。
  • んで、1 sector毎に見た方がいいんだろうけど、 時間もかかるので、まずは「dd if=da0s1d of=null bs=32m conv=noerror,sync」。
  • とりあえず引っかかったところを記録: 780, 943, 1327, 1328, 1329, 1330, 1334, 1335, 1336, 1343, 1344, 1350, 1365, 1366, 1372, 1582, 1590, 1629, 1667
  • それぞれの場所で上書きしたら、最大10回ほどの上書きでread errorを起こさなくなった。 ということでもう一度念のため空読み実験。
  • やっぱり引っかかるところあるな: 1331 1332 1336 1337 1338 1344 1345 1351 1366 1367 1584 1592 1631 1669
  • 今度はいくつかの場所は10回以上上書きしてもエラーが解消しなかった。 全体を見るのは時間が2日以上がかかるが、32MB単位で、700〜1800の場所なら1セクタ単位で見に行っても7時間ほどで済みそうなので、とりあえずそれで確認。

2018年6月9日

• 引続き外付けHD整理:
  • 古めのHDがいくつか発掘されてきたのでいじったのだが、なんか信号線の不良なのか反応しないのが多い。 なぜなのだろうか？
  • 反応するのも、不良セクタがあったりするのは頑張れば使えるんだろうけど、zero-fillとかで引っかかるぐらいなので、badsectでどういう数字を指定すべきなのかよくわからんのだよな。 filesystemで対応するということで何か数字がずれていそうだし。 昔、実際に運用中のHDについては何かした覚えがあるんだけど。 OSじゃなくて、S.M.A.R.T.の方で、reallocated sectorで対応してくれると嬉しいのだが。
  • 調べてみたら、badsectコマンド萌えに、そのfilesystemを「dd conv=sync,noerror」で出てきた入力recordを指定したのでそれでよいのかな。 ここでは、1 sector単位の入力なので、一体時間がどれだけかかるかわからんな。 32MB単位とかでやって2分探索する方法はなくはないが、人間的手間がかかるし。
  • ということで、容量の少ないPATAの再利用はしばらく諦めて、というか1st PCの内蔵HDの容量がかなりヤバくなってきたので、SATAの一番小さな400GB HDを1/4縮小録画データの保存にすることにした。
  • んで、とりあえず本体に読みだし。 残念ながら1 filesystemで全部読めるだけ空いているところはないのだった。 という辺りでやばい感じ。 早くdisk整理を進めねば…
  • 3時間ほどかけて、1st PCに読み出した。 372GBほど。 newfsしなおして、既に1/4縮小済のものを書き出し。

2018年6月5日

• RC5-72 challenge5.200%突破。 昨日のペースだと全空間探索にあと574年。 3年4倍で解読速度が向上するとすると27年。

2018年6月4日

• 引続き外付けHD整理:
  • あと29GBほど書き出しがあるようだが、そろそろ寝たい気がする。 放置もありだけど、firewireつなげっぱなしってあんまりいい記憶がないんだよな。 ここで止めるのもナンだし。 あと25分ぐらいか。 まぁ待つか。

2018年6月3日

• 引続き外付けHD整理:
  • 6/1のdisk errorが出た件、すごく久しぶりにS.M.A.R.T.情報を取ってみた。 Reallocated_Sector_Ctはゼロだったが、Raw_Read_Error_Rateは171Mほど、Seek_Error_Rateも22Mで、それなりにエラーが出ているようだ。 温度も43度ということで、決して低くはないな。 しばらく様子見かなぁ。
  • その、問題となった例のファイルは、もう一度エンコしなおしたらなぜだかサイズが大きかったので、何か作成途中にも問題が起きていたようだ。 とりあえず消して、もう一度書き込む時に自動的に再配置セクタが割り当てられることを期待しよう。
  • さて、内蔵HDに作業途中データを895GBも抱え込んでいて、いろいろと作業に支障を来し始めているので、とにかく書き出せるものをどんどん書き出す。 まずは、1/4縮小されている録画ファイルで、一時的に内蔵HDに持ってきているのを容量の小さな外付HDに書き出す作業からかな。
  • まずは、前回、作業途中だった160GB HDへの書き出しで34GBほど空いているところへの書き出し。
  • 23分ほどで書き出し終了。 んで、次はこれまでFreeBSD/i386と1st PCをしてたときに内蔵HDに使っていた250GB PATA HDに書き出す。 とりあえずbsdlabelで全てを1 partitionにして、newfsして、fsckしたら… 変なseek音がしたかと思ったら、なんかread errorを起こした。 とりあえずcontinueしていたが、怪しい状態が継続。 あきらめて0 fillしようとしたら… operation not permittedとか怒られる。 firewireをresetしたが変化なし。 とりあえずfirewireの方を電源off/onしたら、0 fillを開始できた。 これで、読めない不良セクタの再配置が行なわれ復活するとよいのだが。
  • おおよそ25MB/sで書いているようなので、3時間弱かかるな。 読み込み試験もした方がいいかなぁ。
  • 無事書き込みは終了。 気になったので、やっぱり、読み込みもすることにした。
  • んで、案の定エラーが出た。 エラーが出た部分にもう一度書き込みをして読んでみたが… やっぱりエラー。 もう一度してもダメ。 ここだけOSの不良セクタ登録をして、次の読み込みをしたら… またエラー出現。 まぁ頑張ればなんとかなるのかもしれないけど、あきらめて不良ディスク扱いということで別枠保管だな。
  • んで、手持ちのHDを見ていくと250GB HDはあと2つあった。 一つはすでに一度見たら消すということでループさせているディスク。 こっちは、とりあえずこのまま継続かな。
  • もう一つは永久保存のつもりで取っておいた奴を記録しているもの。 既に今回の大規模見直しの外付HDの整理作業のかなり初期に内蔵HDに移しているので好きに使える。 んで、mountして、ちょっと中身を見て… おや？ なんでここで固まる？
  • ちょっと怪しさを感じたので、こちらのHDのzero fillと空読みを実行することにする。 しかし、時間かかる作業ばっかりになってしまったな。
  • 大体21.4MB/sで書いているようなので、3.2時間ぐらいで書き込みは終了する見込み。
  • 順調に進んで、3時間ほどで終った。 エラーもなし。 ということで、先ほどの教訓(?)読み込みも実施。 今度は29.5MB/sぐらい出ているので、2.4時間ほどで終る見込み。
  • 無事終了。 ということで「fdisk -i」「bsdlabel -w」「bsdlabel -e」「newfs -m 0 -o space」して、fsckも無事通った。 んで、1/4縮小ファイルの書き出し。

2018年6月2日

• 引続き外付けHD整理:
  • とりあえず750GB Hから1/4縮小した録画ファイルを1st PCに複写。 全部で564GBほどなので、現在のペースが続けば4時間強で終る。
  • 途中でちょっとずつペースが落ちていって4.6時間ほどかかった。

2018年6月1日

• 録画された動画のチェックをしていたら

  (ada1:ata2:0:0:0): READ_DMA48. ACB: 25 00 40 d1 62 40 2d 01 00 00 00 01
  (ada1:ata2:0:0:0): CAM status: ATA Status Error
  (ada1:ata2:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 40 (UNC )
  (ada1:ata2:0:0:0): RES: 51 40 00 d2 62 2d 2d 01 00 00 00
  (ada1:ata2:0:0:0): Retrying command
  g_vfs_done():ada1p1[READ(offset=2588885024768, length=131072)]error = 5

  がーん。 なんか嫌だなぁ。 いま、外付HDの整理も続けているので、あんまりディスク的に余裕がないし。 内蔵HDのうち、一番新しい奴なのに… とりあえず勝手に復旧したので、様子を見るかな。 ちょっと問題が起きたファイルを触るのはしばらく止めておこう。

今月の日記

日本語ホーム頁に戻る

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