研究で使っているデスクトップのCドライブ使用率が100%に張り付く事象が発生した。
HDDに原因があると思い，安易にchkdskをかけたら，1週間近くかかってしまった話。
チェックディスク(chkdsk)のきっかけ
10月も終わりに差し掛かったある日のこと。
研究室PCのCADで作業していると，ディスク使用率が100％になる事象が発生した。この事象は，CADを閉じても，解消しなかった。何をするにしても，もっさりして，作業にならなかったので，ネットで解決策を探した。
いろいろ探した結果，以下の記事を参考に，（迂闊にも）チェックディスク(chkdsk)をやってみることにした。
何も調べず，この記事を鵜呑みにして，以下のコマンドをコマンドプロンプトへ入力した。
chkdsk.exe /f /r
そして，次回再起動時に，チェックディスクを実行するようにしてしまった。
オプションによっては膨大な時間がかかる
これが良くなかった。もし，chkdskを「いまからやろうとしている」のであれば，ちょっと待って欲しい。
上記コマンドにつけたオプション「/f」および「/r」は，以下のページを読んでもらうとわかるように，ディスク上のエラーを修正し(/f)，なおかつ見つかった不良部分を回復しようとする(/r)オプションなのだ。
ほかにもネットで調べてもらえばわかるように，上記の処理は，ディスクをチェックする「chkdsk」コマンドのなかでは，かなり重たい処理だ（chkdskについては，公式リファレンスを除けば，以下の記事が正確で網羅的かつわかりやすかった）。
この処理を，TB級のHDDに実行するとどうなるか。それはもう膨大な時間がかかるわけだ。調子のいいディスクならまだしも，今回の自分のPCのように，不調のディスクのチェックとなると，さらに長い時間がかかることは間違いない。
しかも，上記の記事に書いてあるように，いったんchkdskを始めると，終了するまで止めてはいけない（もし，途中で止めてしまうと，HDD破損のリスクが高まるようだ）。
そのうえ，終了までの時間は，HDDの状態に大きく依存し，予測するのは難しいらしい。
Q3. Chkdsk の時間の見積もり方法について教えてほしい。
最後に、Chkdsk の実行時間の見積もり方について、ご説明します。
「Chkdskの動作について」social.technet.microsoft.com
一般的には、読み取り専用 Chkdsk ではそれほど長い時間はかかりませんが、/f または/r のオプションを付加して修復を行う場合に長い時間がかかります。
Chkdsk にかかる時間は、ボリュームの状態、ファイルの数、システムのスペックに依存するため、事前の予測は非常に困難です。
特にファイルの数に大きく依存しますので、ファイルの数が多い場合はそれだけ長い時間がかかるとお考え下さい。
見積もる方法としては対象のディスク/ボリュームのコピーを作成し、業務影響のない環境にて Chkdsk コマンドをお試しいただくことが挙げられます。
これらのことを肝に銘じて，処理を実行しなければならなかった。しかし，自分の場合，そうとは知らないまま実行してしまった。
1週間近くかかったchkdsk記録
ネット上で自分が調べた限り，TB級のHDDにchkdskをかけた事例は，ほとんど見当たらなかった。そこで以下では，実際にchkdskをかけたらどうなったかを，日記や写真を振り返りつつ，記録した。
記録を見るに必要な知識
chkdsk.exe /f /r
上記オプションでChkdskを実行した場合，修復には全部で５つのステージがあるらしい。
補足) Chkdsk の動作について
Chkdsk の動作は 5 段階のステージで構成されています。
オプションを付けない読み取り専用モードでの実行はステージ 3 まで実行し、/f オプションはステージ 4 まで、/r オプションはステージ 5 まで実行します。– ステージ 1 : マスタ ファイル テーブル (MFT) 内の各ファイル レコード セグメント (FRS) の検証
「Chkdskの動作について」social.technet.microsoft.com
– ステージ 2 : ボリューム内のフォルダーの検証
– ステージ 3 : 各ボリュームのセキュリティ記述子の検証
– ステージ 4 と 5 ( オプションのステージ ) : ボリューム内の全てのセクターの読み取り、安定性の確認
chkdskの進捗を示すまえに，PCのざっくりとした仕様は以下の通り。
- OS：Windows 10 Pro
- CPU：Intel Core i7
- Cドライブ：TOSHIBA HDD (1TB，うち使用可能領域930GB，このうち540GBくらい使用）
- メモリ：16GB
10/31(月): 日中の間にstage5まで進む
自分のPCでは，今回，2022年10月31日の午前から，再起動をかけてchkdskを始めた。
＊
以下は，同日20:10，帰宅前に撮影した写真。hpのロゴの下には，「Fixing (C:) Stage 5: 15%…」の白文字が表示されていた（写真がちょっと歪んでいるのは，縦写真を回転させているからです）。
ここで表示されている「Stage」が，chkdskのStage１－５にあたる。カッコ内の（XXXXXXXX of YYYYYYYYY）は，（処理済みのセクタ of 対象セクタ数の合計）であると思われる。自分のPCだと，Stage５の処理セクタは，全部で1億4000万もあることになる。日本の人口より多い。
次に書いてある，Total: XX%は，Stage１－５全部で何％処理が終わったかを表していると思われる。
「ETA」とは，Estimated Time of Arriaval：到着予定時刻。ここでは，処理が終わるまでにかかりそうな時間ということになる（が，これはほとんどあてにならないことが，後々判明する。というか，Windowsのファイル処理などで，こういう「残り時間」が基本的にあてにならないのはよくあるので，ことさら新事実だというわけでもない）。
＊
朝にchkdskを始めて，夜もこの状態。ということで，この日は1日，PCを使った作業ができなかった。そういうわけで，午前中は投稿準備中の論文を紙の上で修正し，昼からは実験をした。データは，別途研究室に備えられている計算機上で整理した。計算機といっても，スペックが高い以外はふつうのPCなので，これで最低限のことはできた。
ちなみにこの日，論文の相談でBossに声をかけられたついでに，PCのことも相談しておいた。どうやら，新しいPCが，予備として温存されていることがわかった。
chkdskが終わったら，そのPCを使いたいことをほのめかしておいたので，データを救い出せさえすれば，すぐに新しいPCに移行できそうだ。そうはいっても，データを救出できるかどうかは，chkdskが正常に終わるかどうかにかかっている。なんとか頑張ってくれ…
11/1(火): PCは使えないが，できることをする
翌朝，研究室へ行くと，PCは以下の画面を表示していた。
昨晩は，stage 5の15%だった。少しずつではあるが，着実に進んでいるようだ。ここまで見た限りだと，XXXXXXXX(処理済みセクタ) of XXXXXXXXXのうち，処理済みセクタの下3桁は，ずっと「629」のままで，下から4桁目（千の位）と5桁目（万の位）が，数秒～数十秒に１つずつ進んでいた。すなわち，進捗速度は毎分102～103セクタといったところだ。
このペースだと，今日もPCは使えないとあきらめ，放置した。このブログを書いているノートPC（Thinkpad）を，HDMIでディスプレイにつないで作業した。作業といっても，chkdsk中のHDD上にあるデータは使えない。昨日の実験データの整理と，報告資料用の図の作成に終始した。あと，後輩の報告資料もチェックした。
＊
帰るまえ（18時前ごろ）にPCをチェック。stage 5が49％まで進んでいた。今日の日中（9時間少々）で10％進んだ。もどかしいが，強制終了すれば，生きているデータまで救出できなくなる。
ちなみに，バックアップのHDDを確認すると，最後のバックアップは8月上旬だった。つまり，8月から先月末までの約3カ月分のデータが救出されなくなるということだ。
このなかには，論文の図や発表用スライド，予稿，計算データ・資料などが含まれる。処理の大変な実験データは含まれていなかった。別にバックアップしてある報告資料を見返せばなんとかなるものも多いが，それでも，完全なデータを復旧できるに越したことはない。うまく終了して，PCを再起動できることを祈るばかり，。ネット上には，TB級のHDDを完全なオプションでchkdskすると，2-3日はかかるという情報もあるから，できることをやりながら気長に待ちたい。
＊
という思いを抱きつつも，帰宅してから，ネット上で情報を漁った。こういうとき，結果や解決策を調べても何にもならないのだが，ついつい調べてしまう。期待せず，できることを淡々とやったほうがいい。
＊
全然関係ないが，Windowsではこういうトラブルが突然起きるから怖い。Systemとして完結している（らしい）Macが欲しくなった。そうでないにしても，バックアップくらいは定期的にとりたいと思った。
11/2(水)：停電があるらしいが，速度が低下
chkdsk３日目。Stage 5は55%まで進んだ。昨晩から6%進んだ。画面を見るたびにETAが増えている。進行速度が明らかに遅くなっている。今日も，PCの使用はあきらめた。
この日の午後は，後輩の実験に付き添いつつ，報告資料をノートPCで書いた。後輩の実験のあと，自分の実験に必要な試験をやった。PCは調子が悪いけど，試験はうまくいった。
このデータは，計算機をつかって，外付けデータドライブに整理した。
＊
整理が終わった帰り際，Bossが声をかけてくださった。chkdskの状況を説明すると，待つしかないねとのこと。そして，予備用のSSD搭載PCがあるとも仰っていた。
また，再来週には，全館で停電があることも教えてくださった。それまでに立ち上がらなければ，リスクを取って強制終了→再起動するか，非常用電源（？）を用意して続行させるか，決断しなければならなくなる。これは大変。
まあ，速度は遅いけれども，全然進んでいないわけではない。何より，強制終了にはデータ喪失のリスクが伴う。もう少し，様子を見ようと思う。さすがに，再来週までには終わるだろう（終わらなければ，その週にある学会のスライドも間に合わない）。
＊
結局この日は，20時前に帰った。実験データの整理は，いつもより時間がかかった。常用のPCが使えないとは，こんなに不便なものなのか。
chkdskは，Stage 5の60%まで進行していた。日中（12時間）で，5%しか進まなかった。が，木・金・土・日と経れば，なんとか100％までたどり着けるペースではある。頼むから頑張ってほしい。ハードを壊すリスクを負って強制終了するという「ハード」な選択だけはしたくない。早く論文の図を直したい。発表資料も作り進めたい。
11/3(木・祝)：文化の日，まだまだ先は長い
この日は文化の日ということで，休日。9時過ぎまで寝て，洗濯した。
いい天気だから，広場か公園へ昼寝でもしに行こうかと思い，そのついでにLab.へ寄った。
chkdskは４日目。Stage 5は65%まで進んでいた。昨晩（１４時間くらいまえ）から5%まで進んだ。この１日は，だいたい24時間で10％くらいのペース。まだまだ，先は長い。
一昨日，欲しくなったMacについて，ネットサーフィンした。何となく性能とか価格がわかった。
11/4(金)：便利な外部ディスプレイ
chkdsk５日目。朝，進捗を確認すると，Stage 5は71%まで進んでいた。ついに，処理済みセクタの数が100,000,000（1億）を突破した。しかし，昨日午前中からの進捗は6％。つまり，丸1日で6%しか進んでいない。2日前より，さらにスピードが落ちている。これは，ひょっとすると，HDDの調子が相当悪いのかもしれない。もし，chkdskが無事に終わったとしても，Windowを通常起動できるかどうかは怪しいかもしれない。
この日は，午前中，輪講や実験治具の作成，そのほか雑務などをこなした。いずれも，ノートPCだけで済ませられた。
午後からは，２週間半後の学会発表にむけて，講演用のスライドを作り始めた。スライド自体は，全体の1/3くらいつくっていた。このデータは，現在chkdsk中のHDD上にしか入っていない。とりあえず，のこりの2/3の部分を，クラウドにアップしてある原稿データをもとに，先回りして作ることにした。
スライドは，ノートPCと，外部ディスプレイを繋いでつくった。外部ディスプレイは，今，chkdsk中で，つかっていなかったディスプレイのうちの1枚。HDMIケーブルを介して，ThinkpadのHDMIポートから，ノートPCの画面を拡張した。
ノートPCには，パワーポイントが入っていて，データもあるので，割としっかりスライドをつくれた。
この状態で，16時前は治具の作成のつづき，そのあと，報告資料用に試験データをまとめた。ふだん，デュアルディスプレイで作業している感覚だと，ノートPCのディスプレイは狭すぎて作業が捗らない。しかし，外部ディスプレイ1枚つなぐだけで，ノートPCでも効率は高まった。外部ディスプレイの力は侮れない。
＊
先述のように，chkdskは，数秒～数十秒に１回，千から万の位が１つ進む。そして，ロゴの下の白いグルグルが，グルグルと回り続ける。ちらちらと気になるので，今日はディスプレイを切っていた。
帰る前（18時過ぎ）に，ディスプレイの電源を入れて進捗をチェックすると，Stage 5の84%まで進んでいた。今朝はStage5の71%だったから，今日の日中で13%進んだことになる。どうやら，今日の日中で加速したようだ。ETAも18時間→10時間まで減っている。
ここまでずっと，chkdskのペースは落ちる一方だったが，ここへきて加速に転じた。この調子で，なんとか土日の間に終わってほしい。そう願いつつ，ディスプレイの電源を入れたままで週末に入った。
11/5(土)・6(日)：chkdskの確認なし
週末は研究室に行かなかった（土日くらいは，研究や研究室から身を離すようにしているので）。
午後の暇な時間に，ネットサーフィンして，PCのことを調べたりした。研究用のノートPCが研究費で買えるようになったら，下宿のPCはデスクトップにしてもいいなあと思った次第。
また，昨日一昨日あたりで，外部ディスプレイの快適さを実感した。なので，ディスプレイについても調べた。いろいろ勉強になったので，iPadのメモに残しておいた。こういう雑多な知識は，ネットサーフィンで集めるのが効率的だし，楽しい。
11/7(月)：chkdskは終わっていた
さて，土日を終えて，月曜日になった。木曜日あたりからのペースに加えて，金曜日の加速もふまえると，もうchkdskは終わっていてもおかしくない。というか終わっていてくれ。
そう願いながら，Lab.へ行って，おそるおそる居室の自分のデスクへむかった。つけっぱなしだったはずのディスプレイをのぞき込むと，，，
白いグルグル，Stage 5:XX%，，すっかり見慣れてしまった表示が消えていた。
どうやら，chkdskは，土日の間に終了したようだ。
よかった。。。。とりあえずホッとした。
＊
ここから，PCを再起動のうえ，データを救出していく作業に入っていくのだが….
chkdskにこれだけの長時間がかかったのだから，そのまま再起動できるはずはない。
データ救出までの道のりは，まだまだ長い。
ここから先の話（再起動およびデータの救出）は，長くなるので，別の記事にまとめようと思う。
【次の記事】
不調のHDD(1TB)をchkdskしたら1週間近くかかった話
chkdskの進捗速度とログ
chkdsk進捗速度の記録
以上が，長い長いchkdskとの格闘の記録だ。記録をとっている範囲で，chkdskの進捗をグラフ化すると，以下の通り。
![chkdsk.exe f/ r/ for windows 10 pro (hp, 930GB HDD [Toshiba])](https://take26.com/wp-content/uploads/image-27.png)
11/3から11/5にかけて，Stage 5の進捗が著しく低下していることがわかる。我ながら，よく我慢したと思う。
我慢の甲斐あってか，11/4日中から，徐々に加速している。同図から，終了日時は11/5午後遅く～11/6未明と推測される。結果的に，chkdsk.exeの開始から終了まで，丸6日近くかかった。
さすがに長かった，，，この1週間で，精神をかなりすり減らした。
吐き出されたログ：8846KBもの不良セクタ
chkdsk終了からの再起動（およびデータ救出）については，長くなるので別の記事でまとめるとして，再起動後に回収したchkdskのログのみ貼っておく。
ログは，イベント ビューア―にて確認できる。詳細な方法および結果の見方については，以下を参照した。
＝＝＝（ここからログ）＝＝＝
Checking file system on C:
The type of the file system is NTFS.
Volume label is Windows .
A disk check has been scheduled.
Windows will now check the disk.
Stage 1: Examining basic file system structure ...
Cleaning up instance tags for file 0x19c3.
The USA check value, 0x2e, at block 0x1 is incorrect.
The expected value is 0x21f.
The USA check value, 0x2e, at block 0x1 is incorrect.
The expected value is 0x21f.
The USA check value, 0x2e, at block 0x1 is incorrect.
The expected value is 0x21f.
The USA check value, 0x75, at block 0x1 is incorrect.
The expected value is 0x21f.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0x11a.
The USA check value, 0x6f, at block 0x1 is incorrect.
The expected value is 0x11a.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0x11a.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0x11a.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0xc.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0x38.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0xf.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0xc.
1520640 file records processed.
File verification completed.
Phase duration (File record verification): 48.66 seconds.
22978 large file records processed.
Phase duration (Orphan file record recovery): 0.00 milliseconds.
0 bad file records processed.
Phase duration (Bad file record checking): 1.47 milliseconds.
Stage 2: Examining file name linkage ...
The USA check value, 0x2e, at block 0x1 is incorrect.
The expected value is 0x21f.
The USA check value, 0x2e, at block 0x1 is incorrect.
The expected value is 0x21f.
The USA check value, 0x2e, at block 0x1 is incorrect.
The expected value is 0x21f.
The USA check value, 0x75, at block 0x1 is incorrect.
The expected value is 0x21f.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0x11a.
The USA check value, 0x6f, at block 0x1 is incorrect.
The expected value is 0x11a.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0x11a.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0x11a.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0xc.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0x38.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0xf.
The USA check value, 0x0, at block 0x1 is incorrect.
The expected value is 0xc.
114192 reparse records processed.
2027932 index entries processed.
Index verification completed.
Phase duration (Index verification): 11.78 minutes.
0 unindexed files scanned.
Phase duration (Orphan reconnection): 8.72 seconds.
0 unindexed files recovered to lost and found.
Phase duration (Orphan recovery to lost and found): 2.56 minutes.
114192 reparse records processed.
Phase duration (Reparse point and Object ID verification): 184.78 milliseconds.
Stage 3: Examining security descriptors ...
Cleaning up 4748 unused index entries from index $SII of file 0x9.
Cleaning up 4748 unused index entries from index $SDH of file 0x9.
Cleaning up 4748 unused security descriptors.
CHKDSK is compacting the security descriptor stream
Security descriptor verification completed.
Phase duration (Security descriptor verification): 2.30 seconds.
253647 data files processed.
Phase duration (Data attribute verification): 1.68 milliseconds.
CHKDSK is verifying Usn Journal...
Usn Journal verification completed.
Stage 4: Looking for bad clusters in user file data ...
Read failure with status 0xc000009c at offset 0x5f0669d000 for 0x10000 bytes.
Read failure with status 0xc000009c at offset 0x6230211000 for 0x10000 bytes.
1520624 files processed.
File data verification completed.
Phase duration (User file recovery): 8.59 hours.
Stage 5: Looking for bad, free clusters ...
141861295 free clusters processed.
Free space verification is complete.
Phase duration (Free space recovery): 0.00 milliseconds.
Adding 2224 bad clusters to the Bad Clusters File.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.
No further action is required.
975550463 KB total disk space.
405817152 KB in 1103948 files.
665212 KB in 253650 indexes.
8896 KB in bad sectors.
1622919 KB in use by the system.
65536 KB occupied by the log file.
567436284 KB available on disk.
4096 bytes in each allocation unit.
243887615 total allocation units on disk.
141859071 allocation units available on disk.
Total duration: 8.85 hours (31875728 ms).
Internal Info:
00 34 17 00 eb b5 14 00 41 d0 24 00 00 00 00 00 .4......A.$.....
c4 0d 00 00 4c b0 01 00 00 00 00 00 00 00 00 00 ....L...........
＝＝＝（ここまでログ）＝＝＝
ログの見方は完全には理解できていないが，「8896 KB in bad sectors.」との記述があった。これは，HDD上に，これだけの不良セクタが存在するという意味。やはり，HDDが不調みたいだ。
まとめ
HDDのchkdskは，安易に実行すべきではない。時間に余裕のある時にやるべき。もしやるにしても，データをバックアップしてからにしよう。
ちなみに，自分の研究データは，3カ月前（8月）を最後にバックアップされていなかった。もし，chkdskを途中で止めたりしていたら，3カ月分の研究データが丸々無くなるところだった。。。
みなさん，ご安全に。
（この記事が，chkdskがいつまで経っても終わらないという方の励ましになれば幸いです）
（おわり）