Linux Software Raidは、月の第1日曜日にcheckarrayを実行しますか？どうして？
Debianには毎月第1日曜日にcheckarrayを実行するデフォルトがあるようです。
これにより、2TBのミラーで12時間、パフォーマンス上の大きな問題が発生し、ディスクが大量に使用されます。これを「万が一に備えて」行うことは、私にとっては奇妙なことです。いずれにしても、クォーラムなしで2つのディスク間で同期していないデータを検出すると、失敗します。
この大規模なチェックでは、回復不能なドライブ障害と破損したデータがあることがわかりました。これはいいですが、それほど役に立ちません。それは必要？
ディスクエラーがなく、ディスクに障害が発生したと考える理由もないのに、なぜこのチェックが必要なのですか？ cronから削除する必要がありますか？
/etc/cron.d# tail -1 /etc/cron.d/mdadm
57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet
洞察をありがとう、
RAID1を実行しているようですので、状況に応じてチェックを行う必要はないことに同意しますが、最初の回答者が示した理由のいくつかには同意しません。
1）RAIDはUPTIME/ACCESS SPEEDソリューションであり、バックアップソリューションではありません。 RAIDに障害が発生しても、データの損失を意味するものではありません。RAIDを使用するべきではないからです。
2）ドライブ全体のミラーリングが「非効率的」であると考える理由が気になります。すべてをミラーリングできるのに、なぜ複雑さを追加し、何かを逃さないようにコンピュータに依存する必要があるのですか？
3）「ディスク障害が発生した場合、大規模でアクティブなアレイのミラーまたはパリティディスクの再構築には数日かかる可能性があるため、危険です。この間隔で、劣化したアレイから別のディスクに障害が発生すると、データが失われます。」何とは対照的に、すべてを単一のディスクに保持しますか？ RAIDは完璧ではありませんが、データへのアクセスを失うことなくドライブ全体が死んでも生き残ることができ、データへのアクセスを失うことなく再構築できることを意味します。また、RAID1以外では、定期的なテストにより、悪化しているドライブを検出できます（特定のドライブの個々のブロック障害を追跡し、SMART data）を使用してフラグを付けることもできます）データにアクセスできなくなる前に障害が発生したため、データ損失のシナリオは、即時の壊滅的なドライブ障害だけではありません。
RAID1をチェックすることは依然として理にかなっており、定期的に行うことでデータを大幅に安全に保つことができます。
これは、ドライブがどのように故障する傾向があるかを深く掘り下げるまで、直感に反するように見えます。 2つのディスクの同期が取れていない場合、このチェックは効果がないことに同意します。しかし、ディスクの1つに、最近障害が発生したセクターがある場合はどうなるでしょうか。さて、チェック中にそのドライブから読み取ると、そのドライブの読み取りエラーが発生しますよね？ RAIDドライバーは、2番目のドライブに格納されているミラー情報から、障害のあるセクターに何を格納する必要があるかを認識しているため、RAIDドライバーにとって貴重な情報です。したがって、RAIDドライバーは、障害が発生したセクターを書き換えようとします（チェックモードでも、経験の浅いユーザーは読み取り専用と見なします）。この書き換えは機能する場合と機能しない場合がありますが、最近のディスクにはすべて、書き込み時に障害が発生したセクターを置き換えるスペアセクターがあります（読み取り時ではなく、読み取り時に読み取り障害のみが報告されます）。したがって、RAIDドライバーがセクターを書き換え、ハードドライブが障害が発生したセクターのスペアセクターを再割り当てすることにより、RAIDアレイはオンザフライで修正されます。 RAIDドライバーは、実際に再割り当てが行われたことを知りません（知る必要もありません）。これはドライブ自体の内部で行われ、適切に構成されている場合（smartctlを参照）、オペレーティングシステムは管理者に電子メールを送信して、セクターが再割り当てされたことを通知できます。つまり、ゆっくりと障害が発生しているディスクを交換するときです。最近の大きなディスクは、たとえば温度変動が原因で、これらの「保留中のセクター」の読み取りエラーを生成する傾向があります。それらをRAIDアレイで使用すると、信頼性が大幅に向上し、定期的なチェックを実行すると、問題のあるセクターが読み取りの問題が発生したときに自動的に更新されます。これらのリフレッシュ書き込みにより、実際にはセクターでの書き込み操作が成功する可能性があります。その場合、「保留中のセクター」は「再割り当てされたセクター」にはなりません。つまり、ディスクは次のことができるため、それほど悪くはありません。今セクターを書いてください。
とにかく、smartctlを使用して定期的なチェックを行うことで、RAIDアレイの信頼性を大幅に高めることができます。 zfs（zfs3やz3など）に関するコメントも重要です。ドライブのサイズが大きくなり、情報がより密に書き込まれ、ドライブのエンジニアリングがサーバー市場ではなく消費者市場によって推進されるにつれて、ストレージユニットあたりのデータ損失の全体的なリスクが劇的に増加します。ドライブでRAID5を複数のTBサイズで実行すると、再構築時間が長く、再構築中に他のすべてのドライブから広範囲に読み取る必要があるため、リスクがあります。必要に応じて、スペアが2つあるRAID6を検討してください。壊滅的なデータ損失の失敗の頻度から身を守るために（はい、それは単なる確率であり、コントローラーの失敗、停電など、他の要因も考慮する必要があります...多くの異なるコンポーネントの信頼性）。また、RAID6でさえ、RAIDZやZ3のように、3つのパリティドライブを使用する場合よりも数百倍信頼性が低い場合があります。
Zfsとbtrfsが通常のmdadm RAID5（状況によっては）と比較して興味深いソリューションのように見えることに同意します。
だが...
- btrfsには安定バージョンがありません。あなたは本当にこれを危険にさらしたいですか？
- zfsは成熟しているように見えますが、Linuxシステムのソリューションは少しパッチ的です。ヒューズ？サードパーティのネイティブカーネルモジュール？
私はネイティブサポートに固執すると言います-mdadm RAID1/5/6上のLVM2で...
私の2セント。
Debianのmdadmパッケージで毎月のcheckarrayを簡単にオフにできるという事実は、それがそれほど重要ではないことを私に示唆しています。 dpkg-reconfigure mdadmから受け取る関連メッセージは次のとおりです：
カーネルがそれをサポートしている場合（2.6.14以降のバージョン）、mdadmはMDアレイ（RAID）の冗長性を定期的にチェックできます。これは、ローカルセットアップによってはリソースを大量に消費するプロセスになる場合がありますが、まれなデータ損失の防止に役立つ可能性があります。エラーが検出されない限り、これは読み取り専用のチェックであることに注意してください。エラーが見つかった場合、mdadmはそれらを修正しようとします。これにより、メディアへの書き込みアクセスが発生する可能性があります。
個人的には、1TBのミラー（シンプルなファイルサーバー）で毎月1回実行されるcheckarrayスクリプトに問題はありません。日曜日の朝は3.5時間未満しかかかりませんが、それ以外は何も起こりません。 checkarrayが顕著なパフォーマンスの問題を引き起こしている場合、私はそれをオフにすることをためらわず、またはおそらく、より少ない頻度で実行するようにスケジュールします（たとえば、6か月ごと、特定の休日など）。