回答編集履歴
1
S\.M\.A\.R\.Tの読み方について sharowさんの回答にポインタ
answer
CHANGED
|
@@ -5,7 +5,6 @@
|
|
|
5
5
|
|
|
6
6
|
このログからわかることは、少なくとも /SVN/reps/contentShared/db/revs/553 が記入された部分が損傷しているという事実です。原因が単なるファイルシステムのエラーなのかハードディスクの故障なのかは、他の部分も調査してみないとなんとも言えません。
|
|
7
7
|
|
|
8
|
-
|
|
9
8
|
## まずはバックアップの確保
|
|
10
9
|
|
|
11
10
|
Subversion はそのデータ構造上、途中のリビジョンが破損しているとリカバリは非常に困難ですので、まず、553 のバックアップがないのであれば、早急に別ドライブにバックアップしてください。物理故障であれば、失敗しても何度かトライすると読める可能性があります。
|
|
@@ -21,6 +20,8 @@
|
|
|
21
20
|
ディスクはそれ自身、不良セクタを検知すると、そのセクタを避けて代替セクタを使うように動作します。そのセクタが不良であるとマークされたあとは、そのセクタを踏んでいるファイルを編集した段階で代替セクタが使われます。今回のケースでは、553ファイルをバックアップから書き戻せば代替セクタが使われることが期待できます。
|
|
22
21
|
事前に用意した代替セクタを使い切ってしまうと、それ以上は対処できなくなります。smartctlコマンドが使えるようであれば、S.M.A.R.T関連で他にエラーが検知されていないか調べてみてください。大量に出ているようならディスクの寿命が近いので、リプレースをおすすめします。
|
|
23
22
|
|
|
23
|
+
追記: S.M.A.R.T情報の取り方や読み方は、この質問のsharowさんの回答がとても詳しく大変参考になるので参照してください。(追記ここまで)
|
|
24
|
+
|
|
24
25
|
## 修復
|
|
25
26
|
|
|
26
27
|
パーティションのフォーマットがntfsのようなので、エラーチェックや修復をするのに、fsckよりはWindowsのchkdskのほうが相性が良いかもしれません。バックアップが確保されていることを改めて確認したうえで、修復モードで実行することで、ディスクのエラーおよびファイルシステムの整合性がチェックされます。不整合があってみなしごだったファイルは、救出可能であればマウントポイントの lost+found とか FOUND.000 といったディレクトリに移されています。
|