ファイルの移動中に中断された場合、ファイルシステムが不整合になることはありますか？

同じパーティション（EXT2）に2つのフォルダーがあります。私mv folder1/file folder2と何らかの中断（停電など）が発生した場合、ファイルシステムが矛盾する可能性がありますか？

mv操作はアトミックではありませんか？

更新： これまでのところ、IRCで私は次のような見方をしていました。

1. アトミックであるため、矛盾が発生することはありません
2. 最初に新しいディレクトリのディレクトリエントリをコピーしてから、前のディレクトリのエントリを消去するため、ファイルが2回参照されるという矛盾が生じる可能性がありますが、参照カウントは1です。
3. 最初にポインターを消去してからポインターをコピーするため、ファイルの参照が0であるという矛盾が生じます。

誰かが明確にすることはできますか？

まず、いくつかの神話を払拭しましょう。

アトミックであるため、矛盾が発生することはありません

同じファイルシステム（つまり、rename）システムコール内でファイルを移動することは、ソフトウェア環境に関してアトミックです。アトミック性とは、ファイルを検索するプロセスが古い場所または新しい場所のいずれかでファイルを表示することを意味します。ファイルのリンクカウントが異なること、ファイルが宛先ディレクトリに存在した後にソースディレクトリに存在すること、またはソースに存在せずにファイルがターゲットディレクトリに存在しないことをプロセスで確認できないディレクトリ。

ただし、バグ、ディスクエラー、または電力損失のためにシステムがクラッシュした場合、ファイルシステムが一貫した状態のままであるという保証はありません。Linuxは一般に、ハードウェアイベントに関する原子性の保証を提供しません。

最初に新しいディレクトリのディレクトリエントリをコピーしてから、前のディレクトリのエントリを消去するため、ファイルが2回参照されるという矛盾が生じる可能性がありますが、参照カウントは1です。

これは、特定の実装手法を指します。他にもあります。

Linux上のext2（カーネル3.16以降）がこの特定の手法を使用することはたまたまあります。ただし、これは、2つの操作（新しいエントリの追加、古いエントリの削除）がハードウェアレベルでもアトミックではないため、ディスクコンテンツが[古い場所]→[両方の場所]→[新しい場所]のシーケンスを経ることを意味しません：そのうちの1つが中断され、ファイルシステムが不整合な状態のままになる可能性があります。（願わくばfsckが修復します。）さらに、ブロック層は書き込みを並べ替えることができるため、前半はクラッシュの直前にディスクにコミットされ、後半は実行されませんでした。

システムがクラッシュしない限り（上記を参照）、参照カウントが1と異なることはありませんが、その保証はシステムクラッシュにまでは及びません。

最初にポインターを消去してからポインターをコピーするため、ファイルの参照が0であるという矛盾が生じます。

繰り返しますが、これは特定の実装手法を指します。システムがクラッシュしない場合、ダングリングファイルは観察できませんが、少なくともいくつかの構成では、システムクラッシュの結果である可能性があります。

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

ext2、ext3、ext4ファイルシステムの主要な著者であるTheodore Ts'oは、同じ問題に関するブログ投稿を書いています。このブログ投稿では、原子性（ソフトウェア環境のみ）と耐久性（クラッシュに関する原子性とコミットメントの保証、つまり操作が実行されたことの確認）について説明しています。残念ながら、クラッシュに関する原子性に関する情報は見つかりません。ただし、ext4に与えられる耐久性の保証は、それrenameがアトミックであることを要求します。ext4のカーネルのドキュメントには、ext4と同様に、auto_da_allocオプション（最新のカーネルのデフォルト）を使用したext4 writeが、次のrename、これrenameはハードウェアのクラッシュに関してアトミックであることを意味します。

Btrfsのために、既存のファイルを上書きすることがクラッシュに関してアトミックであることが保証されますが、ファイルを上書きしないことは、どちらのファイルまたは既存のファイルの両方をもたらす可能性があります。renamerename

要約すると、質問に対する答えは、ext2のクラッシュに関してアトミックではなくファイルを移動するだけでなく、ファイルを一貫した状態のままにすることさえ保証されていfsckないということです（修復できない障害はまれです）—ほとんど何もありません。それが、より良いファイルシステムが発明された理由です。Ext3、ext4、およびbtrfsは限定的な保証を提供します。

名前変更操作はどのファイルシステムでも非常に高速であるため、中断されることはほとんどありませんが、従来のファイルシステムでは確実に中断できます-最初に宛先リンクを作成すると、ファイルに2つのリンクを残すことができます-しかし、ファイルは1つしかないと考えているため、後で削除すると問題が発生する可能性があります。一方、最初にソースリンクを削除すると、ファイルが失われる可能性があります。fsckを実行すると通常どちらかの状態が検出および修正されますが、ファイルが失われた場合、目的の場所ではなく任意の名前で「lost + found」ディレクトリに配置されます。2つのリンクがある場合、リンクカウントは単純にファイルシステムがこれをサポートしている場合、ファイルは2つの場所に存在します。

電源障害が発生した場合に堅牢なファイルシステムが必要な場合は、NTFS、EXT3、XFSなどのジャーナリングファイルシステムを使用する必要があります。最新のシステムのほとんどはデフォルトでジャーナリングファイルシステムを使用しますが、外部ドライブに使用する場合、FATはジャーナリングファイルシステムではないことに注意してください。

ジャーナリングファイルシステムは、「ダブルエントリ」システムを使用します。ジャーナルファイルに移動しようとしているという事実を書き込み、移動を実行します。ファイルシステムが起動時にチェックされ、中断された場合、移動が完了していないことに気づき、それからやり直します。

ジャーナリングファイルシステムには、メタデータジャーナリングと完全なジャーナリングの2種類があります。メタデータジャーナリングとは、ジャーナルシステムのファイルコンテンツの変更を追跡しないことを意味します（したがって、ファイルに書き込むとコンテンツを失う可能性があります）が、ディレクトリコンテンツなどの重要なファイルシステム情報を追跡し続けます、ファイルのプロパティなど

名前変更操作がアトミックであることを話すとき、システム上の別のプロセスによって遷移の途中でそれを観察することはできず、たとえば、mvコマンド自体をで中断することによってそれを半分完了したままにすることはできません^C。ディスク上の記憶領域が大きく異なる場所にある可能性がある各ディレクトリへの物理的な書き込みプロセスは、ハードウェアレベルでの本当にアトミックな操作にはなり得ません。

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

この質問は、スーパーユーザーに対してわずかに異なる方法で尋ねられました。mvコマンドのウィキペディアのページでも非常によく説明されています。

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

Linuxにはsyscallという名前の変更があるため、ファイルの名前をアトミックな（つまり、相互運用不可能な）操作として変更します。いいえ、あなたが説明した状況でファイルシステムが矛盾することはありません。