SSDドライブのext3パーティションでの突然の停電後のファイルシステムの破損は「予期される動作」ですか?


13

私の会社は、内蔵SSDドライブのext3パーティションから起動する組み込みDebian Linuxデバイスを作成しています。デバイスは埋め込まれた「ブラックボックス」であるため、通常は外部スイッチを介してデバイスの電源を切るだけで無作法にシャットダウンされます。

ext3のジャーナリングは物事を整理するので、これは通常は問題ありません。そのため、ログファイルの一部が時々失われることを除いて、物事はうまく動き続けます。

ただし、最近、いくつかのハードパワーサイクルの後にext3パーティションが構造上の問題を発生し始めるユニットを見てきました。特に、ext3パーティションでe2fsckを実行すると、次のような多くの問題が見つかります。この質問の下部にある出力リストに表示されます。エラーの報告(またはパーティションの再フォーマット)が停止するまでe2fsckを実行すると、問題は解消されます。

私の質問は...たくさんの突然の/予期しないシャットダウンにさらされたext3 / SSDシステムでこのような問題を見ることの意味は何ですか?

私の考えでは、これはシステムのソフトウェアまたはハードウェアの問題の兆候である可能性があります。私の理解では、ext3のジャーナリング機能はこれらの種類のファイルシステムの整合性エラーを防ぐはずだと理解しているためです。(注:ユーザーデータはジャーナリングされていないため、ユーザーファイルが変更/欠落/切り捨てられる可能性があることを理解しています。具体的には、以下に示すようなファイルシステムメタデータエラーについて説明しています)

一方、同僚は、SSDコントローラーが書き込みコマンドを並べ替える場合があり、ext3ジャーナルが混乱する可能性があるため、これは既知/予想される動作であると述べています。特に、正常に機能するハードウェアとバグのないソフトウェアが与えられたとしても、ext3ジャーナルはファイルシステムの破損を不可能ではなく不可能にするだけであるため、時々このような問題が発生しても驚かないはずです。

私たちのどちらが正しいですか?

Embedded-PC-failsafe:~# ls
Embedded-PC-failsafe:~# umount /mnt/unionfs
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Invalid inode number for '.' in directory inode 46948.
Fix<y>? yes

Directory inode 46948, block 0, offset 12: directory corrupted
Salvage<y>? yes

Entry 'status_2012-11-26_14h13m41.csv' in /var/log/status_logs (46956) has deleted/unused inode 47075.  Clear<y>? yes
Entry 'status_2012-11-26_10h42m58.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47076.  Clear<y>? yes
Entry 'status_2012-11-26_11h29m41.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47080.  Clear<y>? yes
Entry 'status_2012-11-26_11h42m13.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47081.  Clear<y>? yes
Entry 'status_2012-11-26_12h07m17.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47083.  Clear<y>? yes
Entry 'status_2012-11-26_12h14m53.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47085.  Clear<y>? yes
Entry 'status_2012-11-26_15h06m49.csv' in /var/log/status_logs (46956) has deleted/unused inode 47088.  Clear<y>? yes
Entry 'status_2012-11-20_14h50m09.csv' in /var/log/status_logs (46956) has deleted/unused inode 47073.  Clear<y>? yes
Entry 'status_2012-11-20_14h55m32.csv' in /var/log/status_logs (46956) has deleted/unused inode 47074.  Clear<y>? yes
Entry 'status_2012-11-26_11h04m36.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47078.  Clear<y>? yes
Entry 'status_2012-11-26_11h54m45.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47082.  Clear<y>? yes
Entry 'status_2012-11-26_12h12m20.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47084.  Clear<y>? yes
Entry 'status_2012-11-26_12h33m52.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47086.  Clear<y>? yes
Entry 'status_2012-11-26_10h51m59.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47077.  Clear<y>? yes
Entry 'status_2012-11-26_11h17m09.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47079.  Clear<y>? yes
Entry 'status_2012-11-26_12h54m11.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47087.  Clear<y>? yes

Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Couldn't fix parent of inode 46948: Couldn't find parent directory entry

Pass 4: Checking reference counts
Unattached inode 46945
Connect to /lost+found<y>? yes

Inode 46945 ref count is 2, should be 1.  Fix<y>? yes
Inode 46953 ref count is 5, should be 4.  Fix<y>? yes

Pass 5: Checking group summary information
Block bitmap differences:  -(208264--208266) -(210062--210068) -(211343--211491) -(213241--213250) -(213344--213393) -213397 -(213457--213463) -(213516--213521) -(213628--213655) -(213683--213688) -(213709--213728) -(215265--215300) -(215346--215365) -(221541--221551) -(221696--221704) -227517
Fix<y>? yes

Free blocks count wrong for group #6 (17247, counted=17611).
Fix<y>? yes

Free blocks count wrong (161691, counted=162055).
Fix<y>? yes

Inode bitmap differences:  +(47089--47090) +47093 +47095 +(47097--47099) +(47101--47104) -(47219--47220) -47222 -47224 -47228 -47231 -(47347--47348) -47350 -47352 -47356 -47359 -(47457--47488) -47985 -47996 -(47999--48000) -48017 -(48027--48028) -(48030--48032) -48049 -(48059--48060) -(48062--48064) -48081 -(48091--48092) -(48094--48096)
Fix<y>? yes

Free inodes count wrong for group #6 (7608, counted=7624).
Fix<y>? yes

Free inodes count wrong (61919, counted=61935).
Fix<y>? yes


embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****

embeddedrootwrite: ********** WARNING: Filesystem still has errors **********

embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks

Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory entry for '.' in ... (46948) is big.
Split<y>? yes

Missing '..' in directory inode 46948.
Fix<y>? yes

Setting filetype for entry '..' in ... (46948) to 2.
Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Pass 4: Checking reference counts
Inode 2 ref count is 12, should be 13.  Fix<y>? yes

Pass 5: Checking group summary information

embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****
embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks
Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite: clean, 657/62592 files, 87882/249937 blocks

ext4またはZFSに変更することを考えましたか?
mdpc

少なくともext4に変更することを考えましたが、それはこの問題の解決に役立ちますか?ZFSはそれでも良いのでしょうか?
ジェレミーフリースナー

1
どちらのオプションもこれを修正しません。ZFSではスーパーキャパシターを備えたデバイスを引き続き使用しますが、サーバーアプリケーションのext4にはバッテリーまたはフラッシュ保護されたキャッシュをお勧めします。
ewwhite

回答:


11

あなたはどちらも間違っています(たぶん?)... ext3は、基礎となるストレージを突然削除することで、できる限りの最善を尽くしています。

SSDにはおそらく何らかの種類のオンボードキャッシュがあります。使用中のSSDのメーカー/モデルについては言及していませんが、これはエンタープライズレベルまたは産業グレードのモデルと比較して、消費者レベルのSSDのように聞こえます。

いずれにしても、キャッシュは書き込みの合体を助け、ドライブの寿命を延ばすために使用されます。転送中の書き込みがある場合、突然の電源喪失が間違いなく破損の原因です。真のエンタープライズおよび産業用SSD には、バッテリーバックアップおよびフラッシュバックRAIDコントローラーキャッシュの動作とほぼ同じ方法で、キャッシュから不揮発性ストレージにデータを移動するのに十分な時間電力を維持するスーパーキャパシターがあります。

ドライブにスーパーキャップがない場合、実行中のトランザクションが失われているため、ファイルシステムが破損しています。ext3はおそらくすべてが安定したストレージ上にあると言われていますが、それは単なるキャッシュの機能です。


あなたとこれを支持したすべての人に申し訳ありませんが、あなたは間違っています。進行中の書き込みの損失を処理することは、まさにジャーナルの目的であり、ドライブが書き込みキャッシュを持っているかどうかを正しく報告し、それをフラッシュするコマンドに従う限り、ジャーナルはメタデータが矛盾しないことを保証します。スーパーキャップまたはバッテリーバックアップRAIDキャッシュのみが必要なので、バリアを有効にすることなく書き込みキャッシュを有効にできます。これにより、データの正確性を維持するためにパフォーマンスが犠牲になります。
psusi

@psusi使用中のSSDは、おそらくキャッシュが明示的に有効になっているか、OS_levelの設定に関係なく内部バッファーに依存しています。そのキャッシュ内のデータは、スーパーキャパシタ対応SSDが保護するものです。
ewwhite

IOバリアを有効にする場合、キャッシュ内のデータを保護する必要はありません。ほとんどのコンシューマータイプのドライブは、デフォルトで書き込みキャッシュが無効になっていますが、OSが注意しないと破損の問題が発生するため、必要に応じて有効にする必要があります。
psusi

2
@pusi今は古いですが、あなたはこれに言及しています:as long as the drive correctly reports whether it has a write cache and obeys commands to flush it, the journal guarantees that the metadata will not be inconsistent.それは事です:古いディスクを想定する傾向があるストレージコントローラーのために、SSD は時々データがフラッシュされるかどうかについて嘘をつきます。あなたはそのスーパーキャップが必要です。
ジョエル

2

あなたは正しいですし、同僚は間違っています。何か問題が発生しない限り、ジャーナルは一貫性のないfsメタデータを持たないようにします。hdparmドライブの書き込みキャッシュが有効になっているかどうかを確認してください。それがあり、IOバリアを有効にしていない場合(ext3ではデフォルトでオフ、ext4ではデフォルトでオン)、それが問題の原因です。

バリアは、ドライブの書き込みキャッシュを強制的に正しい時間にフラッシュして整合性を維持するために必要ですが、一部のドライブは動作が悪く、書き込みキャッシュが無効になっているときに無効になっていることを報告するか、フラッシュコマンドを静かに無視します。これにより、ジャーナルがジョブを実行できなくなります。


-1 ... -読解のための
ewwhite

@ewwhite、多分あなたは読んでみてください、そして実際に代わり、この幼稚な侮辱の有益な応答を書きます。
psusi

QAの他の回答と同様に、この回答はおそらく改善される可能性があります。しかし、少なくともいくつかの光とヒントを提供します。@downvoters:自分で答えを改善するか、考えられるフローについてコメントしますが、適切な正当化なしにこの答えを下げることは嫌です!
アルベルト
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.