問題タブ [fsync]

USBスティックにいくつかのフォルダーとファイルをコピーしようとしていますが、すべてが完了したらすぐにUSBスティックを取り外します。実装は次のようなものです。

• を使用して、USB スティックに対応するフォルダー構造を作成します。mkdir
• fsyncフォルダが作成された後の各ディレクトリ記述子
• ファイルの内容をコピーします (C++ ストリームを使用)
• fsync各ファイルがコピーされた後の各ファイル記述子

最後のファイルがコピーされた直後に、USB スティックを取り外します (~500ms - 1s)。ただし、フォルダー構造全体が欠落している場合があります。それを避けるためにfsync、最後のファイルがコピーされた後、各ディレクトリ記述子で再度使用しました。今回は、すべてのファイルとフォルダーが USB スティックに存在しますが、フォルダー構造にゴミが入ったり、USB スティックが破損したりすることがあります。USB スティックのファイルシステムは vfat です。データを正しく保存する方法について何か考えはありますか?

MongoDB インスタンスに認証を追加しました。次のコマンドでユーザーを作成しました

db.fsyncLock()を実行したいのですが、次のように表示されます。

私は何を間違っていますか？ありがとう！

私は実行しました

1. デシベル.fsyncLock()
2. バックアップ注文
3. デシベル.fsyncUnlock()

後で、データベースで find() などの一般的な操作を実行しようとしましたが、ブロックされて何も返されません。再び機能させるには、mongodb を再起動する必要があります。

私が間違っていることは何ですか？

Linux マシンで fsync のパフォーマンスをテストしているときに、fsync はファイルにデータを挿入するとファイルのサイズが大きくなり、非常に時間がかかることがわかりました。

環境: 12 コアの 2-CPU Linux バージョン 2.6.32_1-14-0-0 (scmpf@pwd) (gcc バージョン 4.4.4 20100726 (Red Hat 4.4.4-13) (GCC) ) #1 SMP 月 3 月 31 日10:42:09 CST 2014 ext2 ファイルシステム

テストコード:

結果：

上記の test_fsync プログラムを "echo "" >/home/zhangguangzhou/tmp/0" の後に実行すると、各 fsync は平均で 8 ミリ秒かかります。しかし、繰り返し実行すると、平均で 50 ミリ秒かかります。2回目以降の実行で。ファイルの途中から insertint データをテストしたり、異なるサイズのデータ​​で挿入したりしましたが、結果はほとんど変わりませんでした。

質問: 書き込みによってファイルが大きくなる場合、fsync の余分な時間がかかるのは何ですか?

fysnc の inode IO について考えてみましたが、どちらもファイル変更時の inode メタデータを更新する必要があるため、ファイル増加書き込みとファイル増加なし書き込みの両方で inode IO は同じです。

fsyncを使用して、SDカードにできるだけ早くファイルを書き込もうとしました。ただし、ファイルが SD カードに物理的に書き込まれる前に fsync が実際にブロックすることはありません。実際にSDカードにデータが入るまで5～6秒ほどかかるようです。ただし、commit = 1 または sync オプションを使用してファイル システム (ext3、ext4 を試しました) をマウントすると、データは再起動後 1 秒で安全になります。私の質問は、パーティション全体のソリューションに頼らずにフラッシングを達成する方法があるということですか? Linux カーネル 2.6.37 を使用しています。ありがとうございました

次の関数を使用して、ファイルにデータを書き込みます。

このfsync()呼び出しは IOError を処理するために必須です。ネットワーク ドライブに到達できないときに使用しない場合、関数はwrite()ローカル バッファーで動作し、例外は発生しません。

問題は、数回の書き込み操作の後、関数fsync()がハングすることです。それは何に関連していますか？ローカル マシンは Python 2.7 を実行する Linux です。ドライブは mount.cifs でマウントされます。リモート ディスクは、常に到達可能なローカル サーバー上にあります。リモートディスクをアンマウントすると、fsync()数十秒後に戻ります。

それぞれがリクエストを受け入れ、何らかの処理を行い、結果をコミットログに保存し、結果を返す複数のスレッドがあります。最大 x 秒分のデータが失われることを保証するには、このコミット ログを x 秒ごとに fsync する必要があります。

スレッド間の同期を避けたいと思います。つまり、共有ログではなく、それぞれが独自のコミット ログを持つ必要があります。これらの異なるコミット ログをすべて、パフォーマンスの高い方法で定期的に fsync することは可能ですか?

これは Linux、ext4 (または ext3) 上にあります。

（注：コードの性質上、通常の処理中であっても、スレッドはコミットログから自分の最近のデータの一部を再読み取りする必要があります（ただし、他のスレッドがログデータをコミットすることはありません）。多くのスレッドが読み書きする必要があるため、共有ログを使用してください)

似たような質問が既にあることは知っており、それらを調べてみましたが、私の質問に対する明確な一義的な答えを見つけることができませんでした。これらの機能とメモリ層との関係についてオンラインで調査していました。特に、メモリ層についての良い洞察を与えてくれるこの美しい記事を見つけました

fflush()アプリケーションからカーネル ファイルシステム バッファにデータを移動するようで、問題ありません。誰もがこの点に同意しているようです。私を困惑させた唯一のことは、同じ記事で、fsync()「データは安定したストレージレイヤーに保存される」と書かれたライトバックキャッシュを想定し、「ストレージ自体が書き込み時にデータを保存する可能性がある」と付け加えたことです。 -バックキャッシュなのでfsync()、データを安定したストレージに保存するために、O_DIRECT で開かれたファイルにはまだ必要です。"

あちこちを読むと、真実のように見えますが、データをストレージデバイスに入れますが、これにキャッシュレイヤーがある場合は、ここに移動するだけで、すぐに永続的なストレージに移動するのではなく、電源障害が発生した場合にデータが失われる可能性さえあります. バリアが有効になっているファイルシステムがない限り、「/およびその他の操作により、適切な CACHE FLUSH (ATA) または SYNCHRONIZE CACHE (SCSI) コマンドがデバイスに送信されます」[Web サイトの回答から]fsync()sync()sync()fsync()

質問:

1. 更新するデータが既にカーネル バッファーにあり、デバイスにライトバック モードの揮発性キャッシュ レイヤーがある場合、記事で述べたように、fsync()[そしてsync()私が推測する] ような操作はデータを安定したメモリ レイヤーに同期するというのは本当ですか?揮発性のものをスキップしますか？これは、ライトバック キャッシュではなく、ライトスルー キャッシュで起こることだと思います。私が読んだことから、ライトバックキャッシュをオンにfsync()すると、データを揮発性キャッシュに入れるデバイスにデータを送信することができ、後でのみ永続メモリに入ることがわかりました

2. fsync()私はそれがファイル記述子で動作し、次に単一のファイルで動作することを読みsync()ましたが、バッファの全体的な展開が発生するため、更新されるすべてのデータに適用されます。また、このページから、ディスクへの実際の書き込みの終了を待たずfsync()に、ディスクへの書き込みの終了を待機します。sync()2 つの間のメモリ データ転送に関連する他の違いはありますか?

助けようとする人々に感謝します

FUSE APIsyncはファイル システム レベルの呼び出しを公開せず、fsyncとfsyncdir. syncが呼び出されると (またはsyncfsFUSE マウントポイント内で)、カーネルがfsyncすべての FUSE マウント ファイル システム上のすべての開いているファイルを呼び出すということですか? それとも別のセマンティクスがありますか？

ここで、何かを書き込むためにリモート ファイルを開く必要があります。コードは次のようになります。

ここで、すべてのデータが実際にディスクに書き込まれていることを確認したいので、コードを次のように変更します。

しかし、メッセージが表示されます：

ファイルを強制的にディスクに同期的に書き込みたい場合、どうすればよいですか?