web-dev-qa-db-ja.com

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

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

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
filesystemshardwaressdext3
13
Jeremy Friesner

あなたは両方とも間違っています（多分？）... ext3は、基盤となるストレージを突然削除することで、可能な限り最善を尽くしています。

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

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

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

11
ewwhite

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

一貫性を維持するためにドライブの書き込みキャッシュを正しいタイミングで強制的にフラッシュするにはバリアが必要ですが、一部のドライブは動作が悪く、書き込みキャッシュが無効になっているときに無効になっていると報告するか、フラッシュコマンドを黙って無視します。これはジャーナルがその仕事をするのを防ぎます。

2
psusi