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

2019年1月25日

• 引続き内蔵HD確認作業:
  • うーん。 録画ファイルを整理していたらやっぱり3TB HDでread errorが出てしまった。 これぐらいのエラー再現率で修理してくれるかなぁ。

2019年1月15日

• 引続き内蔵HD確認作業:
  • そういえばS.M.A.R.T.情報を見ようかと思っていたのだった。 が、「smartctl ada0」では「ada0: Unable to detect device type」とか怒られて見えない。 /devをcurrent directoryにしていても 「smartctl -a /dev/ada0」などとする必要があるらしい。
  • 内容を見たけどread errorだのseek errorだのはそれなりの桁数記録されているけどreallocated sectorはなかった。 あと、いくつかエラーの記録はあったけど。 うーん。 ようわからん。 何か起きていない訳ではないけど、といったところ。 とりあえず「smartctl -t long」してみた。 5時間ほどかかるらしい。
  • complete without errorらしい。 うーん。 しばらく使って様子見かなぁ。
  • とりあえずこれまでしばらく失敗していたmksnap_ffsは問題なく実行できた。
  • 3TB HDを使うといっても「ファイルが壊れるかも」と思うとちょっと使いづらい感じ。 といっても、2TB HDの空きもあんまりないので、とりあえず、しばらくおいておくだけの録画中間データ置きに使うことにしよう。 といっても、これまでも書き込みでエラーは出ず、読み込みの時だけ起きていたので、なんらかの読み込み試験を定期的に実施する必要はあるな。

2019年1月14日

• 引続き内蔵HD確認作業:
  • さて、次はどうするか。 いきなり3TB HDをいじってもよいのだが… うーん。 また、起動でトラブルになると嫌だから、もとroot diskのPATA diskを外してからにするかな。
  • うっかり忘れかけたfstabの起動ディスクとかの修正をして電源off。 PATA diskの電源cableを抜いて起動。 BIOSでboot diskを変更。 んで、kernelだけが立ち上がる… という残念な自体にはならなかったものの、録画保存用の内蔵HDについてもada番号が狂っていて、single user mode。 fstabを修正して起動。
  • 3TB HDの方に最後まで残っていた自動録画系のファイルを2TB HDに移動。 のち、0-fill開始。 2TB HDの容量に余裕がないのと、残りが少なくてdisk accessに時間がかかってしまうことから、手際よく作業してできるだけ早く終らせたい。
  • iostatで見ていると、とりあえず200MB/s弱ぐらいで書き込めているようだ。 ということで、5時間もあれば終るかな。
  • 当初見積りだとあと1時間ぐらいだが、段々遅くなっていて現在120MB/sぐらい。 最初の2.5時間ぐらいが200MB/sぐらいで、そこから2.5時間ぐらいかけて120MB/sぐらいまで線形に遅くなっているようだ。 でも、そろそろ終っていいような。
  • 計算違った。 さっきの計算時点ではあと1.3時間ぐらいだった。 ということで、残りあと1時間はないな。
  • ちょうど5時間ぐらいで終った。 エラーなし。 平均160MB/sぐらいで書き込めたようだ。 んで、今度は空読み。
  • こちらも当初は200MB/sを越えている感じ。 でもやっぱり段々遅くなるんだろうな。 そうなるとすると、今日中には終らない見込み。
  • 空読み開始から2時間。 エラーなし。 今回の症状は古いデータを読む時にエラーになるという訳ではなくて新たに作成したデータについても読み込みエラーが起きるということだから今回の全体0-fillで直るかどうかはわからんのだけれども。
  • 全空読み終了。 エラーなし。 まぁ想定通りかな。

2019年1月13日

• 引続き内蔵HD確認作業:
  • もとroot diskに1/4縮小済データをいれるのはいいけど、現状で本当にこれを外して大丈夫かどうか不安という問題もある。 一度にまとめていろいろやると問題が起きた時の原因の切り分けも難しいし、復旧も大変になるから面倒でも一つずつやるかなぁ。
  • ということで、root diskの電源を外して起動。 同時にSATA PCIカードを刺すことも考えたが今回はなしということで。
  • やっぱりこれでよかった。 BIOSでboot diskを変更しなければならなくなるのはともかく、M/Bの方で、IDEなしになるとSATAの方のchannel番号が変わるらしく複数回起動し直しするはめに。
  • ということで、PATA diskを外す際は忘れず/etc/fstabを直さなければということで。 んで、外したroot diskをfirewire経由でいつものように外づけHDとして、録画データを複写してもよいのだが、IDE直結の方がもちろん速いので、もう一度接続し直してSSD root diskから起動。 んで、bsdlabel、newfsして、1/4縮小済のデータを書き出し。 ざっと容量を見たところ、ちょうどぴったし収まりそうな感じ。
  • ん？ よく見ると3TB HDから2TB HDに移動したところに、新たに録画したデータを書いてしまっているような。 これはちょっとまずいな。 今のうちに2TB HDに移動せねば。 3TB HDは0-fill予定なので。
  • あれ？ なんかHTTP serverが上がっていないぞ。 数日前にまとめて「pkg upgrade」した関係で、依存libraryがいなくなって起動していないようだ。 「pkg unlock」して「pkg upgrade」しなおしだな。 3TB HDの様子見とは関係ないが、再起動した関係で発現したようだ。
  • とりあえずapache問題は解決。 んで、間違って移動元に保存してしまった新しいファイルはどう探すか。 とりあえず今年に入ってからのものを一つずつ見るかな。 全部で83ファイルか。 ま、しかたないな。
  • すでに移動しているものを見つけるたびに対象ファイルを減らしていけることに気がついた。 83→42→38→26→19と減っていって実質的に3ファイルだけだった。
  • もとroot diskへの1/4縮小番組を複写終了。 思ったよりは早く終った。 空きは1GB弱。
  • んで、2TBの方のディスクから移動したデータを消去して、そこに3TB diskのまだ複写していないデータを移動… と、思ったら空いていないな。 そういえば、mksnap_ffsでうっかり消し対策をしているのだった。 毎日のbatchを待たなくても手動で作業してもよいが… 恐いので、明日にしよう。

2019年1月9日

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

2019年1月7日

• 引続き内蔵HD確認作業:
  • とりあえず録画PCに123GB弱移動してみた。 これで残りをroot diskに複写したら… いや、それだと作業領域が残っていないな。 1/4縮小済のものを旧root diskに移動する必要があるな。 それぐらい空けておけば、数日はもちそうだ。
  • ということで残りの513GBほどをSSDにtarでまとめて複写しようとしたが、50GB弱を複写したところでdisk errorにぶつかってしまった。 仕方ないので、1 title毎に複写。

2019年1月6日

• 引続き内蔵HD確認作業:
  • あと、640GBほど。 なんとか、他に動かせなくはないけど、そのままの状態で数日はおけないな。 root diskはよく考えたら、そのうち1/4縮小した録画ファイルをおく予定だったので、まずは、それを書き出すかな。 録画PCの方も100GBほどは使えるかもしれない。

2019年1月6日

• 引続き内蔵HD確認作業:
  • root diskの方をSSDに交換してから快調。 とくにswapがSSDになったのが大きい。 これまで、RAM 4GBにも関わらずfirefoxとchromiumを同時に立ち上げている状態だったので、swapを2GB弱ほど使っているのが状態化していた。 それが、瞬時に実メモリに戻るのが嬉しい。 これまで、swapも4GBしかとってなくて、時々溢れてほぼfreezeといった状態になっていたこともあり、今度は16GBとってみたのはどう効くだろうか。
  • んで、問題の内蔵3TB HDの不調。 label領域というか、GPT領域が破損したのを書き込んで復旧した12/29以来、毎日のmksnap_ffsが「mksnap_ffs: Cannot create snapshot old-: Input/output error」と失敗しているのも気になるところ。 読み込みエラーを起こす領域には12/10から1/1まで当たらないという好運には恵まれているが。
  • ということで、当面の目標は現状ですべて0-fillと読み込みテストの実施。 ということで、何カ月もかけて空き領域を増やして来た。 だが、SATAの空き具合が… と思ったけど、root diskにいれたSSDが1TBもあり、700GB以上増えたので、一時保存領域に使えることに気がついた。 ということで、ちゃんと計算したいとわからないけど、2TB HDとSSDの方に移動を開始。 まずは放送終了番組400GB弱を2TB HDに移動。
  • なんか、170GBほど移動したところでread errorを起こして止まっていた。 logを取りながら1 title毎にやり直そう。
  • 壊れていたのは1番組だけだった。 あとは、チマチマ移動していくしかないのかなぁ。 微妙に空きがぎりぎりな感じ。 もとroot diskも使おうかしらん？

2019年1月2日

• 引続きroot disk交換作業:
  • ということで作業再開。 ある意味最初からやり直し。 bsdlabelの情報をまた計算しなおすの面倒なので記録しておこう:

    #          size     offset    fstype   [fsize bsize bps/cpg]
      a:    8388608         16    4.2BSD        0     0     0
      b:   33554432    8388624      swap                    
      c: 1953525105          0    unused        0     0     # "raw" part, don't edit
      d:    4194304   41943056    4.2BSD        0     0     0
      e:   16777216   46137360    4.2BSD        0     0     0
      f: 1890610529   62914576    4.2BSD        0     0     0
    

  • そしてnewfs、fsckと、「disklabel -B ada2s1」を忘れず実行。 のち、dump&restore。
  • 3時間強かかり無事複写終了。 んで、/etc/fstabのada0をada2に変更し、再起動。 BIOSで起動ディスクをada2であるSSDに変更し起動。
  • 無事立ち上がった。 あとはPATA diskを外して、SATA cardをさして、不調の3TBの中身を… うーん。 まだいろいろやることはあるが、とりあえず今日はここまでにするか。
  • これまでずっとPATA diskのガリガリいう音を聞いていて、何か実行している実感があるのが好きだったけど、SSDになって静か。 まぁ速くなったからアリということにするかな。

今月の日記

日本語ホーム頁に戻る

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