ファイルの移動中に中断された場合、ファイルシステムが不整合になる可能性はありますか？
同じパーティション（EXT2）に2つのフォルダがあります。mv folder1/file folder2を実行して、何らかの障害（停電など）が発生すると、ファイルシステムが不整合になる可能性がありますか？
mv操作はアトミックではありませんか？
更新：これまでのところIRC私は次の見解を得ました：
- アトミックなので、不整合は起こりません
- 最初に新しいディレクトリにdirエントリをコピーしてから、前のディレクトリのエントリを消去します。そのため、ファイルが2回参照されるという矛盾が生じる可能性がありますが、参照カウントは1です。
- 最初にポインタを消去してからポインタをコピーし、ファイルの参照が0であるという矛盾を解消します。
誰かが明確にできますか？
最初に、いくつかの神話を払拭しましょう。
それはアトミックなので、不整合は起こり得ません
同じファイルシステム内でのファイルの移動（つまり、 rename ）システムコールは、ソフトウェア環境に対してアトミックです。原子性とは、ファイルを検索するプロセスが古い場所または新しい場所のいずれかでファイルを参照することを意味します。ファイルのリンクカウントが異なること、ファイルが宛先ディレクトリに存在した後にソースディレクトリに存在すること、またはファイルがソースに存在しない後にターゲットディレクトリに存在しないことをプロセスが監視できないディレクトリ。
ただし、バグ、ディスクエラー、停電などの理由でシステムがクラッシュした場合、ファイルシステムが一貫した状態に保たれていることは保証されません。 Linuxは一般に、ハードウェアイベントに関して原子性を保証しません。
最初に新しいディレクトリにdirエントリをコピーしてから、前のディレクトリのエントリを消去します。これにより、ファイルが2回参照されるという矛盾が生じる可能性がありますが、参照カウントは1です。
これは特定の実装手法を指します。他にもあります。
Linuxのext2 （カーネル3.16以降）がこの特定の手法を使用するのは偶然です。ただし、これは、2つの操作（新しいエントリの追加、古いエントリの削除）がハードウェアレベルでアトミックではないため、ディスクのコンテンツが[古い場所]→[両方の場所]→[新しい場所]のシーケンスを通過することを意味しません。 ：それらの1つが中断され、ファイルシステムが不整合な状態になる可能性があります。 （うまくいけばfsckがそれを修復します。）さらに、ブロック層は書き込みを並べ替えることができるため、クラッシュの直前に前半をディスクにコミットでき、後半は実行されませんでした。
システムがクラッシュしない限り（上記を参照）、参照カウントが1と異なることはありませんが、その保証がシステムクラッシュにまで及ぶことはありません。
最初にポインタを消去してからポインタをコピーし、ファイルの参照が0であるという矛盾を解消します。
繰り返しますが、これは特定の実装手法を指します。システムがクラッシュしない場合、ダングリングファイルは確認できませんが、少なくとも一部の構成では、システムクラッシュの結果である可能性があります。
Alexander Larssonによるブログ投稿 によると、ext2はシステムクラッシュの一貫性を保証しませんが、ext [3]はdata=orderedモード。 （このブログ投稿はrename自体ではなく、ファイルへの書き込みとそのファイルでのrenameの呼び出しの組み合わせに関するものであることに注意してください。）
Ext2、ext3、ext4ファイルシステムの主な著者であるセオドアTs'oが 同じ問題に関するブログ投稿 を書いた。このブログ投稿では、atomicity（ソフトウェア環境に関してのみ）とdurability（クラッシュに関する原子性とコミットメントの保証、つまり操作が実行されたことを知る）。残念ながら、クラッシュのみに関する原子性に関する情報は見つかりません。ただし、ext4に指定された耐久性の保証では、renameがアトミックである必要があります。 ext4のカーネルドキュメント は、ext4にauto_da_allocオプション（最近のカーネルのデフォルト）とext4は、writeの後にrenameが続くという耐久性を保証します。これは、renameがハードウェアのクラッシュに関してアトミック。
Btrfsの場合、 a renameは既存のファイルを上書きします はクラッシュに関してアトミックであることが保証されますが、 a renameはファイルを上書きしません は、どちらのファイルも、両方のファイルも存在する可能性があります。
要約すると、あなたの質問に対する答えは、ext2でのクラッシュに関してファイルをアトミックではなく移動するだけでなく、ファイルを一貫した状態に保つことさえ保証されていないということです（ただし、fsck修復できないことはまれです）—ほとんど何もないので、より優れたファイルシステムが発明されました。 Ext3、ext4、およびbtrfsは限定的な保証を提供します。
名前変更操作はどのファイルシステムでも非常に高速であるため、中断される可能性はほとんどありませんが、従来のファイルシステムでは、確実に中断されます。最初に宛先リンク、それはファイル上に2つのリンクを残すことができます-これは合法ですが、ファイルは1つしか持っていないので、以下の場合に問題が発生する可能性があります1つは後で削除されます。一方、最初にソースリンクを削除すると、ファイルが失われる可能性があります。 fsckを実行すると、通常どちらの状態も検出および修正されますが、ファイルが失われた場合、ファイルは目的の場所ではなく、任意の名前の「lost + found」ディレクトリに配置されます。リンクが2つある場合、リンク数は単純にファイルシステムがこれをサポートしている場合、ファイルは2つの場所に存在します。
電源障害が発生した場合に堅牢なファイルシステムが必要な場合は、NTFS、EXT3、XFSなどのジャーナルファイルシステムを使用する必要があります。最近のほとんどのシステムはデフォルトでジャーナリングファイルシステムを使用しますが、外部ドライブに使用する場合、FATはジャーナリングファイルシステムではないことに注意してください。
ジャーナリングファイルシステムは「ダブルエントリ」システムを使用します。ジャーナルファイルには、移動するつもりであるという事実が書き込まれ、移動が実行されます。起動時にファイルシステムがチェックされると、ファイルシステムが中断された場合、移動が完了していないことが通知され、その時点でやり直されます。
ジャーナリングファイルシステムには、メタデータジャーナリングと完全ジャーナリングの2種類があります。メタデータジャーナリングとは、ジャーナルシステムのファイルコンテンツへの変更を追跡しないことを意味します（そのため、ファイルに書き込んでいると、コンテンツが失われる可能性があります）が、ディレクトリコンテンツなどの重要なファイルシステム情報は追跡し続けます、ファイルプロパティなど.
名前変更操作がアトミックであると人々が話すとき、それはシステムの別のプロセスによって移行の途中で観察することができないことを意味します。 mvコマンド自体を中断する ^C。ストレージスペースがディスク上の大きく異なる場所にある可能性がある各ディレクトリへの物理的な書き込みプロセスは、ハードウェアレベルでの真のアトミック操作ではありません。
完全を期すために、宛先ディレクトリに新しいリンクを作成して古いリンクから削除することに加えて、名前変更に関連するいくつかの偶発的なI/O操作もあることに注意してください。両方のディレクトリのmtimeを更新し、場合によっては宛先ディレクトリの割り当てサイズ、..リンクと、ファイルがディレクトリの場合は親ディレクトリのリンク数。また、ファイル自体のatimeが影響を受けるかどうかはわかりません。
この質問 質問されました スーパーユーザーでは少し異なります。 mvコマンドのWikipediaページ 説明
同じファイルシステム内でのファイルの移動は、通常、ファイルをコピーしてから元のファイルを削除する場合とは異なる方法で実装されます。 rename syscallをサポートしないプラットフォームでは、新しいリンクが新しいディレクトリに追加され、元のリンクは削除されます。ファイルのデータはアクセスされません。
Linuxには rename syscall があるため、ファイルの名前をアトミック、つまり中断できない操作に変更します。したがって、いいえ、あなたが説明した状況でファイルシステムが不整合になることはありません。