「cp」を強制終了するとどうなりますか?それは安全ですか、それは結果をもたらしますか?


23

実行中に+ をcp入力してコピーコマンドを終了すると、ext4ファイルシステムにどのような影響がありますか?CtrlC

ファイルシステムは破損しますか?不完全なコピーされたファイルが占有しているパーティションのスペースは、削除後も使用可能ですか?

そして、最も重要なことは、cpプロセスを終了することは安全なことですか?


1
ext4の答えは正しいものの、ジャーナリングのないファイルシステムはそれほど安全ではないことに注意してください。
アベニュー

3
@Ave Journalingはこれとは何の関係もありません。syscallは、使用するファイルシステムに関係なくアトミックです。ジャーナリングは、電源が突然失われる可能性がある状況で役立ちます。
フォレスト

回答:


22

これは安全ですが、当然のことながらコピーを終了していない可能性があります。

ときにcpコマンドが実行され、それはファイルのコピーを作成するために、カーネルに指示するシステムコールを行います。syscallは、アプリケーションが呼び出すことができる関数であり、ディスクへのデータの読み取りや書き込みなど、カーネルにサービスを要求します。ユーザー空間プロセスは、syscallが終了するのを単に待ちます。呼び出しをトレースすると、次のようになります。

open("/home/user/hello.txt", O_RDONLY)           = 3
open("/mnt/hello.txt", O_CREAT|O_WRONLY, 0644)   = 4
read(3, "Hello, world!\n", 131072)               = 14
write(4, "Hello, world!\n", 14)                  = 14
close(3)                                         = 0
close(4)                                         = 0

これは、コピーされるファイルごとに繰り返されます。これらのシステムコールが機能するため、破損は発生しません。このようなシステムコールが入力されると、致命的なシグナルは、システムコールの実行中ではなく、システムコールが終了した後にのみ有効になります。このため、プロセスを強制終了すると、現在実行中のsyscallが終了した後にのみプロセスが終了します。つまり、ファイルシステムドライバーが存在するカーネルは、ファイルシステムを正常な状態にするために完了する必要がある操作を自由に完了できます。この種のI / Oは、操作の途中で終了することはなく、アトミック操作になります。

興味深いことに、このようなコマンドは、cp強制終了してもすぐに終了しない場合があります。非常に大きなファイルをコピーして、SIGKILLを使用して強制終了する場合、現在のsyscallが終了するまでプロセスは引き続き実行されます。大きなファイルでは、プロセスが中断できない状態になるため、これには時間がかかる場合があります。


2
@qwrそれはおそらくglibcライブラリの一部であり、cpそれ自体ではありません。内部的に値として使用するさまざまなファイルアクセス関数があります。
フォレスト

2
素晴らしい答えです!cp大きなファイルを処理しているときでも、SIGKILL後の終了に遅延があることに気づきませんでした...プロセスのそれらの割り込み不可能なアトミック操作の期間が短すぎるかもしれません。殺害ddや他のディスク読み取り/書き込みプロセスでも同じ説明が機能しますか?
セニーニャ

1
@Seninhaアクセスがキャッシュされるため、操作は非常に簡単です。したがって、バーストで行われた場合、ドライブが実際に処理できるよりも多くのデータを1秒あたりに大量にコピーできます。ファイルが非常に大きく、低速のメディア上にある場合、キャッシュがいっぱいになり、プロセスの強制終了に時間がかかることがあります。killingに関してはddbs設定した内容によって異なります。512(デフォルト)のみの場合、すぐに終了します。大きい場合は、少し時間がかかる場合があります。
フォレスト

3
@qwr 128kbチャンクは、blockdevicesから読み取るときにcoreutilsでハードワイヤーされたデフォルトです。これは、syscallsを最小化するために行われます。分析は、coreutilsのソースに記載されています:git.savannah.gnu.org/cgit/coreutils.git/tree/src/ioblksize.h
Fiisch

1
@AndrewHenleおそらく、ファイルシステムのメタデータがアトミックであると言ったはずです。書き込みが部分的である可能性があることは正しいです。
フォレスト

20

以来cpユーザ空間のコマンドがあり、これはファイルシステムの整合性には影響を与えません。

もちろん、実行中のcpプログラムを強制終了した場合、少なくとも1つのファイルが完全にコピーされないように準備する必要があります。


14
なぜ下票なのですか?ずるいからといって?
スティーブンキット

6
間違いなく私の答えをすべて下票する人が少なくとも一人いるようです。誰が下票をしたのかを知る方法を知っていますか?
18

2
モデレーターでさえ、誰が特定の票を投じたのかを知ることはできません。「お問い合わせ」リンクを使用して、調査を依頼することができます。
フィリップケンドール

1
ユーザー空間のプログラムがファイルシステムの整合性を危うくすることができたら、とても悲しいでしょう。注:もちろん、そこにすることができ、そこにされていること、およびファイルシステムの実装にバグがあるでしょう。注#2:もちろん、CAP_SYS_RAWIOファイルシステムの基盤となるデバイス(例sudo dd if=/dev/urandom of=/dev/sda1:)に直接アクセスできる昇格された特権(例:Linuxまたは他のOSで同等)で実行されるユーザー空間プログラムは、あらゆる種類の破壊をもたらす可能性があります。
ヨルグWミットタグ

3
そして、ファイルシステムが中断された後に破損するほどバグがある場合、cpおそらく終了からcpも破損するでしょう
...-ilkkachu
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.