ファイルの移動中に中断が発生した場合、ファイルシステムは一貫性を失いますか?

ファイルの移動中に中断が発生した場合、ファイルシステムは一貫性を失いますか?

同じパーティション(EXT2)に2つのフォルダーがあります。mv folder1/file folder2停電などの中断が発生した場合、ファイルシステムは一貫性を失いますか?

仕事はmvアトミックではありませんか?

修正する: これまで私はIRCについて次の見解を得ました。

  1. アトミックなので、不一致が発生することはありません。
  2. 最初にディレクトリエントリが新しいディレクトリにコピーされ、次に古いディレクトリのエントリが削除されるため、ファイルは2回参照されますが、参照数が1の不一致が発生する可能性があります。
  3. 最初にポインタを消去してからコピーするので、ファイルへの参照がゼロであるという不一致があります。

誰かがこれを明確にすることができますか?

答え1

名前変更操作はすべてのファイルシステムで非常に高速であるため、中断される可能性はありませんが、クラシックファイルシステムでは確実に中断されます。できる破損 - ターゲットリンクを最初に作成した場合、ファイルに2つのリンクが残る可能性があります。これは正当ですが、ファイルは考える1つしかありませんが、後で削除すると問題が発生する可能性があります。一方、ソースリンクを最初に削除すると、ファイルが失われる可能性があります。 fsckを実行すると、通常、2つの状況のうちの1つを検出して修正しますが、ファイルが見つからない場合は、目的の場所に配置されず、任意の名前の "lost + found"ディレクトリに配置されます。リンクが2つある場合、countは単に更新されるため、ファイルシステムがサポートしている場合、ファイルは両方の場所に存在します。

停電に強いファイルシステムが必要な場合、ジャーナリングファイルシステムを使用する必要があります。、NTFS、EXT3、XFSなど。ほとんどの最新システムは基本的にジャーナリングファイルシステムを使用しますが、外付けドライブでFATを使用する場合はジャーナリングファイルシステムではないことに注意してください。

ジャーナリングファイルシステムは「デュアル入力」システムを使用します。つまり、ジャーナルファイルが移動される予定であることを記録し、移動を実行します。起動時にファイルシステムを確認するときに中断した場合は、移動がまだ完了していないことを通知して再実行します。

ジャーナリングファイルシステムには、メタデータジャーナリングとフルジャーナリングの2種類があります。メタデータのロギングは、ロギングシステムのファイル内容に対する変更を追跡しませんが(したがってファイルに書き込むと内容が失われる可能性があります)、ディレクトリの内容、ファイルのプロパティなどの重要なファイルシステム情報を追跡し続けることを意味します。 。


人々がアトミック名の変更操作について話すとき、これはシステムの他のプロセスが変換中にそれを観察できず、例えば割り込みmvコマンド自体を使用して半分を完了できないことを意味します^C。各ディレクトリ(ストレージスペースがディスク上のまったく異なる場所にある可能性があります)に書き込む物理プロセスは、ハードウェアレベルで実際にアトミックな操作にすることはできません。


完全性を期すために、ターゲットディレクトリに新しいリンクを作成し、古いディレクトリから削除することに加えて、名前の変更に関連する付随的なI / O操作があることに注意してください。つまり、両方のディレクトリのmtimeを更新することです。宛先ディレクトリの割り当てサイズを拡張し、ファイルがディレクトリ..の場合は、親ディレクトリのリンク数とリンク数を変更します。また、ファイル自体のatimeが影響を受けるかどうかはわかりません。

答え2

まず、いくつかの誤解を修正します。

アトミックなので、不一致が発生することはありません。

同じファイルシステム内でファイルを移動する(例:rename) システムコールはソフトウェア環境に対してアトミックです。アトミックは、ファイルを検索するすべてのプロセスが古い場所または新しい場所でファイルを表示できることを意味します。どのプロセスでも、ファイル内のリンク数が異なるか、ファイルがターゲットディレクトリに存在してからソースディレクトリに存在することを観察することはできません。 、またはファイルがソースディレクトリに存在しない後、ターゲットディレクトリに存在しません。

しかし、バグ、ディスク障害、または停電によってシステムがクラッシュした場合、ファイルシステムが一貫した状態に保たれるという保証はなく、移動が中断されないという保証もありません。 Linux は通常、ハードウェアイベントに対する原子性保証を提供しません。

最初にディレクトリエントリが新しいディレクトリにコピーされ、次に古いディレクトリのエントリが削除されるため、ファイルは2回参照されますが、参照数が1の不一致が発生する可能性があります。

これは具体的な実装技術を表す。まだもっと手に入れました。

起こるようにLinuxのext2(カーネル3.16ベース)この特別な技術を使用してください。ただし、これはディスクの内容が「前の位置」→「2つの位置」→「新しい位置」の順に進むという意味ではありません。これは、これら2つの操作(新しいエントリの追加、古いエントリの削除)がハードウェアレベルではアトミックではないためです。どちらか:これらのいずれかが中断され、ファイルシステムが一貫していない状態になる可能性があります。 (fsckはこの問題を解決することを願っています。)また、ブロック層は書き込み順序を変更して、競合が発生する前に前半がディスクにコミットされ、後半が実行されないようにすることができます。

システムがクラッシュしない限り(上記を参照)、参照数は1と異なることは観察されません。ただし、この保証はシステムの競合には拡張されません。

最初にポインタを消去してからコピーするので、ファイルへの参照がゼロであるという不一致があります。

繰り返しますが、これは特定の実装技術を表します。システムがクラッシュしていない場合は、ハングしたファイルを観察できませんが、これは少なくとも一部の構成でシステムのクラッシュが原因で発生する可能性があります。


~によるとAlexander Larssonによるブログ投稿、ext2はシステムクラッシュ時に一貫性を保証しませんが、ext3はdata=orderedこのモードで一貫性を提供します。 (このブログ投稿はrenameそれ自体に関するものではなく、ファイルに書き込むこととそのファイルを呼び出すことの組み合わせに関するものですrename。)

ext2、ext3、およびext4ファイルシステムの主な著者であるTheodore Ts'oは、次のように書きました。同じ問題に対するブログ投稿。このブログ記事では、次のように説明します。原子性(ソフトウェア環境のみ)耐久性(これは衝突の原子性と仕事が行われたことを知ることができるという約束についてです。)残念ながら、衝突にのみ関連する原子性に関する情報が見つかりません。ただし、ext4に提供される耐久性の保証はrename原子的でなければなりません。ext4用カーネルドキュメントauto_da_allocオプション(最新のカーネルのデフォルト)を使用してext4を宣言すると、ext4は次のwrite耐久性を保証します。つまり、ハードウェアの競合に関して原子的というrename意味です。rename

Btrfsの場合、rename既存のファイルを上書き衝突に関する限り、原子性は保証されますが、aはrenameファイルを上書きしませんこれにより、いずれかのファイルが存在しないか、または両方のファイルが存在しない可能性があります。


要約すると、あなたの質問に対する答えは、ext2の競合に関してファイルを移動することが原子的ではないだけでなく、ファイルを一貫したままにすることも保証されていないことです(修正fsckできないエラーはまれですが)。これがより良いファイルシステムが発明された理由です。 Ext3、ext4、btrfsは限られた保証を提供します。

答え3

この問題リクエストを受け取りましたスーパーユーザーではアプローチが少し異なります。コマンドのウィキペディアページmvもあります。説明するとても良い:

同じファイルシステム内でファイルを移動することは、通常、ファイルをコピーしてから元のファイルを削除するのとは異なります。名前の変更 システムコールをサポートしないプラットフォームでは、新しいリンクが新しいディレクトリに追加され、元のリンクが削除されます。ファイルデータにアクセスできませんでした。

Linuxはシステムコールの名前変更したがって、ファイルの名前を変更することはアトミック操作、つまり中断できない操作です。したがって、いいえ、あなたが説明している状況では、ファイルシステムは矛盾しません。

関連情報