web-dev-qa-db-ja.com

不適切なシャットダウン（fs ext4）によるLinuxファイルシステムの破損？

私は多くのLinuxサーバーを管理してきましたが、他のどのOSよりもLinuxサーバーで遊ぶのはとても簡単です。しかし、Linux OSで問題が発生することがあるのは、ファイルシステムの破損です。この問題は、Windowsサーバーでは発生しません。

私はインターネットで詳細に解決策を探しました、ほとんどこれらはすべてによって与えられた提案です。

  1. バックアップと復元を維持する

私のコメント==> 100％同意しましたが、クラッシュしたOSの復元に苦労する必要がない解決策を探しています。

  1. Fsckを実行します

私のコメント==>私の経験では、いつか追加の問題が発生します。

  1. 適切なシャットダウン/再起動を実行します。

私のコメント==>誰もが適切にシャットダウン/再起動したいと思っています。サーバーが応答しない、または適切にシャットダウンまたは再起動できないというまれなシナリオについて話しています

  1. Btrfs ==>

私のコメント==>本番環境では十分に安定していません

  1. Ext4にアップグレードする

私のコメント==>すでにext4を使用しています

  1. ハードディスクをアップグレードします私のコメント==>ディスク障害が原因ではなく、主に不適切なシャットダウンが原因で問題が発生します。

Fsckに関する私の問題：

  1. -yオプションを指定して実行すると、fsckがファイルシステムを破損することがあります

  2. fsckはシステムを修正するのに約1日か2日かかりますが、これは実稼働環境では問題ありません

私の質問は、btrfsが安定するまで、この問題を解決するための回避策はありますか？

たとえば、ファイルシステムを数分に1回「同期」します。または再起動する前にすべてのファイルシステムの変更を同期するスクリプトを作成する

私は提案ではなく、この問題の解決策を探しています。

linuxfilesystemskernelpartitionlinux-kernel
2
Mani

ext4は、プラグを引っ張っても弾力性がある必要があります。ただし、そのためには、ストレージサブシステムがコミットされた書き込みを失わないようにする必要があります。

まず、barrier=0/nobarrierでマウントしていないことを確認します。これにより、パフォーマンスが向上することがよくありますが、適切なシャットダウンが実行されない場合、破損が発生します。また、カーネルログをチェックして、スタック内の何かがバリアをサポートしていないためにバリアがext4によって無効にされていないことを確認します。

少なくとも磁気（非SSD）ディスクで次に試すことは、ディスク書き込みキャッシュを無効にすることです。ディスクが実際にプラッターにデータを書き込んだときにうそをつくことがあります。これにより、パフォーマンスが向上します（電源が切れない限り）。通常、これはhdparm -W0（IDE/SATAの場合）またはsdparm --clear=WCE（SCSI/SASの場合）で実行できます。特にSATAの場合、電源を入れ直すとデフォルトにリセットされる可能性があるため、これらをブートスクリプトに追加する必要がある場合があります。

書き込みキャッシュがデータを失っていないことを確認するための（かなり古い）スクリプトがあります。スクリプトとその使用方法については、 Brad Fitzpatrickのdiskchecker.plブログ投稿 を参照してください。

SSDを使用していて問題が発生している場合は、残念ながら、別のディスクを探す必要があるかもしれません。

5
derobert