問題タブ [corruption]

最近、 「SATA vs. SCSI の信頼性」という記事を読みました。主に、一般消費者向け SATA ドライブの非常に高速なビット フリッピングについて説明し、「現在、特定のディスクからすべてのデータを読み取ることができない可能性は 56%」と結論付けています。Raid-5 でさえ問題を常にスキャンする必要があるため、私たちを救うことはできません。

考慮事項:

Raid-Zを使用した Sun のZFSについて素晴らしいことを聞いたことがありますが、Linux と BSD の実装はまだ実験段階です。まだ全盛期の準備ができているかどうかはわかりません。

また、 Par2ファイル形式についてもかなり読んだことがあります。各ファイルと一緒に追加の % パリティを保存すると、ほとんどの問題から回復できるようです。ただし、これを内部で行うファイル システムは認識しておらず、個別のファイルを管理するのは難しいようです。

バックアップ (編集):

バックアップが最重要であることは理解しています。ただし、何らかのチェックを行わないと、知らないうちに悪いデータを簡単に送信してしまう可能性があります。また、どのバックアップにそのデータの適切なコピーがあるかを判断するのも難しい場合があります。

たとえば、Raid-5 アレイを 1 年間実行していて、破損したファイルを見つけたとします。適切なコピーが見つかるまで、バックアップのチェックに戻る必要があります。ファイルを含む最初のバックアップに移動するのが理想的ですが、ファイルが何度も編集されている場合は特に、それを特定するのが難しい場合があります。さらに悪いことに、破損が発生した後にそのファイルが追加または編集されたかどうかを検討してください。それだけで、Par2 などのブロック レベルのパリティを使用するのに十分な理由になります。

アプリを実行しているコンピューターが数百台あります。1台のコンピューターで、SQLiteから引き出した一部の文字列に1ビットの2つのインスタンスが正しく設定されていないのを確認しました。これが私の開発用コンピューターである場合、どこかにバグがあると思いますが、確かにいくつかのインストールがあり、その時点でまれなハードウェアベースのエラーが発生し始めます。

これは確かに私が行うIOの量に依存しますが、この種のものを見る可能性が十分にある場合の経験則はありますか？たとえば、TCPパケットの場合、このペーパーでは、「1600万から100億パケットの約1つ」でサイレントで検出されない破損が発生すると判断しました。

残念ながら、問題のマシンでmem/diskチェッカーを実行することは起こりそうにありません。

私が開発しているLinux組み込みアプリケーションでは、時々発生するいくつかのイベントを記録する必要があります。これらのレコードはMTDフラッシュデバイスに保存され、一度書き込まれると、レコードを変更したり効率的な検索を行ったりする必要はありませんが、データをユーザーに表示するには読み取りアクセスが必要です。大きな問題は、適切なシャットダウンシーケンスがないと、いつでも電源が切れてしまう可能性があることです。これらのイベントが発生する頻度は非常に遅い場合があります（日/週）が、それらのいくつかは一度に発生します。イベントごとに保存されるデータは、日付、時刻、いくつかの短いテキスト文字列、およびいくつかの整数のように強く入力されます。

現在、私はjffs2とSQLiteに基づくソリューションを継承しましたが、DBファイルが破損することがあるため、最適とはほど遠いものです。これが発生すると、ファイル全体が読み取れなくなり、jffs2、SQLite、フラッシュセクターのバグ、または電源が間違ったタイミングで切断されたことが原因であるかどうかを理解する方法がありません。

この種の問題を解決するのに役立つライブラリまたはファイルシステム/ライブラリの組み合わせはありますか？または、CSVのような形式のテキストファイルを使用する必要がありますか？

jpeg ファイルが破損しているかどうかを検出する効率的な方法はありますか?

背景情報:
  ソリューションは php スクリプト内から動作する必要があり
  ます jpeg ファイルはディスク上に
  あります 手動チェックはオプションではありません (ユーザーがアップロードしたデータ)

私はそれimagecreatefromjpeg(string $filename);ができることを知っています。しかし、そうするのはかなり遅いです。

より高速で効率的なソリューションを知っている人はいますか?

私は、アクセスアプリケーションにいくつかの簡単な修正を行っているクライアントにいます。しばらくの間、アクセスを試みましたが、すぐに回復しています。ただし、興味深い問題を発見しました。

一部のレポートで、「レコードが削除されました」というエラーが表示されます。レポートを確認しましたが、1 つのテーブルに問題があるようです。そのテーブルを開くと、すべての列が「#deleted」とマークされているレコードを見つけます。明らかに、この行が原因のようです。ただし、その行を削除しようとしても、実際には何も起こりません。テーブルを再度開くと、行はまだ存在します。

データベースに破損がありますか？このレコードを完全に削除するにはどうすればよいですか?

編集： MS2000バージョンです

解決策:単純な圧縮/修復では機能しませんでした。代わりに、データベースを 2003 ファイル形式に変換しました。圧縮/修復を提案する最初の回答にマークを付けました。これは、正しい方向に向けられたためです。ありがとう！

現在、かなり大規模な C++ アプリケーション (CPU と RAM の使用量、およびコードの長さの点で大規模 - 100,000 行を超える) で、非常に奇妙なバグが発生しています。これは、デュアルコアの Sun Solaris 10 マシンで実行されています。このプログラムは株価フィードを購読し、ユーザーが設定した「ページ」に表示します (ページはユーザーがカスタマイズしたウィンドウ構造です - プログラムはユーザーがそのようなページを設定できるようにします)。このプログラムは、基盤となるライブラリの 1 つがマルチスレッドになるまで問題なく動作していました。これによって影響を受けるプログラムの部分は、それに応じて変更されました。私の問題に。

約 3 回の実行ごとに、プログラムは起動時にセグメンテーション違反を起こします。これは必ずしも難しいルールではありません。3 回続けてクラッシュし、5 回続けて動作することもあります。興味深いのはセグメンテーション違反です (読む: 痛い)。さまざまな形で現れる可能性がありますが、最も一般的なのは、関数 A が関数 B を呼び出し、関数 B に入るとフレーム ポインタが突然 0x000002 に設定されることです。機能 A:

これは単純なシグナルの実装です。impl_ と _A_a1 は、クラッシュ時のフレーム内で明確に定義されています。その命令を実際に実行すると、プログラム カウンター 0x000002 になります。

これは、その関数で常に発生するとは限りません。実際、かなりの数の場所で発生しますが、これはエラーの余地があまりない単純なケースの 1 つです。場合によっては、スタックに割り当てられた変数が理由もなく突然ジャンク メモリ (常に 0x000002) に置かれることがあります。また、同じコードが問題なく実行される場合もあります。それで、私の質問は、何がスタックをひどく壊すことができるのかということです. フレームポインタの値を実際に変更できるものは何ですか? 確かにそんな話は聞いたことがありません。私が考えることができる唯一のことは、配列に範囲外の書き込みをすることですが、それが発生した場合に発生するスタックプロテクターを使用して構築しました。ここでも、スタックの範囲内に収まっています。私もしない 各スレッドには独自のスタックがあるため (これはすべて pthread です)、別のスレッドが最初のスレッドのスタック上の変数を上書きする方法を確認してください。Linuxマシンでこれを構築しようとしましたが、セグメンテーション違反は発生しませんが、約3回に1回フリーズします。

転覆で何かがうまくいかず、今私は直面しています

リポジトリからダンプを作成しようとすると。ここで別の質問がありますSubversionリポジトリエラーですが、破損が85リビジョン前であるため、解決策は私には十分ではありません。

破損はそれほど重要ではないディレクトリ（トランク/ブランチ/タグではない）にあるため、私は2つの解決策を考えていました。

1. 正常な部分からダンプを作成し、それを新しいリポジトリにインポートした後、重要なディレクトリから差分をコミットします（すべてのリビジョン履歴を失います）
2. 正常な部分からダンプを作成し、古いリポジトリ内の必要なディレクトリのすべてのリビジョンをチェックするrubyスクリプトを記述します。これにより、改訂用のdiffファイルが作成され、作成者名と元のコメントを使用して新しいリポジトリにコミットされます。

コメントはありますか？:)

/ JaanusSiim

すでに数回、SVN リポジトリの 1 つが破損し、プロジェクトのいくつかのバージョンまたはブランチで何をしたかを本当に知らなくても何でもできるという状況に陥りました。では、リポジトリが破損する原因は何ですか?

クライアント間の非互換性、特に文字セットの非互換性が問題を引き起こす可能性があるようです。

私は MySQL を初めて使用し、mysqldump. このページでは、次のコマンド ラインを提案しています。

しかし...ドキュメントを注意深く読むと、次のことがわかります。

ダンプの処理中--single-transactionは、有効なダンプ ファイル (正しいテーブルの内容とバイナリ ログの位置) を確保するために、他の接続で次のステートメントを使用しないでくださいALTER TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE。一貫性のある読み取りはこれらのステートメントから分離されていないため、ダンプ対象のテーブルでこれらのステートメントを使用すると、テーブルの内容を取得するSELECT実行者が誤った内容を取得したり、失敗したりする可能性があります。mysqldump

では、この可能性のあるダンプ破損シナリオを防ぐ方法はありますか? つまり、これらのステートメントを一時的にブロックできるコマンドです。

PS: この件に関する MySQL バグ エントリhttp://bugs.mysql.com/bug.php?id=27850

WM オペレーティング システムはプロセス メモリを相互に保護していますか? 1 つの不適切に作成されたアプリケーションが、最初の 1 つのメモリを誤って書き込んでいるだけで、他のアプリケーションをクラッシュさせる可能性はありますか?