PC ＞ｱﾌﾟﾘ ＞保守用ﾂｰﾙ ＞HDD Regenerator ＞現場例 ＞JM 運送 様 : IK町＞
( 2020.10.30.更新 )
| ● 機種 ● | |
|---|---|
| 1 | 東芝 : DT01ACA300 : JUL-2018 |
| ↑ 3.0 TB | |
| ↑ Regene には 746 GBで認識されるが､｢ 4Kｾｸﾀ = 4,096 MB × 746 GB = 3,055,565 MB = 3 TB ｣ ということ … ? | |
| ● 症状 ● | |
| 1 | ↓ 3 TB の大容量をのぞいても､歴代最悪の感じ ( = 希望がある故障の中の 最悪 ) |
| [1]. Rﾋｯﾄ どころか Dﾋｯﾄ もしないのに､処理が激遅のｾｸﾀが 大量 | |
| ↑ 通常ｽｷｬﾝでも､強制ｽｷｬﾝでも | |
| ↑ ( 大量に対して ｽﾄﾚｽはたまるが )､ この症状自体は 他のHDDでも 見たことはある | |
| [2]. 通常ｽｷｬﾝだと ｢ not ready 停止 ｣ するのに､強制ｽｷｬﾝだと Rﾋｯﾄも Dﾋｯﾄもしないｾｸﾀが 大量 | |
| ↑ この症状は ほとんど見たことがない | |
| ↑ 強制ｽｷｬﾝのままだと 完了が 何か月後になるかわからないし､通常ｽｷｬﾝでは しょっちゅう止まる | |
| ↑ ｢ 手動で ｣ 処理を変えながら 進行する必要があるので､非常に 面倒くさい | |
| ↑ 100 G ( = 実際の容量は 400 G ) あたりまで この症状が大量で､ｽﾄﾚｽがたまった | |
| [3]. ( 普通の ) Dﾋｯﾄ､ Rﾋｯﾄ､ Bﾋｯﾄ残りも 大量 | |
| ● 処置 ● | |
| ↓ 50 日以上 かかった | |
| 1 | 20 日以上かけて Regene を 通し､さらに 20 日以上かけて､( 新品 HDD = WD 赤 に ) ddｸﾛｰﾝした |
| 2 | ↓ Windows の認識で 以下 |
| 原本 = ｢ ﾌｧｲﾙ : 24,674 ｣ + ｢ ﾌｫﾙﾀﾞ : 474 ｣ + ｢ 容量 : 423 GB ｣ | |
| ｸﾛｰﾝ先 = ｢ ﾌｧｲﾙ : 24,028 ｣ + ｢ ﾌｫﾙﾀﾞ : 464 ｣ + ｢ 容量 : 397 GB ｣ | |
| ↑ ｸﾛｰﾝ先が､｢ ﾌｧｲﾙ : - 646 ｣ + ｢ ﾌｫﾙﾀﾞ : - 10 ｣ + ｢ 容量 : - 26 GB ｣ … !! | |
| ↑ なんと ( Regene 後 の ) 原本 ( = 障害 HDD ) のほうが､認識できるﾃﾞｰﾀが 多いという 結果に | |
| ↑ 不調ｾｸﾀに当たったさい､ddｸﾛｰﾝよりも ｺﾋﾟｰのほうが ｢ ﾀｲﾑ･ｵｰﾊﾞｰ するまでの時間が 長い ｣ とか､｢ ﾘﾄﾗｲ数が 多い ｣ ということ … ? | |
| ↑ もちろん ｢ 認識はしても 抜けいないﾃﾞｰﾀ ｣､ あるいは ｢ 抜けても 再生不能のﾃﾞｰﾀ ｣ も 多数あるとは思うが | |
| 3 | 原本 ( = 障害 HDD ) を 内蔵で Ubuntu 18.04 起動のほうが ﾌｧｲﾙ : 25,159で､( Windows 認識よりも ) + 485 多いので Ubuntuで ﾃﾞｰﾀ･ｺﾋﾟｰした |
| ↑ 単に 隠しﾌｧｲﾙ 系 ( = 不要なﾌｧｲﾙ ) かもしれないが | |
| ↑ ただし､1 ﾌｧｲﾙのｺﾋﾟｰに ものすごい時間がかかっても､ほとんど ﾀｲﾑ･ｵｰﾊﾞｰ ( = ｺﾋﾟｰ･ｴﾗｰ ) にならないので､Ubuntu によるｺﾋﾟｰで 正解 | |
| 4 | ↓ 10 日かけて､ﾊﾞｯｸｱｯﾌﾟ先ｽﾄﾚｰｼﾞに ｺﾋﾟｰ完了した |
| ｺﾋﾟｰ･ｴﾗｰ は 7 ﾌｧｲﾙのみ | |
| ﾊﾞｯｸｱｯﾌﾟ先 = ｢ ﾌｧｲﾙ : 24,674 ｣ + ｢ ﾌｫﾙﾀﾞ : 474 ｣ + ｢ 容量 : 423 GB ｣ | |
| ↑ Windows の 認識では､原本 ( = 障害 HDD ) と同じ ( = ﾌｧｲﾙ数 : + 485 は､やはり 隠しﾌｧｲﾙだったのか ) | |
| ● 過程 ● | |
|---|---|
| 1 | ( なんか 今までにない､独特の 面倒くさい感じ ) |
| 2 | 容量が､746Gbで認識されるのは､RegeneのOSが古いから､仕方ないか |
| ↑古い筐体:EPSON:AT970(AMI)でも､新しめ筐体:富士通:D588/CX(AMI)でも | |
| ↑Regeneの販売ｻｲﾄを見たら､Ver.2011で止まっている | |
| ↑4Kｾｸﾀだから､512M × 8 = 1ｾｸﾀ:4,096MBで､4,096MB × 746GB = 3,055,656 = 3TB､ということかも | |
| 2 | ↓症状が､独特 |
| [1]. 明らかに処理が遅いｾｸﾀが､大量にあるのに､Dﾋｯﾄは､ものすごく少ない | |
| ↑これは､ときどき見る症状だが | |
| [2]. (それに歩調を合わせるのか)､処理が(異常に)遅いｾｸﾀが大量にあるのに､ほとんど､R処理されない | |
| ↑あまり見ない症状だ | |
| [3]. (たまに)Rﾋｯﾄ → R処理されて､B残りが倍ぐらい | |
| ↑まあこれは､症状が重いだけで､普通か | |
| [4]. 通常ｽｷｬﾝだと､not ready停止するｾｸﾀが､異常に多い | |
| ↑そのｾｸﾀを強制Regeneすると､ほとんどが､ｽﾙｯと(Rﾋｯﾄなしで)通過する | |
| ↑これが非常に､独特だ | |
| ↑今までは､not ready停止したら､そこを強制RegeneしてR処理され､その後､通常ｽｷｬﾝが通るようになった | |
| ↑強制がｽﾙｯと通ったので､(あるいは､処理が遅くても､Rﾋｯﾄなしで通ったので)､同じｾｸﾀを再度､通常ｽｷｬﾝすると､ほぼすべて､not ready停止する | |
| ↑｢ Rﾋｯﾄも､Bﾋｯﾄもしない､not ready停止ｾｸﾀ ｣が､大量にあるのは､独特だ | |
| 3 | ↓つきっきりでいられるなら､以下の処理もできる |
| [1]. 通常ｽｷｬﾝで､not ready停止したら､(再起動して)､そのｾｸﾀに強制をかける | |
| [2]. 強制が通ったら､再度､通常ｽｷｬﾝしてみる | |
| [3]. 通常が通ればよし､再度､not ready停止したら､そのｾｸﾀを飛ばして､通常ｽｷｬﾝを続ける | |
| ↑しかし､この症状のｾｸﾀが､大量にあるため､とてもそんな手間はかけられない | |
| ↑仕方ないので､(とりあえずは)､強制をかけ続けるしかない | |
| 4 | (普通は)､強制Regeneだって､症状が軽いｴﾘｱなら､進行は速い |
| ↑ざっくりと､1秒で数百ｾｸﾀ(= 完全に正常なｴﾘｱなら) | |
| ↑しかし､このHDDは､(今､90Gbを越えた地点だが)､進行の速いｴﾘｱが､ほとんどない | |
| ↑(目視できた範囲で)､いちばんﾏｼなのは､1秒で1ｾｸﾀ程度の速度(= ﾏｼなｾｸﾀは､非常に少ないが) | |
| ↑大量にあるのは､1ｾｸﾀ20秒前後であり､(しかも､ほとんど)､Dﾋｯﾄ + Rﾋｯﾄしないので､非常に独特だ | |
| ↑今後､このﾍﾟｰｽが続くなら､どれだけ時間がかかるんだ…? | |
| 5 | 手順をいろいろと混ぜて､やっと(= 20日間)､100Gまで終了した |
| ↑Rも多かったが､それ以上に､多くのBも残った | |
| ↑それ以上に､D + Dﾋｯﾄしないﾃﾞｨﾚｲが､大量(= 数万以上) | |
| 6 | 100G以降は､通常ﾘﾍﾟｱの放置で､けっこういけそう |
| ↑(数えるほどの)､少数のNot Ready停止はあったが､それ以外は､ほぼ放置で最後まで | |
| ↑相変わらず､Dﾋｯﾄしないﾃﾞｨﾚｲが大量で､Dﾋｯﾄが少し | |
| 7 | Ubuntu 18.08で､新品3T:AFTに､ddｸﾛｰﾝ開始 |
| ↑bs=512で | |
| 8 | ↓大量のDﾋｯﾄなしﾃﾞｨﾚｲと､多数のB残りのわりには､(序盤の)ｴﾗｰが少ない感じ |
| 6.4MB地点 × 1 | |
| 6.5MB地点 × 8 | |
| 3.1GB地点 × 9 | |
| 48GB地点 × 9 | |
| 53GB地点 × 大量 | |
| 94GB地点 × 大量 | |
| 403GB地点 × 8 | |
| 879GB地点 × 25 | |
| 972GB地点 × 28 | |
| 999GB地点 × 1 | |
| 1,644.9 〜 1,645.01GB地点 × 大量 | |
| 1,645.02GB地点 × 1 | |
| 1,698.16GB地点 × 1 | |
| ↑まあ､ｴﾗｰが出ないｾｸﾀでも､ﾃﾞｰﾀが壊れているｹｰｽは､多々あるが | |
| 9 | 1,000G 〜 1,600Gは､速かったが､そこからがすごく遅い |
| ↑ｴﾗｰ×0だが､数値がつっかえつっかえ､進むような感じ | |
| ↑これがまさに､(大量の)｢Dﾋｯﾄなしﾃﾞｨﾚｲ｣の､ｴﾘｱかも | |
| 10 | 1,650Gあたりから､ﾍﾟｰｽがﾏｼになってきたが､やはり頻繁に､つっかえがある |
| 11 | 1,738.090Gあたりから､ｶﾀｶﾀ + ｶﾘｶﾘとうるさくなり､大量に読み取りｴﾗｰが増えていく |
| ↑1,738.100Gあたりで､静かにはなったが､512Bずつ､読み取りｴﾗｰが増えていく | |
| ↑1,738.108Gあたりで､いちおうｶｳﾝﾀｰが正常に | |
| ↑1,738.109Gあたりで､また､ｶﾀｶﾀ + ｶﾘｶﾘ = ｴﾗｰが基本だが､ｶｳﾝﾀｰが上がるときもあり | |
| ↑1,738.110851584Gで､ｶｳﾝﾀｰが止まった = ｶﾀｶﾀ + ｶﾘｶﾘすることはあるが､止まったまま = ｱｸｾｽ･ﾗﾝﾌﾟもつかず | |
| ↑少しして､高速ｴﾗｰ･ｶｳﾝﾄが開始 = ｶﾘｶﾘもないし､ｱｸｾｽ･ﾗﾝﾌﾟも消灯 = 読み取りできないなら､最後までｾﾞﾛﾌｨﾙでもいい | |
| 12 | 残りの1.4Tは､(すべてｴﾗｰだったが)､3Tすべてが終わるまでに､数日かかった |
| 13 | ﾕｰｻﾞが､｢3分の2ぐらい､ﾃﾞｰﾀが埋まっている｣とか言うから､2Tぐらいあるのかと思ったら､500Gで充分に収まる程度だった |
| 14 | ↓Windowsの認識で､以下 |
| 原本 = ﾌｧｲﾙ:24,674 + ﾌｫﾙﾀﾞ:474 + 容量:423GB | |
| ｸﾛｰﾝ先 = ﾌｧｲﾙ:24,028 + ﾌｫﾙﾀﾞ:464 + 容量:397GB | |
| ↑ｸﾛｰﾝ先が､ﾌｧｲﾙ : - 646 + ﾌｫﾙﾀﾞ : - 10 + 容量 : - 26GB …!! | |
| ↑(Regene後)､原本からﾃﾞｰﾀをｺﾋﾟｰしたほうが､救えるﾃﾞｰﾀが多いのかよ…!! | |
| ↑当然､ｶｳﾝﾄはされても､開けないﾃﾞｰﾀも多数だろうが | |
| ↑しかし､ddｸﾛｰﾝ先で､ｶｳﾝﾄさえもされないﾃﾞｰﾀが､こんなに多数だとは… (勉強になった) | |
| 15 | 原本を内蔵に戻し､Ubuntuのｴｸｽﾌﾟﾛｰﾗで､ﾌｧｲﾙのｺﾋﾟｰ開始 |
| ↑ﾌｧｲﾙ = 25,159とは､(Windowsの認識よりも)､+ 485多いが､隠しﾌｧｲﾙか | |
| ↑ｺﾋﾟｰ先がSSDだが､進行ﾍﾟｰｽは､かなり遅い(= しょっちゅう､つっかえるようなｲﾒｰｼﾞ) | |
| ↑序盤で､残り426時間(= 18日)が､表示されたことも | |
| 16 | もし再度､Regeneをかけるなら､ﾃﾞｰﾀが500G未満ということは､700G地点までで充分だろう |
| ↑ということは､700Gを4,096MBで割ると､｢ (Regene認識が)､172GB地点までで､充分 ｣ということだ | |
| 17 | ﾌｫﾙﾀﾞ一覧の窓の上､(小さな)円ｸﾞﾗﾌでｺﾋﾟｰの進行状況が示されるが､それをｸﾘｯｸすると､具体的なﾌｧｲﾙ数の小窓が開く |
| ↑その小窓を[×]で閉じると､ｺﾋﾟｰ処理自体がｷｬﾝｾﾙされてしまった | |
| ↑要注意 | |
| 18 | ﾌｧｲﾙ : 2,516 / 25,159あたり(= ちょうど､10%あたり)から､ものすごい遅い |
| ↑残り1,700時間(= 71日)の､表示が出たこともある | |
| ↑それでも､ﾀｲﾑ･ｵｰﾊﾞｰしないでくれるのは､(すごく)､ありがたいが | |
| ↑｢95%は､救えるのが確定したが(= Ubuntu認識と､ｸﾛｰﾝ先ﾃﾞｰﾀの量から割り出して)､少しでも100%に近づけるために､あと30日｣で､中間報告した | |
| ↑30日 = 残り:720時間以下の表示なら､余裕がある | |
| 19 | 残り310時間(= 13日)ぐらいで､(ある意味)､ﾍﾟｰｽが落ち着いたように見えるが､それでも､ｶｳﾝﾄの上がりを観察していると､ｽﾄﾚｽがたまるほどの遅さだ |
| ↑ﾓﾆﾀの輝度を､最低に落とした | |
| ↑ﾎﾞﾔっとして､進行状況はよく見えないが､ｺﾋﾟｰ･ｴﾗｰの窓が出ているかどうかは､すぐにわかってちょうどいい | |
| 20 | ↓結果､ｺﾋﾟｰ･ｴﾗｰは､数えるほどだった |
| [1]. 晦日日出SN.jpg / 2018 12 30 高下ﾀﾞｲﾔD3x | |
| [2]. 2019 03 23 久遠寺 D3x(18).NEF / 2019 03 23 久遠寺 D3x(18) | |
| [3]. 2019 03 24 富士山 寺巡り D3x(73).jpg / 2019 03 24 富士山 寺巡り D3x | |
| [4]. 2019 03 24 富士山 寺巡り D3x(73).NEF / 2019 03 24 富士山 寺巡り D3x | |
| [5]. 2019 05 03 冨浦 D3x 300mm(3).JPG / 2019 05 03 冨浦 D3x 300mm | |
| [6]. 2019 05 03 冨浦 D3x 300mm(3).NEF / 2019 05 03 冨浦 D3x 300mm | |
| [7]. 2019 05 03 冨浦 D3x 300mm(4).JPG / 2019 05 03 冨浦 D3x 300mm | |