2021年10月28日木曜日

今更 No Man's Sky をやってみた。共同探検#3編。

チュートリアルもそこそこに、さっそく実践編とばかりに共同探検#3を開始してみました。

終わってみて振り返ってみると、これが私にとってこのゲームの実際のチュートリアルとして大変役に立ちましたので、ゲームを開始した時期で言えば、大変ついていたと思います。

その理由は、宇宙船が壊れていて、その宇宙船を修理することが大きな目標になっていたため、様々な素材を調達したり、エクソスーツ内で加工したりといった作業を最初のチュートリアルよりも学習できたことと、「フェーズ(普通は段階を追うとか、順を追う場合に使うと思うんだけど)」と書いてあっても無視して前後して作業してもよいという、このゲームの雑さ具合は言葉の定義そのものを変えてくるということが学習できたことです。

また、マルチプレイモード?だと足がかかりとしての自分の基地を作ろうとしても作れない、ということも学びました。

この点で面白いと思ったのはマルチプレイとシングルプレイをゲーム内の設定で切り替えることができることでした。状況に応じて切り替えをするという発想そのものが珍しいように思います。

ところで、今にして思うと、この共同探検での自分の宇宙機は外来種だったような気がします。

当時は宇宙機の違いなんかさっぱり分からないので、ちっとも気づきませんでしたが、かなり貴重な機体なんだそうです。もし知っていたら、イベント終了後もそのセーブデータを消さないで遊んでいたかもしれません。知らぬが仏とはこのことだと思いました。

その他、工場の使い方とかも学びましたが、エクソクラフトなる乗り物についてもここで学習しました。

しかし、ミノタウロス・エクソクラフトという機械を作るように指示されて作ったのですが、とにかくEキー長押しで設置できる、すべてのアップグレードをつけなくてはならないものと思い込んで、何かを間違って、「酸」が必要な拡張を設置してしまったため、ミノタウロスを一歩も動かせなくなってしまいました。

なにかBクラスのアップグレードだったと思います。

これを動かすには「酸」とやらを手に入れて、拡張の設置を完了させなくてはならないようですが、その「酸」はどうやって作るのか、あるいは買うのか、共同探検を完了した後まで、さっぱりわかりませんでした。

後日、スペースアノマリーでレシピを買って、自作するもんだということが分かりましたが、後の祭りです。その当時は本当にわかりませんでした。

まあ、なんか見た目も超ウゼェロボだし、どうでもいいやと思って放置していましたが、フェイズ4の「クロスカントリー」という課題で、「エクソクラフトで15,000u移動」という内容があるので困ってしまいました。

このまま「やり直しをするか、全部の課題をこなすのは諦めるべきか?」という考えが頭をよぎりました。

ただ、よく読むと、「エクソクラフトで」としか書かれておらず、「ミノタウロスで」とは書いてありません。

ま、どうせ雑な会社だから自分で作らせておいたミノタウロスじゃなくても、エクソクラフトなら何でもいいんだろ、と推察して、実際にホバークラフト型のナントカというエクソクラフトを作って乗って移動するとちゃんと移動距離が計上されたので一安心です。

いや。この場合は文言に忠実だ、というべきでしょうね。訂正します。

さて、そんなこんなで、数日かかったものの(通算24時間以上)、無事すべての課題をこなすことができました。
これで心置きなく元のセーブデータに戻ることができます。

大変学ぶことが多いイベントでした。

ところで、まだどの辺が神ゲーなのか、この段階でも、まだよく見えていません。

元のデータに戻って、さらにプレイを続けたいと思います。

今更 No Man's Sky をやってみた。チュートリアル編。

さて、起動してみてまず驚いたのは、音声までも日本語化されていることでした。

大変立派だと思います。

無論、プレイをしているうちに日本語化もかなり雑なことは表示域に収まらない文章や意味不明な「xx動作。停止。」とかいう掛け声ですぐわかりましたが、インストール時で雑なことはよくわかったのでちっとも気になりません。

日本語の入力もできませんがまるで平気です。

とにかく母国語でゲームができることは大変に有り難いです。これだけでも大したもんです。

私がゲームを開始したころ、ちょうど「共同探検#3」という期間限定イベントをやっているようでした。残り1週間とありました。

そこで、共同探検#3に参加してみようと思い、チュートリアルをどの程度進めればいいのか、先達に教わるべくGoogle検索さんに聞いてみました。

すると、このゲームは立派なWikiがあることが分かりました。
どうも家庭用ゲーム機が主体のゲームのようですが、やることは特に変わらないだろうと、さっそくWikiに記述されている先輩諸氏の意見を拝聴すると、大変親切なことに、「目覚め」というシナリオを一通りやっておくと良いようでした。

ただ、かなり充実したWikiの様子でしたので、これは一から十まで全部スポイルされているな、という気がしたので、それ以降はあまり目を通さないようにして早速開始しました。

故障しているものの、なかなかカッコいい宇宙船が私の船のようです。

とにかく環境が悪いのでとっとと修理してこの惑星から逃げ出さなければならないようです。
チュートリアルで指示された通りにあれやこれやで修理の方法や、修理のための素材集めの方法を一通り学びながら進めていくと、所有している宇宙機とは別に、ぼこぼこに壊れた墜落した宇宙機が手に入りました。

これは最初に所有していた宇宙機よりもランクは高いようですが、見てくれがかっこ悪い上に、どう直せばいいんだか手のつけようがないほどの壊れようなので、とりあえずその墜落現場に基地を据えて、放っておくことにしました。

とりあえず、この辺で共同探検#3を開始してみようかと思い、いったんこのセーブデータから離れました。

余談ですが後日、宇宙機を売り払うことができることが分かったので、売り払って懐を温めてくれました。

ところで、基地を設置したことが役に立ちました。
なんでか知りませんが、基地の撤去のために再度訪問したところ、売り払ったはずの同じ宇宙機が再び墜落していたのです。

おお、なんて雑なんだ・・・!

ほんとに雑な会社だ、徹底的に雑なんだ、と念を押してくるこのゲーム会社は本当にすごいと思いました。
早速、再度入手して売り払いました。
このことがあったので、調子に乗って墜落現場を発見したら基地を設置しておくようになりました。4か所くらいでしたでしょうか。

やっぱりそういた現場も二度も三度も同型機が墜落し続けています。

ほんとにインストール時に雑な会社が作ったゲームだとわかっていなかったら、あまりのばかばかしさに幻滅して辞めちゃってたと思います。
あの洗礼は本当に役に立ちました。

でもしばらくして、やっぱりなんだか不正を働いている気分が重くなっちゃって来たので、今ではもうそういった基地は設置していません。

まあ、ともあれ、せっかくの期間限定イベントらしい共同探検#3に参加するには、新規に開始する必要があるそうです。
現在のゲームデータはチュートリアルもやり終えてないし、どうせ右も左もわからないまま失敗続きになることは目に見えているので、共同探検#3のデータはやるだけやったら消すつもりで開始しました。

今のところ、神ゲーという要素は日本語化くらいしか見当たりませんでした。
きっと続けていくうちにわかるに違いないという期待にワクワクします。

長くなったので続きます。

今更 No Man's Sky をやってみた。起動編。

本当に今更ですが、ただいま積みゲー消化の真っ最中のゲームがこれです。

なんだか「神ゲーになった」とかあちこちで言われているのを見かけて、ちょっと気になってSteamを見るとちょうど半額セールだったのですが、それ以前に所有していたようです。
いつ入手したのも全く覚えていません。

まあ、せっかくなのでやってみようと思い、インストールして起動してみました。
すると、いきなりエラーダイアログが表示され、
"NVIDIA DLSS cannot be loaded due to outdated driver."
ですって。ただし、そのダイアログにはOKボタンしかついておらず、そのOKボタンを押下するとゲーム自体は開始することができました。

それにしても、DLSSをサポートするVGAなんてGeForce RTXシリーズだけなのに、こいつ何言ってんだ?と思って、Steamの動作要件欄を確認したところ、
グラフィック: nVidia GTX 480, AMD Radeon 7870
と明記されています。
無論、GTXにはDLSSなんて代物はありません。

初っ端からこの調子なので、ああ、こういう雑な仕事をする会社なのね・・・と、バグ山盛りな予感を最初から持てたのは良かったのかもしれません。
実際バグ山盛りでしたので、ある程度の覚悟を得たことについては、この警告は役に立ったといえましょう。

ちなみに、VGAドライバを最新のものに入れ替えると、エラーダイアログは出なくなりました。
もとに出ていたダイアログの文言から推察するに、「DLSSクラスをロード出来て、その結果DLSSが使えないことが分かるようになったからエラーとは処理しないよ」ってことなんだろうと思います。
エラーダイアログを見るのはプログラマじゃないんだから、最初から「(DLSSなんぞ関係なく)ドライバをバージョンxx以上にしろ」といえばいいだけなのに、エラーメッセージそのものがプログラマに寄り添い過ぎて、ユーザ向けとしては雑だったという落ちまでつけてくれました。
そんな雑な会社の作る作品が神ゲーだともっぱらの評判なので、とにかく期待を以てプレイを開始すべく、難易度ノーマルでさっそく開始してみました。

何をやっているのか知りませんが、起動までに分単位で時間がかかるのにはある程度仕方がない?としても、いざ処理が終了して起動されてみると、2016年リリースのゲームなのに、GTX660だとしょっちゅうFPSが1ケタ台をたたき出すという、まったく最適化していない描画コード。
それなのにGPUの温度は全然上がりません。ちゃんと仕事をさせているのかな。

同じ時期にリリースされた作品で言うと、Fallout4は2015年発売なのに余裕で30FPS出るんですよね。

これじゃあ、ほんとにGTX480で動くのかなんだか怪しいなあ、と思う一方、しかし、さすがに80番台なので、実はすごいのかな、とも思えたりします。
確か480と660って同等程度の性能のはずだから同じような具合に動くことは動くのかな。
まあ、下手に怪しむほうがけしからんかもしれませんね。ごめんなさい。

まあ、私はカックカクでも何でもプレイさえできれば、余程FPSが重要なゲーム以外は全くどうでもいいので、さっそくチュートリアルから開始してみたいと思います。

とおもったのですが、このゲームは破壊的にUIが雑というかデタラメですね。
決定キーだけでもFキーだったりEキー長押しだったり、左クリックだったり、数字キーだったりてんでバラバラ。
キャンセルも同様に右クリックだったりエスケープキーだったり、この統一感のなさは数人で勝手に別々に独自仕様で作ったゲーム部位を単純に張り付け合わせただけとしか思えません。もし一人でこんなUIを設計したのだとしたら、むしろ大天才なのかもしれません。天才の言うことはほかの人にはわからないそうですから。
さらに言うなら、メニュー構造が異常に深い、Xキーで呼び出す機能の位置が状況によってころころ変わるなど、もう本気で意味不明です。
これにはさすがに驚きを禁じえませんでした。
スゴイ。

たったこれだけしかしていないのに結構長くなってしまったので次回に続きます。
プレイを開始するまでで面白いイベントに出会えて、このゲームにも興味津々です。

しかし、いつ買ったんだろう・・・?

積みゲー消化メモ

チラシの裏です。読む価値はありません。

積みゲーが3ケタを超えて久しく、まだ増える一方の現状に鑑み、いくらか消化しようと試みてみました。
しかし、試みてはみたというものの、数か月かかっても大して手を付けられず、しかも途中で放り出すものばかりという体たらくでげっそりです。

その中から、ある程度やったゲームの所感を記録として残しておこうと思います。

まずTropico5はそれなりに楽しめました。まだDLC版のシナリオに加えて、さらにTropico6が残っていますが当分はおなかがいっぱいで当面は見向きもしないと思います。
思えばTropico4のころはSteamもドル建てだったことを思い出しました。もっと前は日本語版だからか大変お高かったけど、初代Tropicoの日本語版の声優さんの演技がとても素晴らしかったことが思い出されます。そして、その初代のゲーム性のままパーツだけ豪華になっているという稀有な作品(「あの」Kalypso mediaに権利が移り、加えて「あの」スクウェア・エニックスと手を組んで聳え立つ**のような組み合わせが実現してしまったものの、時を経てスクウェア・エニックスがどっか行ってくれて本当にヨカッタ)なのも、長くお付き合いできている理由かもしれません。

The Long Darkは最初は面白かったものの、生活が安定すると、あとはすでに用意されているマップの観光をするくらいしかやることがなくなって終了。自分で縛りを入れたりといった遊び方がいいんでしょうが、3ケタもあるゲームが待っているのにそこまでする価値は見出せませんでした。
ただ、たとえシステム的に絶対に逃れられなくても、どんどん南下していつかはアメリカにたどり着くべく努力をしている「つもり」にさせてくれたり、何かこう、ただその場を死なずに生き残るというだけでなく、観光以外の何か希望が持てる感覚を味わえていたら、ちょっとづつ続けられるゲームになったと思います。
当然、シナリオ?ストーリー?は手つかずのままです。

Fallout4はそれなりに楽しめました。レベル40半ばくらいまでは惰性プレイとなりつつもプレイできました。まだメインシナリオも終えていませんが、いつの日かまた起動するかは未知数です。
また、いくら古いゲームとはいえ、GeForceGTX660で快適なプレイが可能だったのには感心しました。
思えばFallout3のころもSteamもドル建て(年寄はクドい)

Oxygen Not Includeedは最初はものすごく楽しめました。
ただ、だんだん仕組みが分かってくると、やることが単調すぎて、せっかくの複製人間のかわいらしいしぐさをもってしても飽きてしまいました。ロケットはひとつも作りませんでした。とは言え、600時間を超えていたのでもう十分やり切った気もします。
これも自分で縛りを入れればまた楽しみ方も変わってくることと思いますが、やはり3ケタもある積みゲーの前には力及ばず、DLCも買っていません。

Civ6は・・・良くも悪くも、ただの「Civilizationの最新版」でした。
このシリーズはCiv3かCiv4で完成しきっちゃった感をひしひしと感じ、あの頃のワクワク感がまるで感じられなかったので、国王で開始して初回プレイで勝ってしまったので、すぐ削除してしまいました(ついでにHDDの肥やしとなっていたCiv5も削除できてすっきりです)。Tropicoも初代から変わり映えしていないのに割合プレイできたのに対して、なんでCivシリーズはつまらないのか、我ながら謎です。

また、積みゲーではないのですが、無料ゲームのIndustry Idleというゲームにも手を出してみました。放置ゲームの一種らしいのですが、抽象化の度合いが面白く、これはかなりいけます。
1回のプレイが短時間で済むので、今でも数日に数分起動して売り上げの回収だけはしています。

そのほかにもいくつかやっていると思うのですが、パッと思い出せないので、とりあえずこんな程度でメモとします。

こんなチラシの裏を公開して申し訳ございません。

2021年3月13日土曜日

S.M.A.R.T.値などで異常を示したST3000DM008で遊んでみよう

新規購入したHDDの初期不良のチェックやRAIDアレイの再構成が一段落ついたので、 先日故障が発覚したHDD(Seagate Barracuda 3.5, ST3000DM008-2DM166)で遊んでみたいと思います。

とにかくドライブのサイズがそれなりに大きいので、一つのコマンドの結果が返ってくるまでに5時間など当たり前なので、一日一コマンドづつしか入力できないのがもどかしいのですが、まあ折角ですので、これまで何度もやっているとはいえ、訓練を重ねることは悪いことではありません。
今回はまず、不良セクタを何とかしたいと思います。


今回の状況としては、/dev/sddとして接続し、ext4の単体ドライブとしてmkfs.ext4をしなおしたうえでrsyncコマンドで元のRAIDの内容をコピーしてある状況を作りました。

まずは異常セクタの特定から行いたいのですが、前回書いた通り、smartctl -t longテストでは異常なしとか平気で言い放つ始末で手に負えません。

実際には以下のパラメータが48まで上昇しているにもかかわらず、です。

・197 Current_Pending_Sector
・198 Offline_Uncorrectable

もはやHDDの自己テスト機能がダメになっているのかもしれません。

そこで、badblocksコマンドを用いて異常セクタを検出したいと思います。

まあ、念のため、再度ブロックサイズを確認します。

1
2
# tune2fs -l /dev/sdd1|grep -i "block size"
Block size:               4096

このパラメータをbadblocksに与えて検査させます。
1
2
3
4
# nohup badblocks -b 4096 -vs -o badblocks.txt /dev/sdd1&
tail -f nohup.out
Checking blocks 0 to 732566271
100.00% done, 5:23:20 elapsed. (139/0/0 errors)
ということで、五時間半かかって、139セクタもの不良セクタが検出されてしまいました。

この段階でのsmart値は以下の通りです。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   097   093   006    Pre-fail  Always       -       40328485
  3 Spin_Up_Time            0x0003   096   096   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       6
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       8
  7 Seek_Error_Rate         0x000f   076   060   030    Pre-fail  Always       -       49566908
  9 Power_On_Hours          0x0032   063   063   000    Old_age   Always       -       32571
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       6
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       262
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0 0 0
189 High_Fly_Writes         0x003a   099   099   000    Old_age   Always       -       1
190 Airflow_Temperature_Cel 0x0022   076   060   045    Old_age   Always       -       24 (Min/Max 20/26)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       4
193 Load_Cycle_Count        0x0032   073   073   000    Old_age   Always       -       55928
194 Temperature_Celsius     0x0022   024   040   000    Old_age   Always       -       24 (0 13 0 0 0)
197 Current_Pending_Sector  0x0012   094   094   000    Old_age   Always       -       1112
198 Offline_Uncorrectable   0x0010   094   094   000    Old_age   Offline      -       1112
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       32556h+15m+05.395s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       25786278431
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       1151768457351

いやあ、すげえ。Current_Pending_Sector  とOffline_Uncorrectable   が1112にまで上昇してしまいました。
これから試す方法の挙動が楽しみです。

さて、まずは実際にbadblocksコマンドで得たセクタ番号がHDD自身から聞けるかどうか、smartctl -t shortで尋ねてみました。

1
2
# 1  Short offline       Completed: read failure       90%     32571         -
# 2  Extended offline    Completed without error       00%     32452         -


全然教えてくれる気はないようです。

しかし、前回、異常が発生しているにもかかわらずエラーなし(#2です)で正常終了していたのが、read failureで異常終了(#1です)しているのはせめてもの事でした。

異常なしっていう時点でおかしいですもの。


まあ、HDDが異常セクタを教えてくれないとのことですので、それならばbadblocksで検出した139の異常セクタをどうにかすればsmart値はどうなるのかを見ていきたいと思います。


その前に、異常セクタにあるファイルを削除するため、先ほどのbadblocksコマンドで生成された badblocks.txt に記録されているセクタ番号をもとに、debugfsコマンドでセクタ番号から使用されているinode番号を取得して、そのinode番号をもとにファイル名を特定します。


無論、すぐに廃棄する予定のHDDでここまでする必要はないのですが、せっかくの演習ですから壊れても惜しくない大容量HDD(いや、もう壊れているのですが)、有効活用してみたいと思います。


まずは指定したセクタに何らかのデータが記録されているかを調べるには以下です。

セクタ番号が524726232として、icheck <セクタ番号>で調査します。

1
2
3
4
# debugfs -R "icheck 524726232" /dev/sdd1
debugfs 1.42.9 (28-Dec-2013)
Block   Inode number
524726232       117966080

ばっちり使われています。

使われていない場合は次のような表示になります。
1
2
3
4
# debugfs -R "icheck 620236906" /dev/sdd1
debugfs 1.42.9 (28-Dec-2013)
Block Inode number
620236906 <block not found>

これを139セクタ分繰り返します。

ファイル名を得るには
1
#  debugfs -R "ncheck 117966080" /dev/sdd1
というように、"ncheck inode番号" を実行しますと、ファイル名が表示されます。
inode番号は重複する場合がありますので、sortしてuniqしたほうがいいと思います。
数が数ですので、awkなりperlなりpythonなり、スクリプトを書いたほうが安全かと思います。

さて、今回のケースではファイル数に換算すると46ファイルでした。
でかいファイルが配置されていたセクタが多かったようです。

早速それらをunlinkして、smart値を見てみますと、特に意味がある変化は見られません。
当たり前といえば当たり前ですが。

お次はddコマンドで0を書き込んでセクタを代替させる作業を行います。
139セクタすべてを0で埋めますが、その前に1セクタだけやって、smart値がどう変化するかを見てみたいと思います。

1
2
3
4
5
6
7
8
9
10
11
12
13
# dd if=/dev/zero of=/dev/sdd1 bs=4096 count=1 seek=524726232
1+0 レコード入力
1+0 レコード出力
4096 バイト (4.1 kB) コピーされました、 0.00141101 秒、 2.9 MB/秒
# sync
# smartctl -a /dev/sdd1
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
 (略)
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       8
 (略)
197 Current_Pending_Sector  0x0012   094   094   000    Old_age   Always       -       1104
198 Offline_Uncorrectable   0x0010   094   094   000    Old_age   Offline      -       1104
 (略)

おやおや、Reallocated_Sector_Ct   の値は変化がありませんが、Current_Pending_Sector  とOffline_Uncorrectable   の値が2ポイント増えてしまいました。なかなか興味深い事象なので後で遊ぶとして、あと138セクタあるので、残りは一括してスクリプトを組んでゼロで埋めてしまいます。

その結果、
1
2
3
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       8
197 Current_Pending_Sector  0x0012   100   094   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   094   000    Old_age   Offline      -       0
Current_Pending_Sector  とOffline_Uncorrectable   の値がゼロになり、代替されたセクタが増えていません。
これ、書き込みが成功した場合は代替しないっていうHDDがあることは知っていましたが、このHDDもその一味なのでしょうか。

念のため、これらのセクタを下手に使ってしまわないようにファイルシステムに"コイツはダメだ"と記録しておきます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# fsck.ext4 -l badblocks.txt /dev/sdd1
e2fsck 1.42.9 (28-Dec-2013)
/dev/sdd1: Updating bad block inode.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong for group #18928 (23698, counted=23699).
Fix<y>? yes
Free blocks count wrong for group #19312 (24543, counted=24544).
Fix<y>? yes
Free blocks count wrong for group #20416 (24543, counted=24544).
Fix<y>? yes
Free blocks count wrong for group #22000 (24543, counted=24544).
Fix<y>? yes
Free blocks count wrong for group #22032 (24542, counted=24544).
Fix<y>? yes
Free blocks count wrong (63487139, counted=63487145).
Fix<y>? yes
/dev/sdd1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sdd1: 97313/183148544 files (1.5% non-contiguous), 669079127/732566272 blocks

ま、結果は信用できませんが、仕上げに自己テストを行わせます。
1
# smartctl -t long /dev/sdd
結果は後日のお楽しみです。(どうせwithout errorでしょうねぇ)

それにしても、3TBという容量が容量なので、こんな危なっかしいHDDをだましだまし使うということは難しい感じです。
廃棄以外にちょっと考えられません。

6TBとか8TBとかがボリュームゾーンになってきている様子ですが、今後ますますトラブル発生即交換・廃棄という運用じゃないととてもやっていけませんねえ。
貧乏性にはつらい選択です。

結果として、頓死しないでずるずる生き延びる、なんだかおもしろい機材が手に入ってしまったので、今後も時間があれば何らかのネタを仕込んでみたい気もしますが、まずは来月あたりにもう一度badblocksコマンドで総なめしてみて、何か面白いことが起きるかどうかですかねえ。

まずは今回はこんなところでしょうか。

ここまでお読みいただき、ありがとうございました。

2021年3月11日木曜日

3年6か月目にST3000DM008に異常発生、WD40EZRZ-RT2購入

一昨日、自宅サーバにて二台のST3000DM008でRAID1を構成していた一台に異常が発生していることが発覚しました。
ペアを組んでいるもう一台のST3000DM008は何の問題もなく元気に稼働しています。

異常は毎週のraid-checkで検出されていました。
よくよく調べてみると、先月のsyslogにすでに異常が報告されていることが分かりました。
smartctlからもmdadmからもメールが来なかったのですっかり油断していました。

2017年6月に運用を開始して以来、メーカーが保証していない24時間365日な自宅サーバ上での使用でこれだけの期間、頑張ってくれたことに感謝です。

実際のところ、ST3000DM001の型番だけ変更品なんじゃないかという疑念が付きまとっていた本製品だけに、一層感謝の念が深まります。


障害の内容は、syslogによるとアクセス不能なセクタが発見されていました。
1
2
3
4
5
6
7
8
9
10
11
12
13
Mar  7 05:57:53 ***** kernel: ata3.00: exception Emask 0x0 SAct 0x100000 SErr 0x0 action 0x0
Mar  7 05:57:53 ***** kernel: ata3.00: irq_stat 0x40000008
Mar  7 05:57:53 ***** kernel: ata3.00: failed command: READ FPDMA QUEUED
Mar  7 05:57:53 ***** kernel: ata3.00: cmd 60/00:a0:00:17:46/01:00:45:01:00/40 tag 20 ncq 131072 in#012         res 41/40:00:38:17:46/00:01:45:01:00/00 Emask 0x409 (media error) &lt;f&gt;
Mar  7 05:57:53 ***** kernel: ata3.00: status: { DRDY ERR }
Mar  7 05:57:53 ***** kernel: ata3.00: error: { UNC }
Mar  7 05:57:53 ***** kernel: ata3.00: configured for UDMA/133
Mar  7 05:57:53 ***** kernel: sd 2:0:0:0: [sdc] tag#20 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=3s
Mar  7 05:57:53 ***** kernel: sd 2:0:0:0: [sdc] tag#20 Sense Key : Medium Error [current] [descriptor]
Mar  7 05:57:53 ***** kernel: sd 2:0:0:0: [sdc] tag#20 Add. Sense: Unrecovered read error - auto reallocate failed
Mar  7 05:57:53 ***** kernel: sd 2:0:0:0: [sdc] tag#20 CDB: Read(16) 88 00 00 00 00 01 45 46 17 00 00 00 01 00 00 00
Mar  7 05:57:53 ***** kernel: blk_update_request: I/O error, dev sdc, sector 5457188664
Mar  7 05:57:53 ***** kernel: ata3: EH complete
驚いてsmartctlで確認したところ、SMART Error Log Version: 1には既に109件もエラーが記録されており、かつ、Reallocated_Sector_Ctの値が8になっていました。

SMART Error Logはこんな感じでした。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
SMART Error Log Version: 1
ATA Error Count: 109 (device log contains only the most recent five errors)
        CR = Command Register [HEX]
        FR = Features Register [HEX]
        SC = Sector Count Register [HEX]
        SN = Sector Number Register [HEX]
        CL = Cylinder Low Register [HEX]
        CH = Cylinder High Register [HEX]
        DH = Device/Head Register [HEX]
        DC = Device Command Register [HEX]
        ER = Error register [HEX]
        ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.
 
Error 109 occurred at disk power-on lifetime: 32432 hours (1351 days + 8 hours)
  When the command that caused the error occurred, the device was active or idle.
 
  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455
 
  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 00 ff ff ff 4f 00  19d+18:25:46.787  READ FPDMA QUEUED
  60 00 00 ff ff ff 4f 00  19d+18:25:46.754  READ FPDMA QUEUED
  60 00 00 ff ff ff 4f 00  19d+18:25:46.143  READ FPDMA QUEUED
  60 00 00 ff ff ff 4f 00  19d+18:25:46.015  READ FPDMA QUEUED
  60 00 00 ff ff ff 4f 00  19d+18:25:46.014  READ FPDMA QUEUED

しかしながら、
1
SMART overall-health self-assessment test result: PASSED
なのでsmartctlはメールを飛ばさなかったようです。
ついでにセルフテストを行ってみましたが、こちらも
1
1  Extended offline    Completed without error       00%     32452         -
といわれてしまい、成功終了してしまいました。

兎にも角にも、RAIDが縮退運転に入る前に気づけたことは幸いでした。
早速、気づいたその日にすぐに代替用HDDの選定に入りましたが、最近の手ごろな価格のHDDってほとんどが瓦磁気記録方式(以下SMR)なのでびっくりしました。
確かに、SMRの普及が進んでいるとは噂程度には聞き及んでいたのですが、ちょっと考えてしまいました。

SMRと一言で言っても、大抵はHDDの外周部分をCMRとして使って、あとでゆっくりSMR方式の内周部分に移動する方式が主流のようです。
そのため、毎週テラバイト単位(ベアドライブ単位で丸ごとだから)でのバックアップの処理のパフォーマンスが極端に低下する(CMRとして記録できる領域を超えてしまうため)懸念を抱きました。
また、CMRとして利用するシリンダを酷使することによる耐久性はどうなのかというのも、もう少々、できれば数年、様子を見たいところです。
また、gitでのソース管理などでも、細かいファイルが大量に発生してしまうのですが、これの処理のパフォーマンスも気になります。

まあ、所詮は自宅サーバですし、あまり気にしても仕方がないのですが、面倒になったのでとにかくCMRの製品にしようと思って探してみました。

もともと3TBのHDDだったので3TB近辺で探すと、現在は4TBがお安いようですね。
そのため、1TBはRAIDとしては使えませんが4TBのHDDを探してみると、あっさりWD40EZRZ-RT2という製品が見つかりました。これはCMRなんだそうです。
お値段は8千円。SMR方式の同容量のHDDと比べても最大でも千円前後しか価格差はないようです。

今回異常を示したHDDの先々代がWDでしたが、二年も持たず故障したので、若干気がかりですが、これは我ながら難癖でしょう。
結局のところこういうのはどのメーカでも同じことですし、そもそもメーカが保証しない連続運用が前提な使い方をする以上、すべては自己責任です。
さっそく注文して取り寄せました。

とりあえず例によってmdadmでraid1アレイから故障したHDDをfailさせてremoveします。
(たとえばこんな感じです。sdcが今回壊れたHDDです)。
1
2
mdadm --manage /dev/md0 --fail /dev/sdc1
mdadm --manage /dev/md0 --remove /dev/sdc1
その後、障害が発生したHDDをサーバから物理的に抜去するか、そのまま接続するなら別RAIDに仮参加させるなど元のRAIDアレイに戻らないように工夫した後、 新規購入したHDDのパーティションを元のRAIDアレイのサイズと同じサイズで切って追加します。


パーティションを切る際、partedで開始位置と終了位置をセクタ単位で指定したい場合はセクタ番号の後ろにsをつければ問題ありません。partedでprintコマンドでセクタ単位で表示させたい場合は、
(parted) unit s
とすると表示できます。
もっとも、fdisk -l で事前に見ておいたほうが楽だと思います。


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# parted /dev/sdc
(parted) mklabel gpt
(parted) mkpart
パーティションの名前?  []? SDC1-WD4T
ファイルシステムの種類?  [ext2]? xfs
開始? 2048s
終了? 5860532223s
(parted) set 1 raid on
(parted) p
モデル: ATA WDC WD40EZRZ-22G (scsi)
ディスク /dev/sdc: 4001GB
セクタサイズ (論理/物理): 512B/4096B
パーティションテーブル: gpt
ディスクフラグ:
 
番号  開始    終了    サイズ  ファイルシステム  名前       フラグ
 1    1049kB  3001GB  3001GB                    SDC1-WD4T  raid

その後、partedで余った1TBのパーティションも追加します。
これは正確な数値である必要はないので、開始位置をサイズ、終了位置を100%といったようなアバウトな指定で十分です。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
(parted) mkpart
パーティションの名前?  []? SDC2-WD4T
ファイルシステムの種類?  [ext2]? xfs
開始? 3001GB
終了? 100%
(parted) p
モデル: ATA WDC WD40EZRZ-22G (scsi)
ディスク /dev/sdc: 4001GB
セクタサイズ (論理/物理): 512B/4096B
パーティションテーブル: gpt
ディスクフラグ:
 
番号  開始    終了    サイズ  ファイルシステム  名前       フラグ
 1    1049kB  3001GB  3001GB                    SDC1-WD4T  raid
 2    3001GB  4001GB  1000GB                    SDC2-WD4T

余談ですが、もちろん、こんなアバウトな指定のしかたでも、きっちりパーティション2はパーティション1の次のセクタから確保されています(unit sしてprintすればわかります)。
こういった地味だけどとても便利で親切なコマンドを作る気配りというのは、下手をすると余計なお世話になってしまうために目には見えないけれど実際には相当負担が大きいのですが、それをあえてするプログラマの心意気に頭が下がります。

そして、上記で生成したパーティションをアレイに追加すればリカバリが始まります。
1
# mdadm --add /dev/md0 /dev/sdc1

今回のリカバリは夜の20時30分に開始して翌未明02時16分に完了しました。
六時間弱、かあ。するとリカバリ速度は約141,963KB/秒ですね。

ただ・・・容量違いのHDDでRAID1を組むと、新しくて、しかも大きい容量のHDDのほうが先に壊れた経験があるので、今回は先例通りにならないことを願うばかりです。

余談ですが、容量が大きいHDDが先に死んでしまったときに生き残ったHDD(ST31000528AS)は2009/04/24から現在まで元気に活躍していました。
彼の初代の相棒はWD10EADS-00L5B1(2009/04/24運用開始、2011/03/吉日死亡)、次の相棒がST2000DL003(2011/3/22運用開始、2017/06/21死亡)でした。
その後、二代目の相棒の死亡を機にRAIDアレイを引退。
余生をPCクライアントのバックアップ置き場として活躍するものの、2021年3月10日、容量の小ささと古さから廃棄処分となりました。
こちらも、本当によく働いてくれました。
ご苦労様でした。ありがとうございました。

あとは自己診断の結果待ちですが、45,180秒かかるそうなので、初期不良の判定はもうちょっと先になりそうです。
さらに故障が判明してから停止していたrsyncによるraidアレイのバックアップ先との同期やらがあるので当分先の話になりますが、hdparmやddコマンドを用いての単体のHDDの転送速度の実測とか負荷がかかる試験をいろいろ試したいのですが、徐々に進めたいと思います。

ネタのつもりで買ったST3000DM008がここまでしてくれたので、ちょっとうれしくて思わずこのような駄文をひねくってしまいました。
お読みいただきありがとうございました。

---
2021/03/11 追記
異常が発生したST3000DM008をmkfsしなおして、rsyncコマンドでraid1の中身を全コピーしてみたところ、何の異常もなく終了してしまいました。結果は以下の通りです。
1
2
sent 2.80T bytes  received 1.69M bytes  139.56M bytes/sec
total size is 2.81T  speedup is 1.00

RAID1のリカバリ時間とほぼ同等ですかね。おおよそ五時間半かかりました。
それにしても、何の異常もなく正常終了してしまうのには困りました・・・
dmesgにもmessagesにもsmartdctl -aの結果にも、まるで何も記録されていません。
RAIDのアレイ構成員としては恐ろしいのでスペアに指定することなんか想像もできませんが、それはさておいて、3TBもの領域でどう遊んでいいやら。
貧乏性の悩みは尽きませんが、かといって、なんらかのネタを思いつければいいのですが・・・

2021年2月25日木曜日

気象庁のホームページが更新

チラシの裏です。


個人用ホームページの天気予報欄の表示がおかしかったので調べたら、リニューアルなさったんですね。ちっとも知りませんでした。


Android用のウィジェットなど、いくつか依存するアプリを作っていたのですが、まあ、もう当時のような気力は戻ってこないでしょうねぇ。

もう10年近く前に作ったアプリが現役で動いていただけでも御の字ってところでしょうか。


本来なら気象業務支援センターからデータを買わないといけないんでしょうけど・・・やっぱり個人では難しいです。

結局、「気象庁ホームページのコンテンツの利用について」で許されている範囲内で気象庁の負荷にならないように極力注意をしたうえで、ページからスクレイピングを行って実装していました。


ただ一つだけ、冒頭に触れたページですが、具体的には単に注警報や天気図、天気予報とかアメダス値がパッと見られるページなのですが、これがまた個人的には実に便利でしたので、再度実装するとしたらどうしたらいいのかな、とちょっとhtmlページのソースを拝見しました。

設計思想からしてすごい変わりようですね。

従来はサーバ側で全部作っておいて、静的なページとして配信していましたが、今回はhtmlで記述する部分はひな形だけで、データ自身は別個にそれぞれのホームページの閲覧者のブラウザから直接サーバに非同期に通信して取得して、そのデータを(ある程度の加工を行っているケースもありましたが)ひな形に当てはめていく形式になっていました。


その非同期で取得するデータの形式はjsonでした。

jmaさんといえば一時期全然必要性を感じない電文やマイコンで直接処理するような電文にもXML化を推進する勢いでしたのに、どうしちゃったんでしょうか。

しかしjsonを採用してくれたおかげで、電文形式が極めて簡素で、かつ大変利用しやすい形式にまとめられているので、簡単に個人用ページを作り替えることができそうです。無論、ブラウザ上から直接ajaxでjsonを取得しちゃうと毎回ページを閲覧するたびに気象庁にクエリが飛ぶので、それは最低でも天気予報が更新される一日三回までに抑える必要があるので、ひと手間は必要ですが。


それにしても、ちょっと引っかかるのは、jmaさんがホームページに広告を掲載する決断を下したことです。

jsonのデータって果たしてjmaさん的に「気象庁ホームページで公開している情報」に該当するのでしょうか。

XMLデータは気象業務支援センターの営業を邪魔しない程度に遅らせてjmaさんのホームページから入手できますが、これは堂々とその配布のための専用ページも設けられているため、「気象庁ホームページで公開している情報」に該当するでしょう。

一方、jsonデータに関する記述は現時点ではどこにも見当たらず、かつ、それだけではホームページを構成していません(ひな形に当てはめて初めてホームページとして完成します)ので、jmaさんが何らかのアナウンスメントを出すまでは、愛知県岡崎市の例もありますし、当面は出来上がったページへリンクを張る程度にとどめ、様子を見たほうが良いかもしれません。

多少遲くていいなら(そして煩雑なXMLでもいいなら)府県予報でもいいわけですから、おいおい考えていきたいと思います。


それにしても、前代のホームページは19年間も現役だったそうです。

本当にお世話になりました。ありがとうございます。