ボリュームをfsckするのにどのくらい時間がかかりますか？

現在300〜500万ページビューを提供しているウェブサイトを運営しています。私たちのサイトはファイル共有サイトなので、250,000ファイルと数千のシンボリックリンクが含まれています。

ハードディスクは1500GB SATAディスクです。

使用hdparmして、ハードディスクの速度が15〜20 MB /秒（80 MB /秒）に低下したことがわかりました。

それではfsck、ディスクの問題を修正するために実行したいと思います。

1. ウィルfsckこの問題を解決するのだろうか？
2. どのくらいの時間がかかります fsck完了するまでにかかりますか（予定しているダウンタイムを計算したいだけです）？

同時にアクセスされるファイルの数が増えると、速度の低下が予想されます。ハードディスクドライブは、並行してアクセスされることを好みません。読み取り/書き込みヘッドがシリンダーを切り替える必要があるたびに、数ミリ秒を失います。2つのファイルが同じシリンダーまたは同じトラック上にある場合でも、ローテーションが1つから別のローテーションに移動するまで待機する必要がある場合があります。メガビット/秒でドライブのパフォーマンスを測定する場合は、並列アクセスが増加するにつれて、指数関数的に低下することが予想されます。

fsck これは役に立ちません。ディレクトリ構造の損傷を修復するだけで、最適化は行いません。

理想的なソリューションは、ソリッドステートストレージへの切り替えです。これには、回転するプラッターの物理的な制限がないためです。しかし、それはおそらく法外な費用です。

次善の策は、並列アクセス用に最適化されたRAIDを使用することです。RAIDは多くの異なるパフォーマンスプロファイルに合わせて構成できるので、特定のRAIDハードウェアとドライバーの設定を理解するには少し時間がかかることに注意してください。

アグレッシブなファイルシステムキャッシングを使用すると、問題を軽減できる場合があります。システムに十分なRAMがある場合、Linuxはすでにこれをかなりうまく行っているはずです。次のようなプログラムを実行しますtop空きRAMの量を確認します。しかし、最も一般的に使用されるファイルがRAM（または取得する可能性が高いRAM）に収まらない場合、これは実際には役に立ちません。

貧乏人の回避策は、ファイルをいくつかの異なる物理ハードドライブ（同じドライブ上の異なるパーティションだけではない）に分割することです。これは実際には長期的なスケーラブルなソリューションではなく、まともなRAIDよりもコストがかかります。しかし、ドライブが横になっている場合は、すぐに解決できるかもしれません。

ハードディスクドライブを含むソリューションの場合は、回転速度が速く、シーク遅延が少ないことを確認してください。

私はここにハードドライブのパフォーマンスに関するいくつかの一般的な背景を持つ記事を書きました：

UNIXのヒント-ファイルシステム

fsckが完了するまでに5時間かかると思います。

代わりに、reiserfsへの移行を検討します（つまり、テスト、テスト、およびテスト）。

1. いいえ（fsckは破損したディスクではなく、破損したファイルシステムメタデータを修正できます。また、最適化ツールでもありません）。
2. ファイルシステムに依存します。ext3を使用すると、耐え難いほど長いため、数時間予約します。ext4やxfsなどの最新のファイルシステムは、簡単に1桁速くなります。

hdparmは順次読み取りを行います。他の人が言ったように、ファイルサーバーディスクは多くのシークを実行しているはずです。

HDエラーが発生している場合、それらは/ var / log /のどこかに表示されているはずです。

"smartctl -t short / dev / sda"を試してから "smartctl -t long / dev / sda"を試してみませんか?? ...ほとんどの新しいHDDでは、HDを使用しているときでもこのコマンドを発行できます。スマートはあなたにいくつかの結果を与えます。「smartctl --all / dev / sda」を使用してHDDの状態を読み取ることができます。

同時アクセスでマウントされているHDDにhdparmを送信する場合、それが結果が以前よりもはるかに少ない理由の1つである可能性があります。

できるだけ早くRAIDセットアップにデータを移動する必要があります。