ext3 ではなく ext4 のみを気にする場合は、名前を変更する前に、新しいファイルで fsync を使用することをお勧めします。 ext4 での fsync のパフォーマンスは、非常に長い遅延がなければ、ext3 よりもはるかに優れているようです。または、(少なくとも私の Linux システムでは) writeback がデフォルト モードであるという事実かもしれません。
ファイルが完全であることのみを気にし、ディレクトリ内でどのファイルが指定されているかを気にしない場合は、新しいファイルを fsync するだけで済みます。完全なデータを含む新しいファイルまたは古いファイルのいずれかを指すため、ディレクトリも fsync する必要はありません。
いいえ
libeatmydata とこのプレゼンテーションを見てください:
Eat My Data:誰もがファイル IO を間違える方法
http://www.oscon.com/oscon2008/public/schedule/detail/3172
MySql の Stewart Smith による。
オフライン/利用できなくなった場合に備えて、コピーを保管しています:
- 動画はこちら
- プレゼンテーション スライド (スライドのオンライン版)
ext4 ドキュメントから:
When mounting an ext4 filesystem, the following option are accepted:
(*) == default
auto_da_alloc(*) Many broken applications don't use fsync() when
noauto_da_alloc replacing existing files via patterns such as
fd = open("foo.new")/write(fd,..)/close(fd)/
rename("foo.new", "foo"), or worse yet,
fd = open("foo", O_TRUNC)/write(fd,..)/close(fd).
If auto_da_alloc is enabled, ext4 will detect
the replace-via-rename and replace-via-truncate
patterns and force that any delayed allocation
blocks are allocated such that at the next
journal commit, in the default data=ordered
mode, the data blocks of the new file are forced
to disk before the rename() operation is
committed. This provides roughly the same level
of guarantees as ext3, and avoids the
"zero-length" problem that can happen when a
system crashes before the delayed allocation
blocks are forced to disk.
「壊れたアプリケーション」という表現から判断すると、ext4 開発者は間違いなく悪い習慣だと考えていますが、実際には非常に広く使用されているアプローチであるため、ext4 自体にパッチが適用されました。
したがって、使用法がパターンに適合する場合は安全です。
そうでない場合は、 fsync を挿入する代わりに、さらに調査することをお勧めします 安全のためにあちこちに。 fsync 以来、それはあまり良い考えではないかもしれません ext3 で大きなパフォーマンス ヒットになる可能性があります (読み取り)。
一方、名前を変更する前にフラッシュすることは、非ジャーナリング ファイル システムで置換を行う正しい方法です。おそらくそれが、ext4 が最初にプログラムからこの動作を期待していた理由です。 auto_da_alloc オプションは後で修正として追加されました。また、ライトバック (非ジャーナリング) モード用のこの ext3 パッチは、データ損失の可能性を下げるために名前変更時に非同期にフラッシュすることで、不注意なプログラムを助けようとします。
ext4 の問題について詳しくは、こちらをご覧ください。